ホームページ  >  記事  >  バックエンド開発  >  .NET Core構成システムの詳細な分析(写真)

.NET Core構成システムの詳細な分析(写真)

黄舟
黄舟オリジナル
2017-03-09 15:18:501712ブラウズ

前回の記事では、.NET プラットフォーム全体における .NET Core の状況と .NET Framework との関係について紹介しました (原文リンク)。今回は、.NET Core Framework の構成と各モジュールの主な機能について詳しく紹介します。 、クロスプラットフォームを実現する方法についても説明します。

.NET Core構成システムの詳細な分析(写真)

上の図は、.NET Core のシステム構造を示しています。アプリケーション層は、ASP.NET Core (Web アプリの作成に使用) や UWP (Web アプリの作成に使用) など、UI ベースのアプリケーションを開発するためのフレームワーク セットです。 Windows 10 アプリ)。

中間層はパブリック ライブラリ (CoreFX) で、.NET 標準ライブラリを実装し、(ファイル、ネットワークなど) などの一般的なシステム レベルの操作が含まれています。

CoreFx には、2 つのランタイム (CoreCLR、CoreRT) が含まれています。CoreCLR は、クロスプラットフォームのオープン ソース コンパイラー RyuJIT を使用するジャスト イン タイム コンパイラー (JIT) ベースのランタイムです。事前コンパイラ (AOT) RyuJIT を使用して AOT コンパイルを実装したり、他の AOT コンパイラを使用したりできます。 AOT は、IL を事前にマシンコードにコンパイルするため、モバイル デバイスでの起動速度が向上し、エネルギーも節約されます。

最後に、オープン ソースのクロスプラットフォーム ソース コード コンパイラーである Roslyn について説明します。これは、先ほどの 2 つのコンパイラーとは異なり、主に IL をネイティブ マシン コードにコンパイルするために使用されます。一方、Roslyn は C# または C# をコンパイルします。 VB.NET コードはプログラム中間言語 (IL) にコンパイルされます。

ロズリンコンパイラ

Roslyn コンパイラは、C# または VB.NET コードをアセンブリ (アセンブリ) にコンパイルするために使用されます。そのコンパイル プロセスは、合計 4 つのステップを含むパイプライン タイプのプロセスです。その具体的なプロセスを次の図に示します。

compiler pipeline

A.パーサー(解析)

文法に従ってソースコードを解析します。

B.宣言

コードのメタデータ (メタデータ) を生成します。 メタデータは、現在のコードで定義されているデータ型とメンバーを説明し、参照される型とメンバーも説明するデータ テーブルのコレクションです。

C.バインド

生成された IL コードをそれを記述するメタデータとバインドして、マネージド モジュールを生成します。

D. エミット(生成)

1 つ以上のマネージド モジュールを結合してアセンブリを生成します。

RyuJITコンパイラ

プログラムの実行中に特定のメソッドを実行する必要がある場合、コンパイルされた IL をローカルのマシンコードに変換する必要があり、このタスクは RyuJIT に引き渡されます。 RyuJIT は、AMD64 アーキテクチャを初めて実装した新世代の JIT コンパイラで、JIT64 (前世代のコンパイラ) よりも高速にコードを生成し、プログラムの実行効率を向上させます。

CoreCLR と CoreRT

.NET Core ランタイム (CoreCLR) と .NET Core ランタイム (CoreRT) はどちらも .NET Core ランタイム (ランタイム) であり、.NET Framework CLR と同様のコア機能 (メモリ管理、アセンブリ読み込み、セキュリティ、例外、スレッド管理、など)、すべてのランタイム指向言語で使用できます。

CoreRT と CoreCLR の違いは、CoreRT が、.NET Core プログラムをネイティブ コードにコンパイルし、.NET ランタイムに依存せずにホスト マシン上で実行できる一連の AOT メカニズムを提供することです。さらに、2 つのランタイムのほとんどの関数コード (GC など) が共有されます。 AOT の最適化は多くのメリットをもたらします:

  • コンパイル後、フレームワークをインストールせずに、CoreRT を含むすべての依存関係を含む単一のファイルが生成されます

  • 起動時はマシンコードです。マシンコードを生成したり、JIT コンパイラーをロードしたりする必要はありません

  • LLILC、ILからCPPまでを含む他の最適化コンパイラーも使用可能

CoreRT にはマシン コードを生成する 2 つの方法があります。1 つは、デフォルトで IL をマシン コードにコンパイルする方法です。もう 1 つは、C# コードを C++ コードにコンパイルする方法です。対応するプラットフォームの C++ コンパイラーを呼び出して最適化し、マシンコードにコンパイルします。

