問題的產(chǎn)生

這個問題一般發(fā)生在項目比較大，OO使用良好，泛型繼承用的較多的時候。第一次真機測試時，項目終于進入真機測試階段，之前都是在Unity編輯環(huán)境下開發(fā)測試，運行的都很良好，信心滿滿的打包安裝，結(jié)果閃退。。。，各種代碼調(diào)試，跟蹤都沒什么線索。這怎么辦？問題很可能出在了AOT的設置上。

解決方案

這個通常是因為你的程序編譯的時候給 trampoline 分配的空間太小，而你的程序中又大量使用了泛型、泛型方法調(diào)用和接口實現(xiàn)導致的。具體的解決方法就是在 Unity3D 的編譯選項 Player Setting 中有一個 AOT Compilation Options 條目，在這個選項條目中加上以下編譯參數(shù)就好了

nrgctx-trampolines=8192,nimt-trampolines=8192,ntrampolines=4096

加上以后，重新打包測試，看還有沒有問題

參數(shù)意思

關于上面的三個參數(shù)的意思分別如下：

nrgctx-trampolines=8192 這是留給遞歸泛型使用的空間，默認是 1024

nimt-trampolines=8192 這是留給接口使用的空間，默認是 128

ntrampolines=4096 這是留給泛型方法調(diào)用使用的空間，默認是 1024

什么是trampoline

Trampoline 是一些手寫的非常短小的用來在 Mono Runtime中執(zhí)行很多操作的Component Code。主要是通過 JIT 使用到的本地代碼宏在運行時動態(tài)生成的。它們通常都有與之相對應的 C 方法，在某些較為復雜的場景中，當 trampoline 無法勝任時，mono 運行時就會將這些復雜的操作交回給這些對應的 C 方法來執(zhí)行。這也可以看作是將 JIT 代碼的執(zhí)行權交回給 runtime 的一種方式。

這看起來明顯是為了提高 mono runtime 在執(zhí)行 C#代碼時候的效率,但還是有點不明白。

再來看看官方文檔關于 JIT Trampolines 和 AOT Trampolines 的介紹：

JIT Trampolines 這些 Trampoline 主要是 JIT 在首次調(diào)用某個方法的時候編譯方法用的。當 JIT 在編譯一個方法調(diào)用指令時，它并不會立刻就編譯這個被調(diào)用到的方法。實際上，它會先創(chuàng)建一個 JIT Trampoline，同時創(chuàng)建一個指向這個 trampoline 的調(diào)用指令。當這個 JIT Trampoline 在調(diào)用到的時候，它會再調(diào)用 mono_magic_trampoline() 方法來編譯這個 trampoline 實際指向的目標方法，然后將編譯后的方法的指針地址返回給這個指向它的 trampoline。這個過程呢稍微有點慢，所以呢，mono_magic_trampoline() 方法會優(yōu)化調(diào)用 JIT 代碼的過程，它會先嘗試調(diào)用已經(jīng)通過 JIT 編譯過的方法而不是立即通過 trampoline 直接進行調(diào)用。這些都是通過在 tramp-.c 文件中的 mono_patch_callsiete() 方法來完成的。

AOT Trampolines

AOT Trampolines 和 JIT Trampolines 非常相似，但是 AOT Trampolines 接受的編譯參數(shù)不是一個 Mono 方法而是一個 image+token 對。如果傳入的用于編譯的 image+token 對所指向的方法已經(jīng)經(jīng)過 AOT 編譯過了，那么再次編譯這個 image+token 對時，就會直接返回這個已編譯方法的指針地址而不需要再次加載這個方法的元數(shù)據(jù)進行再次編譯了。

IMT Trampolines也是用于優(yōu)化接口調(diào)用效率的。

Trampolines 存在的價值就是為了減少 C#代碼在 mono runtime 中運行時的性能損耗，提高 C#代碼的執(zhí)行效率。

總結(jié)

當遇到類似問題時可以試試上面的方法。

以上這篇Unity3D實驗室之iOS真機閃退的解決方法就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論