怎么理解.NET Native架構(gòu)

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)怎么理解.NET Native架構(gòu)，文章內(nèi)容豐富且以專(zhuān)業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

這里簡(jiǎn)單講一下.NET Native的基本架構(gòu)，基本內(nèi)容和上面那個(gè)talk其實(shí)差不多，只是簡(jiǎn)單給大家講一下.NET Native的一些基本概念。

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

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

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


第一步：將應(yīng)用程序的IL代碼和整個(gè).NET Framework BCL的IL一起作為輸入給MCG。MCG （Marshalling Code Generator）這一塊主要是我在負(fù)責(zé)。這個(gè)工具負(fù)責(zé)檢查程序和BCL中所有的Interop相關(guān)的類(lèi)型，比如WinRT接口，P/Invoke，等等。MCG都會(huì)為之生成C#代碼。這個(gè)C#代碼是可以直接調(diào)試的，有興趣的朋友可以F11試一下看看。C#代碼的作用主要是替代Windows.WinMD中的WinRT類(lèi)型定義，P/invoke定義，等等，添加各種類(lèi)型的轉(zhuǎn)換代碼，比如字符串類(lèi)型，RCW和CCW，等等，最終直接調(diào)用到本地代碼?？赡苡行┡笥褧?huì)問(wèn)道：為什么要生成C#? 原來(lái)的CLR是直接在運(yùn)行時(shí)生成IL代碼的，但是顯然這個(gè)方法在.NET Native不太適用，而且IL代碼很難調(diào)試。C#既方便大家調(diào)試，也方便我們快速的修改生成的代碼，添加更多的功能。（寫(xiě)C++程序生成IL代碼可是比較麻煩的，得人工算好stack的位置）

第二步：MCG生成的C#代碼通過(guò)CSC編譯，生成PE文件。這一步?jīng)]啥可講的。

第三步：這個(gè)PE文件被打包合并到應(yīng)用程序和BCL，生成一個(gè)IL代碼的集合。為下一步做好準(zhǔn)備。

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

1. 當(dāng)你在調(diào)用Windows.UI.Xaml.Controls.Button類(lèi)型的時(shí)候，MCG也會(huì)生成一個(gè)對(duì)應(yīng)的Button類(lèi)型，然后IL Transform會(huì)將兩者進(jìn)行替換，這樣程序調(diào)用的Button類(lèi)型就是MCG生成的代碼了。

2. 當(dāng)你在進(jìn)行Serialization和Deserialization的時(shí)候，IL Transform會(huì)調(diào)用另外一個(gè)工具SG來(lái)生成serialization/deserialization的C#代碼，最終這些操作都有這些C#代碼生成。

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

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

第五步:NUTC對(duì)IL進(jìn)行處理，生成MDIL。NUTC就是傳說(shuō)中的C++的編譯器后端的一個(gè)特殊版本，優(yōu)化什么的就靠它了。最后生成的MDIL接近機(jī)器碼，但是也包含一些抽象的類(lèi)型信息，需要進(jìn)一步處理。
第六步：RhBind負(fù)責(zé)對(duì)MDIL進(jìn)行處理，將里面和類(lèi)型系統(tǒng)相關(guān)的信息生成代碼，最后生成一個(gè)EXE。其實(shí)最終是一個(gè)EXE+DLL，實(shí)際的代碼都在DLL中。EXE只是起到Bootstrap的作用。選用DLL的原因是我們需要支持作為Background Task在Broker里面加載。

幾個(gè)我聽(tīng)到的常問(wèn)的問(wèn)題（如果有些答案過(guò)于“官方”，請(qǐng)諒解）：

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

答：不生成。C++后端直接從IL轉(zhuǎn)換成MDIL。

2. WPF支持嗎？

答：暫時(shí)不支持。目前暫時(shí)只支持Windows Store Apps

3. 這個(gè)會(huì)支持桌面程序嗎？

答：目前暫時(shí)只支持Windows Store Apps

4. 這個(gè)支持JIT嗎？

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

5. 既然是本地機(jī)器碼，為什么還可以支持類(lèi)型反射（reflection）？

答：機(jī)器碼和反射并不沖突，我們?cè)赑E文件中儲(chǔ)存了額外的用于反射的信息，然后動(dòng)態(tài)讀取此信息進(jìn)行調(diào)用。C++也可以支持反射（RTTI），只是不如.NET強(qiáng)大而已。

6.這個(gè)需要安裝.NET Framework嗎？

答：開(kāi)發(fā)編譯的時(shí)候需要，運(yùn)行時(shí)不需要。

7.為什么不支持VB

答：VB本質(zhì)上和C#都是生成IL，技術(shù)上非常類(lèi)似。只是目前我們因?yàn)闀r(shí)間問(wèn)題，暫只支持C#。

8.為什么啟動(dòng)運(yùn)行速度會(huì)變快？

答：一方面歸功于C++的優(yōu)秀的編譯器后端，一方面也因?yàn)閞untime的重寫(xiě)和簡(jiǎn)化。

上述就是小編為大家分享的怎么理解.NET Native架構(gòu)了，如果剛好有類(lèi)似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。