怎么理解.NET Native架構

這期內容當中小編將會給大家帶來有關怎么理解.NET Native架構，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

這里簡單講一下.NET Native的基本架構，基本內容和上面那個talk其實差不多，只是簡單給大家講一下.NET Native的一些基本概念。

.NET Native和之前的NGEN有本質區別。NGEN實際上是把CLR運行時的數據結構和代碼給一鍋端（當然，這個是簡化的說法，實際上比這個復雜)的放到最終的PE里面去了，運行的時候還是需要整個.NET Framework支持，而且不能避免JIT。.NET Native是全新的技術，整個.NET Framework經過refactoring重寫，最終的runtime非常小，只有數百K，無需任何安裝（除了mrt100.dll之外，大家可以理解成msvcrt.dll）。大部分的功能都從runtime中refactor到framework中作為C#代碼或者作為toolchain一部分存在。一個典型的例子是：P/invoke原來是由CLR實現，使用C++和匯編編寫。而現在是經由MCG這個工具接手，直接生成C#。最終.NET Native生成的EXE/DLL是可以直接運行的機器碼（通過C++編譯器后端生成）。對了，有些朋友可能會問：我們是不是直接生成C++代碼？答案是否定的。我們所使用的C++編譯器后端接受IL作為輸入，生成MDIL。

整個Toolchain（工具鏈）大致可以分為下面幾個階段：

App IL + FX -> MCG　-> Interop.g.cs -> CSC -> Interop.dll -> Merge -> IL transform -> NUTC -> RhBind -> .EXE


第一步：將應用程序的IL代碼和整個.NET Framework BCL的IL一起作為輸入給MCG。MCG （Marshalling Code Generator）這一塊主要是我在負責。這個工具負責檢查程序和BCL中所有的Interop相關的類型，比如WinRT接口，P/Invoke，等等。MCG都會為之生成C#代碼。這個C#代碼是可以直接調試的，有興趣的朋友可以F11試一下看看。C#代碼的作用主要是替代Windows.WinMD中的WinRT類型定義，P/invoke定義，等等，添加各種類型的轉換代碼，比如字符串類型，RCW和CCW，等等，最終直接調用到本地代碼?？赡苡行┡笥褧柕溃簽槭裁匆蒀#? 原來的CLR是直接在運行時生成IL代碼的，但是顯然這個方法在.NET Native不太適用，而且IL代碼很難調試。C#既方便大家調試，也方便我們快速的修改生成的代碼，添加更多的功能。（寫C++程序生成IL代碼可是比較麻煩的，得人工算好stack的位置）

第二步：MCG生成的C#代碼通過CSC編譯，生成PE文件。這一步沒啥可講的。

第三步：這個PE文件被打包合并到應用程序和BCL，生成一個IL代碼的集合。為下一步做好準備。

第四步：這個IL代碼的集合會被經過若干的步驟處理，每個步驟都相對簡單，只做一件事情。這些步驟的主要作用是提供原來CLR運行時提供的功能，最終的目的是使之最后的代碼能夠被C++最后編譯。在原來桌面版本的CLR里面（也就是4.5里面的那個），很多功能是由Runtime來提供，比如Delegate.Invoke，比如interop。這些Transform的作用是對代碼進行處理，把原來需要runtime實現的部分用實際代碼替換掉。舉個幾個例子：

1. 當你在調用Windows.UI.Xaml.Controls.Button類型的時候，MCG也會生成一個對應的Button類型，然后IL Transform會將兩者進行替換，這樣程序調用的Button類型就是MCG生成的代碼了。

2. 當你在進行Serialization和Deserialization的時候，IL Transform會調用另外一個工具SG來生成serialization/deserialization的C#代碼，最終這些操作都有這些C#代碼生成。

3. 你的程序多半不會用到整個BCL。IL Transform中會有一步叫做Dependency Reducer，使用類似GC的算法（mark->sweep),去掉不需要的代碼。MCG也和DR通力合作，減少不必要的interop代碼生成。DR也會讀取RD.XML文件，決定那些類型需要反射信息，那些不需要。RD.XML這一塊我們還在改善之中，也希望大家多提寶貴意見。

其實呢，MCG其實也是IL Transform的一部分，只不過它實際上不Transform而已，而是直接生成C#。

第五步:NUTC對IL進行處理，生成MDIL。NUTC就是傳說中的C++的編譯器后端的一個特殊版本，優化什么的就靠它了。最后生成的MDIL接近機器碼，但是也包含一些抽象的類型信息，需要進一步處理。
第六步：RhBind負責對MDIL進行處理，將里面和類型系統相關的信息生成代碼，最后生成一個EXE。其實最終是一個EXE+DLL，實際的代碼都在DLL中。EXE只是起到Bootstrap的作用。選用DLL的原因是我們需要支持作為Background Task在Broker里面加載。

幾個我聽到的常問的問題（如果有些答案過于“官方”，請諒解）：

1. 你們最后是生成C++代碼嗎？

答：不生成。C++后端直接從IL轉換成MDIL。

2. WPF支持嗎？

答：暫時不支持。目前暫時只支持Windows Store Apps

3. 這個會支持桌面程序嗎？

答：目前暫時只支持Windows Store Apps

4. 這個支持JIT嗎？

答：目前.NET Native不支持JIT，所有代碼都是編譯時候生成。

5. 既然是本地機器碼，為什么還可以支持類型反射（reflection）？

答：機器碼和反射并不沖突，我們在PE文件中儲存了額外的用于反射的信息，然后動態讀取此信息進行調用。C++也可以支持反射（RTTI），只是不如.NET強大而已。

6.這個需要安裝.NET Framework嗎？

答：開發編譯的時候需要，運行時不需要。

7.為什么不支持VB

答：VB本質上和C#都是生成IL，技術上非常類似。只是目前我們因為時間問題，暫只支持C#。

8.為什么啟動運行速度會變快？

答：一方面歸功于C++的優秀的編譯器后端，一方面也因為runtime的重寫和簡化。

上述就是小編為大家分享的怎么理解.NET Native架構了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。