[.net 物件導向程式設計深入]（8）認識.NET Core

[.net 物件導向程式設計深入]（8）認識.NET Core

1，概述

.NET 經歷14年，在Windows平臺上的表現已經相當優秀，但是“跨平臺、開源”卻是其痛點，從16年開始.NET Core的出現將迎來.NET的真正意義上的跨平臺和開源序幕。

.NET Core是一個開源通用的開發框架，支援跨平臺，即支援在Window，macOS，Linux等系統上的開發和部署，並且可以在硬體裝置，雲服務，和嵌入式/物聯網方案中進行使用。

.NET Core的原始碼放在GitHub上，由微軟官方和社群共同支援。

下面瞭解一下.NET Framework和.NET Core這兩個分支的異同。

.NET 開源專案：https://github.com/dotnet （包括standard、corefx（.NET 庫）、coreclr（NET Core 執行時）、roslyn（Roslyn 編譯器（C# 和 Visual Basic）和適用於 Visual Studio 的語言工具）、cli（命令列介面和工具）、orleans，此外還有一些文件包括：docs、docfx等）

2，NET Framework和.NET Core的結構體系

a.NET Framework 包含,Windows Form,WPF,ASP.NET

b.NET Core 包含，UWP,ASP.NET Core

c.Xamarin，新的.NET還包括第三個部分，即XAMARIN用於構建移動APP，包含iOS、 OS X 、Android等。

即所謂的.NET三架馬車，下面是最新的.NET生態體系圖：

從上圖可以看出，.NET Framework和.NET Core及XAMARIN將是現在及未來.NET的三大部分，而它們三個都是獨立於各自的，但都基於.NET標準庫。

3，NET Framework和.NET Core特點

.NET Core較之前的.NET Framework 從效能和開發效率上都有很大的提升。關鍵是首次實現了.NET的完全跨平臺能力的基礎技術棧。

.NET Core 基於跨平臺能力，並沒有將與 GUI 高度相關的 API 移植到 .NET Core 內，因此像是 Windows Forms 或是 Windows Presentation Foundation (WPF) 並未移植到 .NET Core。

.NET Core 支援控制檯應用程式 (Console Application) 以及類庫 (Class Library) 型別的專案。

不過微軟在其 Universal Windows Platform (UWP) 開發平臺使用了 .NET Core，並且利用 .NET Native 技術將其效能提升至十分接近原生碼的速度。

ASP.NET Core 則以控制檯應用程式驅動其託管環境 Kestrel Server 以支援 ASP.NET Core 程式的執行。

a..NET Framework

（1）Windows應用程式的王者框架:.NET Framework用於建立基於Windows系統的應用程式，包括Windows From、WPF、ASP.NET MVC等。在Windows框架下的開發。.NET Framework仍是強項，今後一段時間將繼續更新升級。

（2）開發語言選擇：可選用C#,VB.NET,F#等眾多語言開發。

b..NET Core

（1）跨平臺 .NET Core 是微軟推出的最新的跨平臺的框架，用它可以建立的應用可以執行在MAC，Linux上。 .NET Core 支援UWP 和 ASP.NET Core，UWP即Windows 10 中的Universal Windows Platform簡稱。即Windows通用應用平臺，在Win 10 Mobile/Surface(Windows平板電腦）/PC/Xbox/HoloLens等平臺上執行，uwp不同於傳統pc上的exe應用也跟只適用於手機端的app有本質區別。它並不是為某一個終端而設計，而是可以在所有windows10裝置上執行。

（2）開源 .NET Core從屬於.NET基金會，由微軟進行官方支援。使用MIT和Apache 2開源協議，文件協議遵循CC-BY

（3）相容性：從前面的圖上看出.NET Core和.NET Framework基於.NET Standard Library。因此與.NET Framework，Xamarin，Mono等相容。

（4）靈活部署機制：第一種.Portable applications(行動式應用)這種部署機制和傳統的.NET Framework相似，只要目標平臺上存在.NET Core Runtime即可。

第二種.Self-contained application（自宿主應用）顧名思義，這種部署機制將應用和執行時共同打包，即便目標平臺上沒有安裝.NET Core Runtime也能正常使用第二種方式和.NET Native也是不一樣的，仍然使用 CoreCLR，而.NET Native使用CoreRT作為執行時，詳細資訊請見dotnet/corert

（5）命令列工具:.NET程式所有的執行指令碼都可以用命令列工具執行(cmd，bash)。

（6）語言選擇：.NET Core 1.0版本中支援的程式語言僅有C#（F#和VB暫未實現）

4，.NET Core構成體系

上面說到.NET的三駕馬車，.NET Framework、.NET Core、XAMARIN,下面主要看一下.NET Core的組成

如上圖，NET Core 構成體系：

（1） Runtime 在.NET Core 中有實現兩種RunTime，NativeRuntime 和 CoreCLR。NativeRuntime 將C# 或 VB.net 程式碼直接轉換為原生機器碼。而CoreCLR是一個開源的JIT執行時，會將程式碼編譯成中間語言（IL）在最終執行時再轉換機器碼。

（2） Unified BCL Base Classlibrary即基礎類，例如 FileSystem、Console、XML操作等。

（3） Windows Store AppModel & ASP.NET Core 1.0 提供開發Windows系統的各種觸屏裝置和ASP.NET程式的一組基礎庫。

5，.NET Core各個功能模組

如上圖：

應用層： .NET Core的系統構成，最上層是應用層，是開發基於UI應用的框架集，包括了ASP.NET Core(用於建立web app)，和 UWP(用於建立Windows10 app)。

中間層：中間層是公共庫(CoreFX)：實現了.NET Standard Library ,囊括了常用系統級操作例如（檔案、網路等）。

在CoreFx下是執行時環境，.NET Core 包含了兩種執行時(CoreCLR、CoreRT),CoreCLR是一種基於即時編譯程式(Just in time compiler,JIT)的執行時,它使用了跨平臺開源的編譯器RyuJIT,

而CoreRT是使用提前編譯器(Ahead of time compiler,AOT)的執行時,它既可以使用RyuJIT來實現AOT編譯也可以使用其他的AOT編譯器。由於AOT提前編譯IL成了機器碼，在移動裝置上也具有更好的啟動速度和節能性。

編譯器：最後還要提到一個開源的跨平臺原始碼編譯器Roslyn，它有別於剛才兩個編譯器，JIT和AOT編譯器主要用於將IL編譯成本機機器碼，而Roslyn是將C# 或 VB.NET 程式碼編譯成程式中間語言(intermediate language,IL)。

下面介紹這個編譯器。

（1）、.NET Core的Roslyn 編譯器

Roslyn編譯器用於將C#或VB.NET程式碼編譯為程式集(assembly)，它的編譯過程是一個管道式的處理過程一共包含4個步驟，具體過程見下圖。

A. Parser(解析)

根據語法對原始碼進行解析。

B. Declaration (宣告)

為程式碼生成後設資料(metadata),後設資料是一個資料表的集合，描述了在當前程式碼中定義的資料型別和成員，同時也描述了引用的型別及成員。

C. Bind(繫結)

將生成的IL程式碼與描述它的後設資料繫結在一起，生成託管模組(managed module)。

D. Emit(生成)

將一個或多個託管模組合併生成程式集(assembly)。

（2）RyuJIT 編譯器

在程式執行中需要執行某一個方法，首先需要將已經編譯好的IL轉換本機的機器碼，而這個任務就交給了RyuJIT。它是新一代JIT編譯器，第一次實現了AMD64的架構，RyuJIT能夠比JIT64(上一代編譯器)更快地生成程式碼，以提高程序執行效率(測試詳情連結)。

（3) CoreCLR & CoreRT

