Unity引擎IOS執行檔大小最佳化

標籤：

     

簡介

     蘋果對於IOS執行檔的大小是有明確的限制的，其中TEXT段的大小不能超過80M，否則提審將會被蘋果拒絕，同時，如果TEXT段過於太大，那麼在蘋果進行加密之後，很容易出現解壓失敗等各種異常，最終導致遊戲無法正常運行。因此，理論上我們應該儘可能保持我們的執行檔TEXT段大小小於80M，根據經驗，始終保持在60-70M以下是相對比較保險的。請注意，這裡說的80M是包含armv7和arm64兩種架構的執行檔的TEXT段之和而並非單個架構，即單個架構的TEXT段大小不能超過40M。

     IOS的執行檔格式為mach-o格式，關於這種個是可以看蘋果的文檔或者維基百科。另外有工具Mach-o Viewer可以協助你檢閱這些資訊。

     

查看TEXT段大小的方法

     首先簡單介紹查看執行檔TEXT段大小的方法。在Mac系統下，使用XCode產生項目之後，產生的執行檔都在DerivedData目錄下，這個目錄可以使用Command + Shift + G跳轉過去，目標地址：

            ~/資產庫/Developer/Xcode/DerivedData/

     可以簡單通過子目錄的時間戳記分析出最近的產生位於哪個目錄下，依次向前即可找到產生的執行檔，這是一個包。查看包內容，裡面會有一個同名的可執行檔，此檔案可以等效於Windows下面的exe檔案。可以將其複製到案頭或者其它地方，也可以不複製。開啟終端，進入對應目錄。使用命令size即可顯示執行檔的各段的大小資料，如：

Bodong-iMac:Documents bodong$ size ./xxgame

__TEXT        __DATA __OBJC others dec hex

34373632 10518528 0 2179072 47071232 2ce4000 ./xxgame (for architecture armv7)

39534592 17203200 0 4296835072 4353572864 1037e4000 ./xxgame (for architecture arm64)

     上面加粗的資料即是TEXT段的大小，最終的TEXT段的大小為兩種架構大小之和。倘若它們之和大於80M，你的執行檔可能會被蘋果拒絕。

 

為什麼要強調Unity

     如果我們直接使用C++開發，一般來說並不會有關於TEXT段太大的問題，然而Unity不一樣，Unity使用的mono C#開發，在build時通過il2cpp將C#代碼編譯結果翻譯成C++代碼，由於il2cpp翻譯的C++代碼需要類比很多C#的行為，因此它本身產生的程式碼量會遠遠高於實現這些功能所需要的C++代碼數量。代碼體積巨大的結果就是TEXT段大小會超標，這樣會對遊戲發布產生巨大的影響。

     這裡我選擇了我自己的一個非常簡單的項目來做執行個體進行展示，代碼很少，因此並不會造成TEXT段過大的問題，但是當你的項目足夠大時，就會有問題了。這裡用於展示，原理是一樣的。

 

           

     Unity對IOS產生的結果是一個Xcode項目。其中在Classes/Native下面，就是我們產生的程式碼，如果這個檔案夾的總大小超過了300M，那請注意，你的執行檔TEXT段可能就要超標了。因此大多數的最佳化目的都是為了減小這個Native檔案夾的總大小，根據經驗，這裡減少5m左右，執行檔TEXT段就可以減少1m。   

 

具體技術細節

     有很多方法可以減少Native檔案夾的大小，這裡依依列出。另外部分最佳化的具體資料由於時間問題已經記不清了，只能記得大概的資料。

     1.一定使用Release編譯，一定使用非Development Build。

     2.項目Build Player Setting中，Api Compatibility Level一定要採用.net 2.0 subset。可減少數M。

     3.strip一定要開，unity4裡面選擇strip level選擇strip by byte code，選擇micro mscorlib可能會導致crash，可以先不考慮；unity5中勾上strip Engine Code。可減少數M。

     4.移除非必須使用的.net基礎庫，比如System.xml，可以使用其它更精簡的庫代替。比如System.xml的替代者SecurityParser。移除這個大模組後，可減少TEXT段3-5M。同理，System.Linq也應該盡量不用，其一是容量問題，其二是效率問題，其三是在iphone4s下面可能導致crash的問題。

     5.少用或不用模板。在早期的unity版本（4.6.6之前），尤為甚之。模板會導致代碼量劇烈膨脹，要查看自己的模板代碼總共貢獻了多少C++代碼，可以在native檔案夾中搜搜Generic，其中有大部分C++代碼就是模板的貢獻。

           倘若你的模板產生的C++代碼總數量大於了40m，那你應該提高警惕。造成這些暴漲的主要元兇就是System.Collection.Generic下面的各種容器，比如List，Dictionary，其解決方案就是針對class類型的類型衰減。我已經提供了新的ListView和DictionaryView，DictionaryObjectView容器，它們不會導致模板產生代碼暴漲。相關代碼可以在我的一個開源項目CheatConsole中找到，地址：https://github.com/sczybt/CheatConsole 。

     6.統一使用C#，不要使用javascript或者boo，哪怕只有一個javascript或者boo代碼檔案，都會導致Unity引用兩個你根本不需要的庫Unity.Lang和Boo.Lang。這個可以通過在Native檔案夾下面搜尋名字包含Lang的C++檔案來驗證。這個要求也包括第三方庫，如果第三庫中有這些代碼，也會產生問題。

     7.移除不再使用的代碼。比如一些三方庫的Example代碼，永遠用不到的組件等等。

     8.盡量升級到新版本的Unity，一般來說新版本較舊版本都會在這方面做一些最佳化。比如4.6.6相比4.6.5就最佳化了大約30%以上的產生代碼容量。

 

總結

     使用了如上策略之後，我們項目的執行檔大小從最初的300m減小到90m，TEXT段大小從190M減小到70M。大家可以對這些方法進行驗證，並提前做好預防工作。

     

Unity引擎IOS執行檔大小最佳化