在確定目標，動手實現(xiàn)huatuo前，有一個必須考慮的問題——我們如何確定huatuo的可行性？

il2cpp雖然不是一個極其完整的運行時，但代碼仍高達12w行，復雜度相當高，想要短期內深入了解它的實現(xiàn)是非常困難的。而且除了官方幾個介紹il2cpp的博客外，幾乎找不到其他文檔。 Hybrid mode execution 的實現(xiàn)復雜度也很高，如果不能確信能夠在il2cpp上實現(xiàn)這套機制，貿然投入開發(fā)，萬一幾個月后發(fā)現(xiàn)此路不通，或者說開發(fā)完成后，突然發(fā)現(xiàn)有一個嚴重并且無解的系統(tǒng)性的缺陷導致這個方案完全不可用于商業(yè)項目，這會帶來巨大的資源浪費，以及對開發(fā)者產(chǎn)生巨大的信心挫傷。 磨刀不誤砍柴工，在動手前從理論上確信這套方案有極高可行性，是完全必要的。

?

以我們對CLR運行時的認識，要實現(xiàn) hybrid mode execution 機制，至少要解決以下幾個問題：

• 能夠動態(tài)注冊元數(shù)據(jù)，這些動態(tài)注冊的元數(shù)據(jù)必須在運行時中跟AOT元數(shù)據(jù)完全等價。

• 所有調用動態(tài)加載的assembly中函數(shù)的路徑，都能定向到正確的解釋器實現(xiàn)。包括虛函數(shù)override、delegate回調、反射調用等等

• 解釋器中的gc，必須能夠與AOT部分的gc統(tǒng)一處理

• 多線程相關能正常工作。包括且不限于創(chuàng)建Thread、async、volatile、ThreadStatic等等

我們下面一一分析解決這些問題

我們在動手前檢查了多個相關函數(shù)，基本沒有問題。雖然不敢確定這一定是可行的，但元數(shù)據(jù)加載是huatuo第一階段的開發(fā)任務，萬一發(fā)現(xiàn)問題，及時中止huatuo開發(fā)損失不大。于是我們認為算是解決了第一個問題。

所有調用動態(tài)加載的assembly中函數(shù)的路徑，都能定向到正確的解釋器實現(xiàn)

我們分析了il2cpp中關于Method元數(shù)據(jù)的管理方式，發(fā)現(xiàn)MethodInfo結構中保存了運行時實際執(zhí)行邏輯的函數(shù)指針。如果我們簡單地設置動態(tài)加載的函數(shù)元數(shù)據(jù)的MethodInfo結構的指針為正確的解釋器函數(shù)，能否保證所有流程對該函數(shù)的調用，都能正確定向到解釋器函數(shù)呢？

嚴謹思考后的結論是肯定的。首先AOT部分不可能直接調用動態(tài)加載的dll中的函數(shù)。其次，運行時并沒有其他地方保存了函數(shù)指針。意味著，如果想調用動態(tài)加載的函數(shù)，必須獲得MethodInfo中的函數(shù)指針，才能正確執(zhí)行到目標函數(shù)。意味著我們運行過程中所有對該函數(shù)的調用一定會調用到正確的解釋器函數(shù)。

至于我們解決了第二個問題。

總結

我們通過少量的對實際il2cpp代碼的觀察，以及對CLR運行時原理的了解，再配合思維實驗，可以99.9%以上確定，既然il2cpp生成的代碼都能在運行時正確運行，那huatuo解釋模式下執(zhí)行的代碼，也能正確運行。

我們在完成思維實驗的那一刻，難掩內心激動的心情。作為一名物理專業(yè)的IT人，腦海里第一時間浮現(xiàn)出愛因斯坦在思考廣義相對論時的，使用電梯思維實驗得出引力使時空彎曲這一驚人結論。我們不敢比肩這種偉大的科學家，但我們確實在使用類似的思維技巧。可以說，huatuo不是簡單的經(jīng)驗總結，是深刻洞察力與分析能力孕育的結果。