在iOS和Android上，可以通過Player Settings里面選擇Mono或者IL2CPP作為腳本后端。如果需要改變腳本后端，到Player Settings窗口（具體的菜單：Edit > Project Settings > Player）, 向下滾動到Other Settings區(qū)域，然后從下拉菜單中選擇Mono或者IL2CPP。
注意：使用2017.3的版本，選擇IL2CPP腳本后端或者Mono后端都可以。然而，WebGL和UWP只支持IL2CPP。iOS在快速開發(fā)階段仍然支持Mono腳本后端，但是不能再向Apple提交Mono(32位)的應用。
不同腳本后端的優(yōu)缺點
每個腳本后端都有自己的優(yōu)點和不足，當選擇腳本后端的時候，這些因素需要被考量：
IL2CPP
- 和Mono相比，代碼生成被大力改進
- 可以從C++代碼中能夠從上到下進行調試
- 可以開啟Engine code stripping選項來減少代碼大小
- 打包的過程要比Mono時間長
- 只支持預編譯（Ahead of Time AOT）
Mono
- 打包過程比IL2CPP快上不少
- 因為即時編譯（Just In Time compilation JIT）能夠支持更多的托管代碼庫
- 支持運行過程中代碼執(zhí)行
- 必須搭載托管的程序集（通過mono- 或者 .net- 產生的.dll文件）
小提示：在開發(fā)階段和最后發(fā)行階段使用IL2CPP后端。如果在迭代階段發(fā)現使用IL2CPP太慢，暫時切換到Mono腳本后端提高迭代速度。
注意：Player Settings中的默認目標架構是針對發(fā)行的編譯進行優(yōu)化的。在開發(fā)階段使用默認選項會增加編譯的時間因為Unity會針對選擇的每個目標平臺進行編譯：
- Android的Player Settings中默認目標架構是armv7 和 x86 with the IL2CPP 和 Mono腳本后端。
- iOS的Player Settings中默認目標架構是armv7 和 IL2CPP腳本后端的arm64。
Unity中的代碼剝離
代碼大小對硬盤空間和運行內存有著直接的影響。所以對于Unity而言，從代碼庫中移除用不上的代碼非常重要。Unity會在構建過程中自動剝離代碼，在兩個不同層面進行：
- 托管代碼的剝離
- 原生代碼的剝離
托管代碼剝離
Unity在方法層面對托管代碼進行剝離。如果想要改變剝離層面，可以在Player Settings窗口，向下拖動到Other Settings部分，定位到Stripping Level，選擇Strip Assemblies。
UnityLinker會通過中間語言(IL, Intermediate Language)移除掉沒有使用的類型（包括類，結構體等）。即使你使用了某個類型，UnityLinker也會移除掉這個類型中沒有使用的方法。
注意： 盡管這個功能在使用Mono腳本后端編譯的時候是可選的，當使用IL2CPP腳本后端編譯的時候永遠開啟。
原生代碼剝離
Unity默認開啟PlayerSettings中的Strip Engine Code選項并且開啟原生代碼剝離。開啟Strip Engine Code可以移除原生的Unity引擎代碼中未使用到的模塊和類。如果禁用Strip Engine Code則會保留原生Unity引擎代碼中所有的模塊和類型。
注意：：對于目前公開可獲取的所有平臺，原生代碼剝離只在iOS、WebGL和Android平臺上被支持。
從Unity 2017.3版本開始支持Android平臺的原生代碼剝離；而在之前的版本，Unity的運行時作為提前鏈接的.so庫，這樣的話Unity就不能夠進行剝離。在2017.3版本之后，Android的運行時是作為靜態(tài)的引擎代碼庫，支持進行原生代碼剝離。最后的鏈接過程發(fā)生的構建(Build)階段，對構建的時間會有略微的影響。
Unity 模塊剝離
注意：WebGL是目前唯一支持剝離未使用到的Unity模塊的平臺。
Unity作最大的努力嘗試移除掉所有未被使用的Unity模塊。意味著，只要在構建過程中的場景中使用或者腳本引用到了任何Unity模塊中的組件，這個模塊的代碼就不會被移除掉。Unity目前不會剝離關鍵模塊，如Camera，AssetBundle，Halo等，但是在未來的發(fā)行版本中，這些也會被剝離掉。
在WebGL平臺上從一個空項目中剝離模塊代碼
移除掉模塊代碼能夠節(jié)省大量的內存。例如，Unity模塊中最大的一個就是物理模塊，包含差不多5MB的壓縮后的ASM.js代碼。如果你從空項目中移除掉這個模塊，最后打包的體積會從17MB降到15MB。
C#代碼剝離
Unity Linker在基本的標記-清除算法上工作，類似于垃圾回收。Unity Linker會從單次Build過程中構建每個程序集中包含的類型和方法的映射。UnityLinker會將部分類型和方法標記為為“根”，然后遍歷類型和方法之間的依賴關系圖。
例如，當一個類型的方法調用了另外一個類型中的方法，UnityLinker就會標記被調用的方法為“使用中”。一旦UnityLinker標記了所有根的依賴，系統(tǒng)就會重新組織程序集，移除掉沒有被使用的方法或者整個類型。
場景，資源，程序集和AssetBundle中的根
如果類在場景或者Resources中直接引用，UnityLinker會將這些內置類作為根。類似地，UnityLinker也會將用戶程序集中使用的所有類和方法作為根。
如果你在場景中或者包括在Resources中的Asset中使用了來自其他程序集的類型或者方法，Unity也會將這些作為根。
使用 link.xml文件來標記額外的類型和方法作為根。如果你的工程使用了AssetBundle，可以使用BuildPlayerOption.assetBundleManifestPath來標記額外的類型和方法作為根。
用戶程序集
用戶程序集指的是在Assets目錄下Unity從松散的代碼中生成的程序集。Unity會將大部分的代碼放在Assembly-CSharp.dll中；然而，Unity會將放在/Assets/Standard Assets/或者/Assets/Plugins中的代碼放在Assembly-CSharp-firstpass.dll，這個DLL也被認為是用戶程序集。
如果代碼庫中很大一部分的類型和方法沒有用到，你可以通過將穩(wěn)定的代碼移動到提前編譯的程序集中，這樣UnityLinker可以剝離這些代碼中沒有沒使用到的類型和方法，這樣可以減少二進制包體和節(jié)約打包時間。使用Assembly Definition Files參考將穩(wěn)定的代碼遷移到預編譯的程序集中。
通用共享
對于引用類型而言，IL2CPP對應生成的C++代碼可以使用引用類型在生成的IL2CPP代碼中共享。然而，IL2PP并不會共享值類型，因為IL2CPP需要針對每個類型獨立生成代碼。這樣就會導致代碼體積增大。
通常來講，這樣不會導致很大的性能差異，但是這取決于特定的情況和需要被優(yōu)化的具體情況。類通常位于堆上，而結構體則通常位于棧上（有一些特殊情況，比如協程的情況）。對于內存性能和使用而言，使用空引用會導致其他的問題。你必須使用值類型來拷貝函數參數來改變性能。對于額外的信息，可以參閱如下的博客 blog post。需要指出，Integer或者Enum類型目前是沒有被共享的。
程序集定義文件
Assembly Definition Files允許你自定義托管程序集并且將腳本指定給某個程序集（以文件夾為單位）。
這樣做可以導致更快的迭代速度，因為Unity只需要構建那些被改動過腳本的程序集即可。
注意：盡管多個程序集能夠保證模塊性，但是同時也增加了應用的大小和運行內存。測試顯示每個程序集會增加4kB的運行內存。
構建報告
Build Report目前是包含在Unity內部的一個API，目前還沒有UI部分的支持。構建一個工程會產生一個buildreport文件，通過這個文件你可以發(fā)現那些部分被剝離并且為什么會從最后的執(zhí)行文件中剝離。
剝離相關的信息查看步驟：
- 構建工程
- 保持編輯器運行
- 連接上http://files.unity3d.com/build-report/.
構建報告工具會連接上正在運行的編輯器，下載并且呈現出構建日志的分解。
也可以通過binary2text工具查看Library/LatestBuild.buildreport的數據。Binary2text的目錄：
Mac ： Unity.app/Contents/Tools
Windows : Unity/Editor/Data/Tools
構建報告在Unity 5.5之后的版本中獲取·。
