Heim  >  Artikel  >  Backend-Entwicklung  >  Detaillierte Analyse des .NET Core-Kompositionssystems (Bild)

Detaillierte Analyse des .NET Core-Kompositionssystems (Bild)

黄舟
黄舟Original
2017-03-09 15:18:501751Durchsuche

Der vorherige Artikel stellte den Status von .NET Core in der gesamten .NET-Plattform und seine Beziehung zum .NET Framework vor (ursprünglicher Link). In diesem Artikel werden die Zusammensetzung des .NET Core-Frameworks und die Hauptfunktionen jedes Moduls ausführlich vorgestellt , sowie wie man plattformübergreifend erreicht.

Detaillierte Analyse des .NET Core-Kompositionssystems (Bild)

Die obige Abbildung beschreibt die Systemzusammensetzung von .NET Core. Die oberste Ebene ist die Anwendungsschicht, bei der es sich um ein Framework für die Entwicklung von UI-basierten Anwendungen handelt, einschließlich ASP.NET Core (zum Erstellen von Webanwendungen) und UWP (zum Erstellen). Windows 10-Apps).

Die mittlere Schicht ist eine öffentliche Bibliothek (CoreFX), die die .NET-Standardbibliothek implementiert und allgemeine Vorgänge auf Systemebene wie (Dateien, Netzwerke usw.) umfasst.

Unter CoreFx befindet sich die Laufzeitumgebung. .NET Core umfasst zwei Laufzeiten (CoreCLR, CoreRT ist eine Laufzeit, die auf dem Just-in-Time-Compiler (JIT) basiert und den plattformübergreifenden Open-Source-Compiler RyuJIT verwendet Ein AOT-Compiler (AOT) kann RyuJIT zur Implementierung der AOT-Kompilierung verwenden oder andere AOT-Compiler verwenden. Da AOT IL im Voraus in Maschinencode kompiliert, bietet es auch eine bessere Startgeschwindigkeit und Energieeinsparungen auf Mobilgeräten.

Abschließend möchte ich Roslyn erwähnen, einen plattformübergreifenden Open-Source-Quellcode-Compiler. Er unterscheidet sich von den beiden Compilern, die gerade verwendet werden, um IL in nativen Maschinencode zu kompilieren, während Roslyn C# kompiliert VB.NET-Code wird in eine Programmzwischensprache (IL) kompiliert.

Roslyn Compiler

Der Roslyn-Compiler wird zum Kompilieren von C#- oder VB.NET-Code in eine Assembly (Assembly) verwendet. Der Kompilierungsprozess ist ein Pipeline-Prozess, der insgesamt 4 Schritte umfasst.

compiler pipeline

A. Parser (Analyse)

Analysieren Sie den Quellcode gemäß der Grammatik.

B. Erklärung

Generieren Sie Metadaten (Metadaten) für den Code. Metadaten sind eine Sammlung von Datentabellen, die die im aktuellen Code definierten Datentypen und Mitglieder sowie die referenzierten Typen und Mitglieder beschreiben.

C. Bind

Binden Sie den generierten IL-Code an die ihn beschreibenden Metadaten, um ein verwaltetes Modul zu generieren.

D. Emittieren (Generieren)

Kombinieren Sie ein oder mehrere verwaltete Module, um eine Baugruppe zu generieren.

RyuJIT-Compiler

Wenn eine bestimmte Methode ausgeführt werden muss, während das Programm ausgeführt wird, muss die kompilierte IL zunächst in den lokalen Maschinencode konvertiert werden, und diese Aufgabe wird an RyuJIT übergeben. Es handelt sich um eine neue Generation von JIT-Compilern, die erstmals die AMD64-Architektur implementiert. RyuJIT kann Code schneller als JIT64 (Compiler der vorherigen Generation) generieren, um die Effizienz der Programmausführung zu verbessern.

CoreCLR und CoreRT

.NET Core Runtime (CoreCLR) und .NET Core Runtime (CoreRT) sind beide .NET Core Runtimes (Runtime). Sie bieten ähnliche Kernfunktionen wie .NET Framework CLR (Speicherverwaltung, Laden von Assemblys, Sicherheit, Ausnahmen, Thread-Verwaltung). usw.), kann von allen laufzeitorientierten Sprachen verwendet werden.

Der Unterschied zwischen CoreRT und CoreCLR besteht darin, dass CoreRT eine Reihe von AOT-Mechanismen bereitstellt, mit denen .NET Core-Programme in nativen Code kompiliert und auf dem Hostcomputer ausgeführt werden können, ohne auf die .NET-Laufzeit angewiesen zu sein. Darüber hinaus werden die meisten Funktionscodes der beiden Laufzeiten gemeinsam genutzt, beispielsweise GC. Die Optimierung von AOT bringt viele Vorteile:

  • Nach der Kompilierung wird eine einzelne Datei generiert, die alle Abhängigkeiten enthält, einschließlich CoreRT. Es ist nicht erforderlich, das Framework zu installieren

  • Beim Start handelt es sich um Maschinencode. Es ist nicht erforderlich, Maschinencode zu generieren oder den JIT-Compiler zu laden

  • Andere optimierende Compiler können verwendet werden, einschließlich LLILC, IL to CPP

