誰偷了我的熱更新？Mono，JIT，iOS

0x00 前言

由於匹夫本人是做遊戲開發工作的，所以平時也會加一些玩家的群。而一些困擾玩家的問題，同樣也困擾著我們這些手機遊戲開發者。這不最近匹夫看自己加n的一些群，常常會有人問為啥這個遊戲一更新就要重新下載，而不能遊戲內更新呢？作為遊戲開發者，或者說Unity3D程序猿，我們都清楚Unity3D不n支持熱更新，甚至於在IOS平台上生成新的代碼都n會導致遊戲報錯崩潰（匹夫之所以在此處強調生成新的代碼這幾個字，就是提醒各位不要混淆Reflection.Emit和反射）。但我們是否和普通的玩家n一樣，看到的僅僅是「不能」的現象，而不了解「不能」背後的原因呢？那今天小匹夫就拋磚引玉，寫寫自己對這個問題的想法~~聊聊到底是誰偷了玩家的熱更新。

0x01 從一個常見的報錯說起

不知道各位看官中的U3D程序猿在開發IOS版本的時候是否也曾經碰到過這樣的報錯：

ExecutionEngineException: Attempting to JIT compile method XXXX while running with --aot-only.

這個報錯的意思很明確，說的也很具體，翻譯成中文的大意就是在使用--aot-only這個選項的前提下，又試圖去使用JIT編譯器編譯XXX方法。

那麼不知道是否會有看官覺得這個問題興許是程序跑在IOS平台上時，不小心犯了IOS的忌諱，使用了JIT（假設此時我們還不知道為何使用JIT是IOS的忌諱）去動態編譯代碼導致的IOS的報錯呢？

答案是否定的。

又或者更進一步，看到「ExecutionEngineException」，似乎和IOS平台的異常沒什麼太大的關聯，那就把責任定位在Unity3D的引擎上好了。一定是遊戲引擎此時不支持JIT編譯了。

也不全對，不過離真相很近了。

各位想想，能涉及到編譯的被懷疑的對象還能有誰呢？

好了，不賣關子了。這個異常其實是Mono的異常。換言之，Unity3D使用了Mono來編譯，所以Unity3D的嫌疑被排除。而IOS並沒有n因為生成或者運行動態生成的代碼而報錯，換言之這個異常發生在觸發IOS異常之前，所以說Mono在IOS平台上進行JIT編譯之前就先一步讓程序崩潰n了。

說到這裡，就繞不過Mono是如何編譯代碼這個話題了。如果我們去Mono的託管頁面看它的源碼，就可以簡單對它的目錄結構做一個簡單的分析，匹夫就簡單總結一下Mono編譯部分的目錄結構：

好啦，具體到咱們要聊的JIT編譯，我們需要看的就是mono目錄下的mini文件夾中的文件了，這個文件夾中的.c文件們實現了JIT編譯。

這個目錄的結構截個圖都截不全，因為文件太多：

不過這裡小匹夫想來一個倒敘，也就是先直接定位這個報錯「ExecutionEngineException: Attempting to JIT compile method XXXX while running with --aot-only.」的位置，然後再探明它究竟是如何被觸發的。

這樣，我們就來到了mono的JIT編譯器目錄mini下的mini.c文件。這裡就是JIT的邏輯實現。而那段報錯呢？在mini.c文件中是這樣處理的：

if (mono_aot_only) {n char *fullname = mono_method_full_name (method, TRUE);n char *msg = g_strdup_printf ("Attempting to JIT compile method %s while running with --aot-only. See http://docs.xamarin.com/ios/about/limitations for more information.n", fullname);n *jit_ex = mono_get_exception_execution_engine (msg);n g_free (fullname);n g_free (msg);n return NULL;n}n

mono_aot_only？沒錯，只要我們設定mono的編譯模式為full-aot（比如打IOS安裝包的時候），則在運行時試圖使用JIT編譯時，mono自身的JIT編譯器就會禁止這種行為進而報告這個異常。JIT編譯的過程根本還沒開始，就被自己扼殺了。

那麼JIT究竟是什麼洪水猛獸？為何IOS這麼忌諱它呢？那就不得不聊聊JIT本尊了。

0x02 美麗的JIT

因何美麗

名如其特點，JIT——just in time，即時編譯。

什麼？這就是匹夫你要告訴大傢伙的？這不是人人都知道的嘛？而且網上一搜也全都是JIT=just in time了事。好吧好吧，匹夫知錯啦。那就認真的定義一下JIT：

一個程序在它運行的時候創建並且運行了全新的代碼，而並非那些最初作為這個程序的一部分保存在硬碟上的固有的代碼。就叫JIT。

幾個點：

1. 程序需要運行
2. 生成的代碼是新的代碼，並非作為原始程序的一部分被存在磁碟上的那些代碼
3. 不光生成代碼，還要運行。

需要提醒的是第三點，也就是JIT不光是生成新的代碼，它還會運行新生成的代碼。之後我們會就這個話題展開。不過在之前匹夫還是要解釋一下，為何稱JIT是美麗的。

舉個例子：

比如你某一天突然穿越成為了一個優秀的學者（好吧好吧，這個貌似不是必須要穿越），現在要去一個語言不通的國家做一系列講座。面對語言不通的窘境，如何才不出醜呢？

匹夫有三條方案：

