Analyse détaillée du système de composition .NET Core (photo)

L'article précédent a présenté le statut de .NET Core dans l'ensemble de la plateforme .NET et sa relation avec le .NET Framework (lien d'origine). Cet article présentera en détail la composition du framework .NET Core et les principales fonctions de chaque module. , ainsi que comment réaliser une multiplateforme.

La figure ci-dessus décrit la composition du système de .NET Core. La couche supérieure est la couche d'application, qui est un ensemble de cadres pour le développement d'applications basées sur l'interface utilisateur, notamment ASP.NET Core (utilisé pour créer des applications Web) et UWP (utilisé pour créer des applications Web). Applications Windows 10).

La couche intermédiaire est une bibliothèque publique (CoreFX), qui implémente la bibliothèque Analyse détaillée du système de composition .NET Core (photo) .NET et inclut des opérations courantes au niveau du système telles que (fichiers, réseaux, etc.).

Sous CoreFx se trouve l'environnement d'exécution. .NET Core comprend deux environnements d'exécution (CoreCLR, CoreRT est un environnement d'exécution basé sur un compilateur juste à temps (JIT), qui utilise le compilateur open source multiplateforme RyuJIT, et CoreRT est un environnement d'exécution qui utilise). un compilateur anticipé (AOT). Il peut utiliser RyuJIT pour implémenter la compilation AOT ou utiliser d'autres compilateurs AOT. Étant donné qu'AOT compile IL en code machine à l'avance, il offre également une meilleure vitesse de démarrage et des économies d'énergie sur les appareils mobiles.

Enfin, je voudrais mentionner Roslyn, un compilateur de code source multiplateforme open source. Il est différent des deux compilateurs actuels. Les compilateurs JIT et AOT sont principalement utilisés pour compiler IL en code machine natif, tandis que Roslyn compile C# ou. Le code VB.NET est compilé dans un langage intermédiaire de programme (IL).

Compilateur Roslyn

Le compilateur Roslyn est utilisé pour compiler du code C# ou VB.NET dans un assembly (assembly). Son processus de compilation est un processus de type pipeline qui contient un total de 4 étapes. Le processus spécifique est illustré dans la figure ci-dessous.

​A. Analyseur (analyse)

Analysez le code source selon la grammaire.

​Déclaration B.

Générer des métadonnées (métadonnées) pour le code. Les métadonnées sont une collection de tables de données qui décrivent les types de données et les membres définis dans le code actuel, ainsi que les types et les membres référencés.

​C. Lier

Liez le code IL généré aux métadonnées le décrivant pour générer un module géré.

​D. Émettre (Générer)

Combinez un ou plusieurs modules gérés pour générer un assembly.

Compilateur RyuJIT

Lorsqu'une certaine méthode doit être exécutée pendant l'exécution du programme, l'IL compilé doit d'abord être converti en code machine local, et cette tâche est confiée à RyuJIT. Il s'agit d'une nouvelle génération de compilateur JIT qui implémente pour la première fois l'architecture AMD64. RyuJIT peut générer du code plus rapidement que JIT64 (compilateur de génération précédente) pour améliorer l'efficacité d'exécution du programme.

CoreCLR et CoreRT

.NET Core Runtime (CoreCLR) et .NET Core Runtime (CoreRT) sont tous deux des runtimes .NET Core (Runtime). Ils fournissent des fonctions de base similaires au .NET Framework CLR (gestion de la mémoire, chargement de l'assembly, sécurité, exceptions, gestion des threads, etc.), peut être utilisé par tous les langages orientés runtime.

La différence entre CoreRT et CoreCLR réside dans le fait que CoreRT fournit un ensemble de mécanismes AOT capables de compiler des programmes .NET Core en code natif et de s'exécuter sur la machine hôte sans dépendre du runtime .NET. De plus, la plupart des codes fonctionnels des deux runtimes sont partagés, comme GC. L'optimisation de l'AOT apporte de nombreux avantages :

• Après la compilation, un seul fichier est généré, qui contient toutes les dépendances, y compris CoreRT. Il n'est pas nécessaire d'installer le Framework

  .

• Il s'agit du code machine au démarrage. Il n'est pas nécessaire de générer du code machine ou de charger le compilateur JIT

• D'autres compilateurs d'optimisation peuvent être utilisés, notamment LLILC, IL to CPP

CoreRT a deux façons de générer du code machine. La première consiste à compiler directement IL en code machine. Par défaut, RyuJIT agit comme un compilateur AOT pour compiler IL en code machine. appelez le compilateur C de la plateforme correspondante pour l'optimiser et le compiler en code machine.

​Utilisez RyuJIT pour compiler en code machine

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

​Compiler et générer du code C

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

CoreRT présente également des inconvénients : il doit être compilé une seule fois pour différentes plates-formes ; mais tout a ses propres limites. Il permet aux ingénieurs de ne pas publier sur des plates-formes qu'ils ne souhaitent pas prendre en charge (par exemple, un jeu ne prend en charge que les ordinateurs de bureau et non les téléphones mobiles). .

Remarque : Ces deux noms ne peuvent pas être utilisés dans la version .NET Core RC2. Selon le communiqué officiel, cette commande a été supprimée dans la version actuelle. La situation finale ne sera connue qu'après la sortie de la version officielle le 27 juin

CoreFX (Bibliothèques .NET Core)

CoreFX contient principalement plusieurs bibliothèques publiques, telles que System.Collections, System.IO, System.Xml, etc. CoreFX est une implémentation de la bibliothèque Analyse détaillée du système de composition .NET Core (photo) .NET et .NET Framework 4.6.3 est également basé sur la bibliothèque Analyse détaillée du système de composition .NET Core (photo) .NET. Ils sont actuellement basés sur la .NET Standard Library version 1.6, voir le tableau ci-dessous pour plus de détails :

Développement, déploiement et processus d'exécution de code .NET Core

Dans l'image ci-dessus, vous pouvez voir que l'utilisation de JIT pour compiler et l'utilisation d'AOT pour compiler le code source et exécuter le programme sont deux processus différents.

Si vous utilisez le compilateur JIT pour déployer un programme, il vous suffit de conditionner le programme sous forme d'assemblys IL. Le compilateur compilera l'IL dans le code machine cible (code natif) avant la première exécution de la méthode et la compilation AOT. compilera le code source lors de la compilation. Directement compilé dans le code machine cible.

AOT compile le code source en code machine et présente les caractéristiques suivantes :

• Remplacez la réflexion par du code statique. Par exemple, si un type de valeur ne remplace pas la méthode égale de ValueType.Equals, il sera jugé égal par défaut. La réflexion sera utilisée pour rechercher les informations de fichier afin de déterminer si les types sont égaux. puis comparez les valeurs égales. Dans la compilation AOT, la réflexion étant remplacée, seules les valeurs peuvent être comparées pour l'égalité.

• Les bibliothèques tierces dépendantes et les bibliothèques .NET sont regroupées dans le programme compilé final.

• Le programme packagé s'exécute sur une version simplifiée du runtime (CoreRT), qui comprend principalement un garbage collector, et le runtime sera également packagé dans le fichier de l'application.

• Bien que le code de réflexion soit remplacé lors de la compilation, vous ne pouvez rien faire lorsque vous rencontrez du code de réflexion dynamique. Si un appel de réflexion dynamique est rencontré au moment de l'exécution, une exception sera levée car les métadonnées et l'implémentation correspondantes sont introuvables. La solution consiste à configurer le fichier de directives d'exécution avant la compilation pour spécifier l'assembly à utiliser.

Résumé

Cette section présente la structure de .NET Core, y compris plusieurs nouveaux compilateurs et CoreFX qui suivent la bibliothèque Analyse détaillée du système de composition .NET Core (photo) .NET. De manière générale, .NET Core est bien meilleur que le précédent .NET Framework en termes de performances et d'amélioration de l'efficacité du développement. La clé est de réaliser pour la première fois la pile technologique de base des capacités multiplateformes complètes de .NET.

.NET Core est basé sur des fonctionnalités multiplateformes et n'a pas porté les API fortement liées à l'interface graphique vers .NET Core. Par conséquent, Windows Forms ou Windows Présentation Foundation (WPF) n'ont pas été portés sur .NET Core. .NET Core prend en charge les projets de type application console et bibliothèque de classes.

Cependant, Microsoft utilise .NET Core dans sa plateforme de développement Universal Windows Platform (UWP) et utilise la technologie .NET Native pour améliorer ses performances à une vitesse très proche du code natif.

ASP.NET Core utilise une application console pour piloter son environnement d'hébergement Kestrel Server afin de prendre en charge l'exécution des programmes ASP.NET Core.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!