CoreRT bietet zwei Möglichkeiten, IL direkt in Maschinencode zu kompilieren. Die andere Möglichkeit besteht darin, IL in Maschinencode zu kompilieren Rufen Sie den C++-Compiler der entsprechenden Plattform auf, um ihn zu optimieren und in Maschinencode zu kompilieren.

Verwenden Sie RyuJIT zum Kompilieren in Maschinencode

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

C++-Code kompilieren und generieren

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

CoreRT weist auch Mängel auf. Es muss für verschiedene Plattformen einmal kompiliert werden. Allerdings hat alles seine eigenen Einschränkungen. Es ermöglicht Entwicklern, nicht auf Plattformen zu veröffentlichen, die sie nicht unterstützen möchten (z. B. unterstützt ein Spiel nur Desktops und keine Mobiltelefone). .

Hinweis: Diese beiden Namen können in der .NET Core RC2-Version nicht verwendet werden. Laut offizieller Aussage wurde dieser Befehl in der aktuellen Version entfernt. Die endgültige Situation wird erst am 27. Juni bekannt gegeben >

CoreFX(.NET Core-Bibliotheken)

CoreFX enthält hauptsächlich mehrere öffentliche Bibliotheken wie System.Collections, System.IO, System.Xml usw. CoreFX ist eine Implementierung der .NET Standard Library und .NET Framework 4.6.3 basiert ebenfalls auf der .NET Standard Library. Sie basieren derzeit auf der .NET Standard Library Version 1.6, Einzelheiten finden Sie in der folgenden Tabelle:

Detaillierte Analyse des .NET Core-Kompositionssystems (Bild)

Entwicklung, Bereitstellung und Ausführung des .NET Core-Codes

Detaillierte Analyse des .NET Core-Kompositionssystems (Bild)

Aus der Abbildung oben können Sie ersehen, dass die Verwendung von JIT zum Kompilieren und die Verwendung von AOT zum Kompilieren des Quellcodes und zum Ausführen des Programms zwei verschiedene Prozesse sind.

Wenn Sie einen JIT-Compiler zum Bereitstellen eines Programms verwenden, müssen Sie das Programm nur als IL-Assemblys packen. Der Compiler kompiliert die IL in den Zielmaschinencode (nativen Code), bevor die Methode zum ersten Mal ausgeführt wird, und führt eine AOT-Kompilierung durch kompiliert den Quellcode während der Kompilierung direkt in den Zielmaschinencode.

AOT kompiliert Quellcode in Maschinencode und weist die folgenden Eigenschaften auf:

  • Ersetzen Sie Reflection durch statischen Code. Wenn ein Werttyp beispielsweise die Gleichheitsmethode von ValueType.Equals nicht überschreibt, wird er Detaillierte Analyse des .NET Core-Kompositionssystems (Bild)mäßig als gleich beurteilt. Reflection wird verwendet, um zu ermitteln, ob die Typen gleich sind. und vergleichen Sie dann die Werte gleich. Da bei der AOT-Kompilierung die Reflexion ersetzt wird, können nur die Werte auf Gleichheit verglichen werden.

  • Die abhängigen Bibliotheken von Drittanbietern und .NET-Bibliotheken werden in das endgültige kompilierte Programm gepackt.

  • Das gepackte Programm läuft auf einer optimierten Version der Laufzeit (CoreRT), die hauptsächlich einen Garbage Collector enthält, und die Laufzeit wird auch in der App-Datei gepackt.

  • Obwohl der Reflexionscode während der Kompilierung ersetzt wird, können Sie nichts tun, wenn Sie auf dynamischen Reflexionscode stoßen. Wenn zur Laufzeit ein dynamischer Reflexionsaufruf auftritt, wird eine Ausnahme ausgelöst, da die entsprechenden Metadaten und die entsprechende Implementierung nicht gefunden werden können. Die Lösung besteht darin, die Laufzeitdirektivendatei vor der Kompilierung zu konfigurieren, um die zu verwendende Assembly anzugeben.

Zusammenfassung

In diesem Abschnitt wird die Struktur von .NET Core vorgestellt, einschließlich mehrerer neuer Compiler und CoreFX, die der .NET-Standardbibliothek folgen. Im Allgemeinen ist .NET Core hinsichtlich Leistung und Entwicklungseffizienz viel besser. Der Schlüssel besteht darin, zum ersten Mal den grundlegenden Technologie-Stack der vollständigen plattformübergreifenden Funktionen von .NET zu realisieren.

.NET Core basiert auf plattformübergreifenden Funktionen und hat keine APIs mit engem Bezug zur GUI auf .NET Core portiert. Daher wurden Windows Forms oder Windows Presentation Foundation (WPF) nicht auf .NET Core portiert. .NET Core unterstützt Projekte vom Typ Konsolenanwendung und Klassenbibliothek.

Allerdings verwendet Microsoft .NET Core in seiner Entwicklungsplattform Universal Windows Platform (UWP) und nutzt die .NET Native-Technologie, um die Leistung auf eine Geschwindigkeit zu steigern, die der von nativem Code sehr nahe kommt.

ASP.NET Core verwendet eine Konsolenanwendung, um seine Hosting-Umgebung Kestrel Server zu steuern und die Ausführung von ASP.NET Core-Programmen zu unterstützen.

Das obige ist der detaillierte Inhalt vonDetaillierte Analyse des .NET Core-Kompositionssystems (Bild). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn