這次我們翻譯了一篇Unity官方部落格上的文章，原文題目為AN INTRODUCTION TO IL2CPP INTERNALS ，作者是從事Unity軟體開發的Joshua Peterson。文章的看點在於，它是以IL2CPP內部開發人員的角度來講述的，所以對於開發者來說非常有參考價值。

如果你對Mono，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.方法呼叫介紹（一般方法呼叫和虛方法呼叫等）

1. 通用程式碼共享的實現
   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
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯絡作者獲得授權並註明出處。