CoreCLR 和 CoreRT 都是.NET Core的執行時(Runtime),它們提供了與.NET Framework CLR 類似的核心功能(記憶體管理、程式集載入、安全性、異常、執行緒管理等)，可由面向於執行時的所有語言使用。

CoreRT 和 CoreCLR 不同的是，CoreRT 提供了一套AOT 的機制,可以將.NET Core程式編譯成原生程式碼，不依賴 .NET 執行時而執行在宿主機器上。

除此之外兩個執行時大部分功能程式碼是共享的，比如GC。AOT的優化帶來不少好處：

編譯後生成一個單檔案，包含所有的依賴，包括 CoreRT，無需安裝Framework

啟動時是機器碼，不需要生成機器碼，也不要載入JIT編譯器

可以使用其他優化編譯器，包括 LLILC ,IL to CPP

CoreRT有兩個方式生成機器碼，第一個使用是直接編譯IL成機器碼，預設情況下，RyuJIT 作為一個 AOT 編譯器將IL編譯成機器碼，另一個方式是將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

CoreRT也有不足之處，它需要為不同平臺編譯一次；但凡事有但是，它允許工程師可以不釋出到不想支援的平臺（比如某遊戲僅支援桌面，不支援手機）。

（4） CoreFX(.NET Core Libraries)

CoreFX主要包含數個公共庫，例如 System.Collections, System.IO, System.Xml等。CoreFX是 .NET Standard Library 的實現，同樣的.NET Framework 4.6.3也是基於.NET Standard Library的實現。它們目前都是基於.NET Standard Library1.6版本，具體見下表：

6、.NET Core 程式碼開發、部署、執行過程

從上圖可以看到使用JIT編譯和使用AOT編譯原始碼並執行程式是兩種不同的流程。

如果使用JIT編譯器部署程式時只需要將程式打包為IL的assemblies，在方法第一次執行前編譯器將IL編譯為目標機機器碼(Native code)，而AOT編譯會在編譯時將原始碼直接編譯為目標機機器碼。

AOT將原始碼編譯為機器碼，擁有如下特性：

（1）用靜態程式碼替換反射，例如如果一個值型別(value type)沒有重寫 ValueType.Equals 的equals的方法，預設情況判斷相等，會使用反射找到filedinfo以確定type是否相等，然後再比較value是否相等。而在AOT編譯中由於替換了反射因此只能比較value是否相等。

（2）依賴的第三方類庫以及.NET Libraries均打包至最終編譯的程式中。

（3）打包後的程式執行在一個精簡版的執行時上(CoreRT)主要包含垃圾回收器，而執行時也會打包在app檔案中。

（4）雖然編譯時會替換反射程式碼，但遇動態反射程式碼無能為力，執行時若遇動態反射呼叫則會因找不到對應的後設資料及實現而丟擲異常。解決辦法是編譯前配置執行時指令檔案(Runtime directive file)指定需要用到的程式集。

7，總結

主要介紹了.NET的三駕馬車.NET Framework、.NET Core、Xamarin，.NET Framework是開發基於Windows平臺的王者框架，而.NET Core的跨平臺特性、開源及靈活的部署機制將是.NET的未來。後面介紹了.NET Core的組成、.NET Core主要功能模組：應用層、中間層、編譯器。最後簡要介紹了.NET Core的開發、部署、執行流程。

（宣告：本文內容參考了一些資料和部落格，如有侵權，請告知，第一時間刪、改。）

==============================================================================================

返回目錄

<如果對你有幫助，記得點一下推薦哦，如有有不明白或錯誤之處，請多交流>

<轉載宣告：技術需要共享精神，歡迎轉載本部落格中的文章，但請註明版權及URL>

軟體管理及.NET 技術交流群：467189533