RyuJIT を使用してマシンコードにコンパイルする

dotnet restore
dotnet build --native --ilcpath <repo_root>\bin
\Product\Windows_NT.x64.Debug\packaging\publish1

C++ コードをコンパイルして生成する

dotnet restore
dotnet build --native --cpp --ilcpath <repo_root>\bin\Product\Windows_NT.x64.Debug\packaging\
publish1 --cppcompilerflags /MTd</repo_root>

CoreRT には、さまざまなプラットフォームに対して一度コンパイルする必要があるという欠点もありますが、エンジニアはサポートしたくないプラットフォームに公開することができません (たとえば、ゲームはデスクトップのみをサポートし、携帯電話はサポートしません)。 。

注: これら 2 つの名前は .NET Core RC2 バージョンでは使用できません。公式声明によると、このコマンドは現在のバージョンでは削除されています。最終的な状況は、正式バージョンが 6 月 27 日にリリースされるまでわかりません。

CoreFX(.NET Core ライブラリ)

CoreFX には主に、System.Collections、System.IO、System.Xml などのいくつかのパブリック ライブラリが含まれています。 CoreFX は .NET Standard ライブラリの実装であり、.NET Framework 4.6.3 も .NET Standard ライブラリに基づいています。現在、.NET Standard Library バージョン 1.6 に基づいています。詳細については、以下の表を参照してください:

.NET Core構成システムの詳細な分析(写真)

.NET Core コードの開発、デプロイ、および実行プロセス

.NET Core構成システムの詳細な分析(写真)

上の図から、JIT を使用したコンパイルと、AOT を使用したソース コードのコンパイルとプログラムの実行は、2 つの異なるプロセスであることがわかります。

JIT コンパイラーを使用してプログラムをデプロイする場合、必要なのは、プログラムを IL アセンブリとしてパッケージ化することだけです。コンパイラーは、メソッドが初めて実行される前に IL をターゲット マシン コード (ネイティブ コード) にコンパイルし、AOT コンパイルを行います。コンパイル中にソース コードをターゲット マシン コードに直接コンパイルします。

AOT はソース コードをマシン コードにコンパイルし、次の特徴があります:

  • リフレクションを静的コードに置き換えます。たとえば、値の型が ValueType.Equals の equals メソッドをオーバーライドしない場合、デフォルトで Reflection を使用して filedinfo が検索され、型が等しいかどうかが判断されます。値が等しいかどうかを比較します。 AOTコンパイルではリフレクションが置き換えられるため、値の等価性のみを比較できます。

  • 依存するサードパーティ ライブラリと .NET ライブラリは、最終的にコンパイルされたプログラムにパッケージ化されます。

  • パッケージ化されたプログラムは、主にガベージ コレクターを含む合理化されたバージョンのランタイム (CoreRT) 上で実行され、ランタイムもアプリ ファイルにパッケージ化されます。

  • リフレクション コードはコンパイル中に置き換えられますが、実行時に動的リフレクション呼び出しが発生した場合は、対応するメタデータと実装が見つからないため、例外がスローされます。解決策は、コンパイル前にランタイム ディレクティブ ファイルを構成して、使用するアセンブリを指定することです。

まとめ

このセクションでは、.NET 標準ライブラリに準拠した複数の新しいコンパイラーや CoreFX など、.NET Core の構造について説明します。一般に、.NET Core はパフォーマンスと開発効率の向上の点で以前の .NET Framework よりも優れています。鍵となるのは、.NET の完全なクロスプラットフォーム機能の基本テクノロジー スタックを初めて実現することです。

.NET Core はクロスプラットフォーム機能に基づいており、GUI に関連性の高い API は .NET Core に移植されていません。そのため、Windows フォームや Windows Presentation Foundation (WPF) は .NET Core に移植されていません。 .NET Core は、コンソール アプリケーションとクラス ライブラリ タイプのプロジェクトをサポートします。

ただし、Microsoft はユニバーサル Windows プラットフォーム (UWP) 開発プラットフォームで .NET Core を使用し、.NET ネイティブ テクノロジを使用してパフォーマンスをネイティブ コードに非常に近い速度まで向上させています。

ASP.NET Core は、コンソール アプリケーションを使用してホスティング環境 Kestrel Server を駆動し、ASP.NET Core プログラムの実行をサポートします。

以上が.NET Core構成システムの詳細な分析(写真)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。