不同Unity版本IL2CPP對比
| Unity版本 | C++代碼總行數 | 泛型相關行數 | Attribute相關行數 | IPA大小 | 純64位 | 64位+32位 | 備注 |
|---|---|---|---|---|---|---|---|
| 4.6.4f1 | 約3302萬行 | 約2508萬行(75%) | 1984行 | 330MB | 約65MB | 約130MB | 正常運行，包太大 |
| 4.6.6f1 | 約755萬行 | 約156萬行 (20%) | 約28萬行 | 292MB | 約42MB | 約78MB | 包夠小! 泛型BUG閃退，KTDCaption.AddPart |
| 4.6.7f1 | 約731萬行 | 約158萬行(21%) | 約28萬行 | 293MB | 約43MB | 約81MB | 正常運行！包大小差一點點 |
| 4.6.8f1 | 約589萬行 | 約275萬（46%） | 約28萬行 | 295MB | 約50MB | 約93MB | 初始化階段，一處反射BUG閃退，KLTaskSettingCallParse里的GetType(xxx, true) |
| 4.6.9f1 | 約591萬行 | 約276萬行(46%) | 約28萬行 | 295MB | 約50MB | 約93MB | 初始化階段，一處反射BUG閃退，KLTaskSettingCallParse里的GetType(xxx, true) |
| 4.7.1f1 | 約591萬行 | 約276萬行(46%) | 約28萬行 | 295MB | 約50MB | 約95MB | 初始化階段，一處反射BUG閃退，KLTaskSettingCallParse里的GetType(xxx, true) |
-
注意:
- 64位+32位要小於80MB才能允許上傳到App Store！
- 尚未進行代碼注入！即無熱更新功能
- IL2CPP的BUG集中在反射和泛型！執行文件大小跟泛型的使用成正比
- 我們的代碼風格越簡潔越不會出現問題！
- 最新的幾個版本4.6.8-4.7.1，IL2CPP已經沒有太多變化了
-
需要進行的優化：
- object引用類型的泛型，4.6.6后，會進行泛型共享，但是值類型的泛型，依然會生成非常大量的代碼
- struct改class! 數組struct[] 會生成大量代碼，數組class[]則不會
- 修復帶有值類型的泛型： 如IList<(struct)> 改成IList<(class)>, Dict<(value), (value)> 改成Hashtable
以后經驗：
- 禁止多重泛型、泛型類、泛型接口、泛型委托， 泛型方法用前斟酌
- 盡可能避免使用反射
不同Unity版本IL2CPP的差異
從Unity 4.6.2開始，之后的所有版本主要精力幾乎都集中在IL2CPP的修復和改進。 嘗試了不同Unity版本的IL2CPP，發現生成的C++代碼有非常大的差異，連生成的策略都很不一樣。
蘋果公司對執行文件的規定
蘋果公司規定，IOS應用執行文件大小有上限限制。 只支持64位的應用，執行文件必須在60MB以下。 要求iPhone 5S或以上，iOS 8.0或以上版本。 支持32位+64位的應用，執行文件必須在80MB以下，要求iOS 6.0以上。
是怎樣評估泛型代碼占用的？
搜索帶有“Generic”字符串的C++文件，用shell命令進行統計。
IL2CPP的重災區
數組Array
泛型 Generic
非常嚴重， 4.7.1的IL2CPP優化重點，就是對於對泛型進行共享優化。 比如Dictionary<(KItem), (KWeapon)>，會變成Dictionary<(* void), (* void)> 但是Dictionary<(KItem), (int)>，依然會生成C++代碼。 