1. 在家的時候僱人把所有的講稿全部翻譯一遍。這是最省事的做法，但卻缺乏靈活性。比如臨時有更好的話題或者點子，也只能恨自己沒有好好學外語了。
2. 雇一個翻譯和你一起出發，你說啥他就翻譯成啥。這樣就不存在靈活性的問題，因為完全是同步的。不過缺點同樣明顯，翻譯要翻譯很多話，包括你重複說的話。所以需要的時間要遠遠高於方案1。
3. 雇一個翻譯和你一起出發，但不是你說啥他就翻譯啥，而是記錄翻譯過的話，遇到曾經翻譯過的就不會再翻譯了。你自己就可以根據之前的翻譯記錄和別人交流了。

看完這三條方案，各位看官心中更喜歡哪個呢？

匹夫個人的答案是方案3，因為這便是JIT的道。所以說JIT的美麗，就在於即保留了對代碼優化的靈活性，也兼具對熱點代碼進行重複利用的功能。

模擬一下JIT的過程

JIT這麼好，那它是如何實現既生成新代碼，又能運行新代碼的呢？

編譯器如何生成代碼很多文章都有涉及，匹夫就不多在此著墨了。下面我就著重和各位聊聊，如何運行新生成的代碼。

首先我們要知道生成的所謂機器碼到底是神馬東西。一行看上去只是處理幾個數字的代碼，蘊含著的就是機器碼。

unsigned char[] macCode = {0x48, 0x8b, 0x07};n

macCode對應的彙編指令就是：

mov (%rdi),%raxn

其實可以看出機器碼就是比特流，所以將它載入進內存並不困難。而問題是應該如何執行。

好啦。下面我們就模擬一下執行新生成的機器碼的過程。假設JIT已經為我們編譯出了新的機器碼，是一個求和函數的機器碼：

long add(long num) {n return num + 1;n}nn//對應的機器碼n0x48, 0x83, 0xc0, 0x01, n0xc3 n

首先，動態的在內存上創建函數之前，我們需要在內存上分配空間。具體到模擬動態創建函數，其實就是將對應的機器碼映射到內存空間中。這裡我們使用c語言做實驗，利用mmap函數來實現這一點。

因為我們想要把已經是比特流的「求和函數」在內存中創建出來，同時還要運行它。所以mmap有幾個參數需要注意一下。

代表映射區域的保護方式，有下列組合：

#include<stdio.h> #include <stdlib.h>n#include <string.h>n#include <unistd.h>n#include <sys/mman.h>nn//分配內存nvoid* create_space(size_t size) {n void* ptr = mmap(0, size,n PROT_READ | PROT_WRITE | PROT_EXEC,n MAP_PRIVATE | MAP_ANON,n -1, 0); n return ptr;n}n

這樣我們就獲得了一塊分配給我們存放代碼的空間。下一步就是實現一個方法將機器碼，也就是比特流拷貝到分配給我們的那塊空間上去。使用memcpy即可。

//在內存中創建函數nvoid copy_code_2_space(unsigned char* m) {n unsigned char macCode[] = {n 0x48, 0x83, 0xc0, 0x01,n c3 n };n memcpy(m, macCode, sizeof(macCode));n}n

然後我們在寫一個main函數來處理整個邏輯：

#include<stdio.h> n#include <stdlib.h>n#include <string.h>n#include <unistd.h>n#include <sys/mman.h>nn//分配內存nvoid* create_space(size_t size) {n void* ptr = mmap(0, size,n PROT_READ | PROT_WRITE | PROT_EXEC,n MAP_PRIVATE | MAP_ANON,n -1, 0); n return ptr;n}nn//在內存中創建函數nvoid copy_code_2_space(unsigned char* addr) {n unsigned char macCode[] = {n 0x48, 0x83, 0xc0, 0x01,n 0xc3 n };n memcpy(addr, macCode, sizeof(macCode));n}nn//main 聲明一個函數指針TestFun用來指向我們的求和函數在內存中的地址nint main(int argc, char** argv) { n const size_t SIZE = 1024;n typedef long (*TestFun)(long);n void* addr = create_space(SIZE);n copy_code_2_space(addr);n TestFun test = addr;n int result = test(1);n printf("result = %dn", result); n return 0;n}n

編譯並且運行看一下結果：

//編譯ngcc testFun.cn//運行n./a.out 1 n

留給我們的難題

OK，到此為止，一切都很順利。這個例子模擬了動態代碼在內存上的生成，和之後的運行。似乎沒有什麼問題呀？可不知道各位是否忽略了一個前提？那就是我們為這塊區域設置的保護模式可是：可讀，可寫，可執行的啊！如果沒有內存可讀寫可執行的許可權，我們的實驗還能成功嗎？

讓我們把create_space函數中的「可執行」PROT_EXEC許可權去掉，看看結果會是怎樣的一番景象。

修改代碼，同時將剛才生成的可執行文件a.out刪除重新生成運行。

rm a.outnvim testFun.cngcc testFun.cn./a.out 1n

結果。。。報錯了！

0x03 小結論

n所以，IOS並非把JIT禁止了。或者換個句式講，IOS封了內存（或者堆）的可執行許可權，相當於變相的封鎖了JIT這種編譯方式。

PS:

關於機器碼的獲取：

mac上用gobjdump linux用objdump