這次我們翻譯了一篇Unity官方博客上的文章，原文題目為AN INTRODUCTION TO IL2CPP INTERNALS ，作者是從事Unity軟體開發的Joshua Peterson。文章的看點在於，它是以IL2CPP內部開發人員的角度來講述的，所以對於開發者來說非常有參考價值。 AN IN ...
這次我們翻譯了一篇Unity官方博客上的文章，原文題目為AN INTRODUCTION TO IL2CPP INTERNALS ，作者是從事Unity軟體開發的Joshua Peterson。文章的看點在於，它是以IL2CPP內部開發人員的角度來講述的，所以對於開發者來說非常有參考價值。
AN INTRODUCTION TO IL2CPP INTERNALS
作者：Joshua Peterson
翻譯：Bowie
大約在一年以前，我們寫了一篇博客討論Unity中腳本將來會是個什麼樣子，在那篇博客中我們提到了嶄新的IL2CPP後端，並許諾其會為Unity帶來更高效和更適合於各個平臺的虛擬機。在2015年的一月份，我們正式發佈了第一個使用IL2CPP的平臺：iOS 64-bit。而隨著Unity 5的發佈，又帶給大家另一個使用IL2CPP的平臺：WebGL。感謝我們社區中用戶的大量寶貴的反饋，我們在接下來的時間里根據這些反饋得以更新IL2CPP，發佈補丁版本，從而持續的改進IL2CPP的編譯器和運行時庫。
我們沒有停止改進IL2CPP的打算，但是在目前這個時間點上，我們覺得可以回過頭來抽出點時間告訴大家一些IL2CPP的內部工作機制。在接下來的幾個月的時間里，我們打算對以下話題（或者還有其他未列出的話題）進行討論，來做一個IL2CPP深入講解系列。目前準備討論的話題有：
1.基礎 - 工具鏈和命令行參數（本篇博文）
2.IL2CPP生成代碼介紹
3.IL2CPP生成代碼調試小竅門
4.方法調用介紹（一般方法調用和虛方法調用等）
- 通用代碼共用的實現
6.P/invoke(Platform Invocation Service)對於類型（types）和方法（methods）的封裝
7.垃圾回收器的集成
8.測試框架（Testing frameworks）及其使用
為了能讓這個系列的討論成為可能，我們會涉及到一些將來肯定會進行改動的IL2CPP的實現細節。但這也沒有關係，通過這些討論，我們希望能給大家提供一些有用和有趣的信息。
什麼是IL2CPP？
從技術層面上來說，我們說的IL2CPP包含了兩部分：一個進行 預先編譯（譯註：ahead-of-time，又叫AOT，以下一律使用AOT縮寫）的編譯器。
一個支持虛擬機的運行時庫
AOT編譯器將由.NET 輸出的中間語言(IL)代碼生成為C++代碼。運行時庫則提供諸如垃圾回收，與平臺無關的線程，IO以及內部調用（C++原生代碼直接訪問托管代碼結構）這樣的服務和抽象層。
AOT編譯器
IL2CPP AOT編譯器實際的執行文件是il2cpp.exe。在Windows平臺你可以在Unity安裝路徑的Editor\Data\il2cpp目錄下找到。對於OSX平臺，它位於Unity安裝路徑的Contents/Frameworks/il2cpp/build目錄內。 il2cpp.exe這個工具是一個托管代碼可執行文件，其完全由C#寫成。在開發IL2CPP的過程中，我們同時使用.NET和Mono編譯器對其進行編譯。
il2cpp 接受來自Unity自帶的或者由Mono編譯器產生的托管程式集，將這些程式集轉換成C++代碼。這些轉換出的C++代碼最終由部署目標平臺上的C++編譯器進行編譯。
你可以參照下圖理解IL2CPP工具鏈的作用：
IL2CPP工具鏈
運行時庫
IL2CPP的另外一個部分就是對虛擬機提供支持的運行時庫。我們基本上是用C++代碼來實現整個運行時庫的（好吧，其實裡面還是有一些和平臺相關的代碼使用了程式集，這個只要你知我知便好，不要告訴別人 ）。我們把運行時庫稱之為libli2cpp，它是作為一個靜態庫被連接到最終的游戲可執行文件中。這麼做的一個主要的好處是可以使得整個IL2CPP技術是簡單並且是可移植的。
你能通過查看隨Unity一起發佈的libil2cpp頭文件來窺探其代碼組織方式（Windows平臺，頭文件在Editor\Data\PlaybackEngines\webglsupport\BuildTools\Libraries\libil2cpp\include目錄中。OSX平臺，頭文件在Contents/Frameworks/il2cpp/libil2cpp目錄中）。舉個例子，由il2cpp產生的C++代碼和libil2cpp之間的介面API，存在於codegen/il2cpp-codegen.h這個文件中。
運行時的另外一個重要的部分，就是垃圾收集器。在Unity 5中，我們使用libgc垃圾收集器。它是一個典型的貝姆垃圾收集器（Boehm-Demers-Weiser garbage collector）。（譯註：相對使用保守垃圾回收策略）。然而我們的libil2cpp被設計成可以方便使用其他垃圾回收器。因此我們現在也在研究集成微軟開源的垃圾回收器（Microsoft GC）。對於垃圾回收器這一點，我們會在後續的一篇中專門的討論，這裡就不多說了。
il2cpp是如何執行的？
讓我們從一個簡單的例子入手。這裡使用Unity的版本是5.0.1，在Windows環境並且建立一個全新的空項目。然後創建一個帶MonoBehaviour的腳本文件，將其作為組件加入到Main Camera上。代碼也是非常的簡單，輸出Hello World：
- using UnityEngine;
- public class HelloWorld : MonoBehaviour {
- void Start () {
- Debug.Log("Hello, IL2CPP!");
- }
- }
當我切換到WebGL平臺進行項目生成的時候，我們可以用Process Explorer來對il2cpp的命令行進行觀察，得到以下內容：
"C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\bin\mono.exe" "C:\Program Files\Unity\Editor\Data\il2cpp/il2cpp.exe" --copy-level=None --enable-generic-sharing --enable-unity-event-support --output-format=Compact --extra-types.file="C:\Program Files\Unity\Editor\Data\il2cpp\il2cpp_default_extra_types.txt" "C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\Managed\Assembly-CSharp.dll" "C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\Managed\UnityEngine.UI.dll" "C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\il2cppOutput"
嗯，這個真是老太太的裹腳布 - 又臭又長......，所以讓我們把命令分拆一下，Unity運行的是這個可執行文件：
"C:\Program Files\Unity\Editor\Data\MonoBleedingEdge\bin\mono.exe"
下一個參數是il2cpp.exe工具本身：
"C:\Program Files\Unity\Editor\Data\il2cpp/il2cpp.exe"
請註意剩下的參數其實都是傳遞給il2cpp.exe的而不是mono.exe。上面的例子里傳遞了5個參數給il2cpp.exe：
–copy-level=None
指明il2cpp.exe不對生成的C++文件進行copy操作
–enable-generic-sharing
告訴IL2CPP如果可以，對通用方法進行共用。這個可以減少代碼並降低最後二進位文件的尺寸
–enable-unity-event-support
確保和Unity events相關的，通過反射機制來運作的代碼，能夠正確生成。
–output-format=Compact
在生成C++代碼時為裡面的類型和方法使用更短的名字。這會使得C++代碼難以閱讀，因為原來在IL中的名字被更短的取代了。但好處是可以讓C++編譯器運行的更快。
–extra-types.file=”C:\Program Files\Unity\Editor\Data\il2cpp\il2cpp_default_extra_types.txt”
使用預設的（也是空的）額外類型文件。il2cpp.exe會將在這個文件中出現的基本類型或者數組類型看作是在運行時生成的而不是一開始出現在IL代碼中來對待。
需要註意的是這些參數可能會在以後的Unity版本中有所變化。我們現在還沒有穩定到把il2cpp.exe的命令行參數整理固定下來的階段。
最後，我們有由兩個文件組成的一個列表和一個目錄在這個長長的命令行中：
“C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\Managed\Assembly-CSharp.dll”
“C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\Managed\UnityEngine.UI.dll”
“C:\Users\Josh Peterson\Documents\IL2CPP Blog Example\Temp\StagingArea\Data\il2cppOutput”
il2cpp.exe工具可以接收一個由IL程式集組成的列表。在上面這個例子中，程式集包含了項目中的簡單腳本程式集：Assembly-CSharp.dll，和GUI程式集：UnityEngine.UI.dll。大家可能會註意到這裡面明顯少了什麼：UnityEngine.dll到哪去了？系統底層的mscorlib.dll也不見了蹤影。實際上，il2cpp.exe會在內部自動引用這些程式集。你當然也可以把這些放入列表中，但他們不是必須的。你只需要提及那些根程式集（那些沒有被其他任何程式集引用到的程式集），剩下的il2cpp.exe會根據引用關係自動加入。
裹腳布的最後一塊是一個目錄，il2cpp.exe會將最終的C++代碼生成到這裡。如果你還保持著一顆好奇的心，可以看看這個目錄中產生的文件。這些文件是我們下一個討論的主題。在你審視這些代碼前，可以考慮將WebGL構建設置中的“Development Player”選項勾上。這麼做會移除–output-format=Compact命令行參數從而讓C++代碼中的類型和方法的名字更加可讀。
嘗試在WebGL或者iOS構建設置中進行些改變。這樣你會發現傳遞給il2cpp.exe的參數也會相應的發生變化。例如，將“Enable Exceptions” 設置成“Full” 會將–emit-null-checks，–enable-stacktrace，和 –enable-array-bounds-check這三個參數加入il2cpp.exe命令行。
IL2CPP沒做的事情
我想指出IL2CPP有一向挑戰我們沒有接受,而且我們也高興我們忽略了它。我們沒有嘗試重寫整個C#標準庫。當你使用IL2CPP後端構建Unity項目的時候，所有在mscorlib.dll，System.dll等中的C#標準庫和原來使用Mono編譯時候的一模一樣。
我們可以依賴健壯的且久經考驗的C#標準庫，所以當處理有關IL2CPP的bug的時候，我們可以很肯定的說問題出在AOT編譯器或者運行時庫這兩個地方而不是在其他地方。
我們如何開發，測試，發佈IL2CPP
自從我們在一月份的4.6.1 p5版本中首次引入IL2CPP以來，我們已經連續發佈了6個Unity版本和7個補丁（Unity版本號跨越4.6和5.0）。在這些發佈中我們修正了超過100個bug。
為了確保持續的改進得以實施，我們內部只保留一份最新的開發代碼在主幹分之（trunk branch）上，在發佈各個版本之前，我們會將IL2CPP的改動掛到一個特定的分之下，然後進行測試，確保所有的bug已經正確的修正了。我們的QA和維護工作組為此付出了驚人的努力才得以保證發佈版本的快速迭代。（譯註：感覺是版本管理的標準的開發流程）
提供高質量Bug的用戶社區被證明是一個無價之寶。我們非常感謝用戶的反饋來幫助我們改進IL2CPP，並且希望這類反饋越多越好。
我們的IL2CPP研發組有很強烈的“測試優先”意識。我們時常使用“Test Driven Design”方法，在沒有進行足夠全面的測試的情況下，幾乎不會進行代碼的合併工作。這個策略用在IL2CPP項目上非常的棒。我們現在所面對的大部分bug並不是意想不到的行為產生的，而是由意想不到的特殊情況產生的。（例如在一個32位的索引數組中使用了64位的指針從而導致C++編譯器失敗）面對這種類型的bug我們可以快速的並且很自信的進行修正。
有了社區的幫助，我們非常努力的讓IL2CPP既快又穩定。順便說一句，如果你對我剛纔說的這些有興趣，我們正在招人（嗯.....我只是這麼一說）
好戲連臺
關於IL2CPP我們還有很多可以說的。下一次我們會深入到il2cpp.exe代碼生成的細節中。看看對於C++編譯器來說，由il2cpp.exe生成的代碼會是個什麼樣子。
作者：IndieACE
鏈接：https://www.jianshu.com/p/dd430c991d0b
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯繫作者獲得授權並註明出處。
