InjectFix是騰訊最新對外開源的Unity代碼邏輯熱修複方案，可實現在Unity線上客戶端內，不用迭代新版本，就能快速修復遊戲的線上bug。
先說幾個亮點：
直接在Unity工程上修改C#即可更新；老項目無需修改原有代碼即可使用； 更符合蘋果熱更新條款； 每個遊戲一份私有補丁格式，安全更有保障。InjectFix經騰訊內部多個項目應用反饋十分良好，不僅能解決線上bug，還可以有效的提高日常開發效率，下面我們聊下這項目的前世今生。
熱更方案大亂鬥所有支持iOS的熱更方案都有個共同點：更新後代碼都是解析執行。如果按其更新前是否解析執行，可以分為兩大類：
一類是某些模塊甚至整個遊戲，都一直解析執行。這是最傳統的方式，目前市面上所有主流方案（xLua，slua，tolua，ILRuntime，jsb等等）都支持這種方式。這種方式的特點：
或多或少都會有些侵入性：ILRuntime解析執行C#編譯後的程序集，在這些方案裡頭侵入性可能最小，但也需要對代碼重構，把要更新的邏輯拆到單獨程序集。各種非C#的腳本侵入性最大，一個已經完成的純C#項目要用意味著重寫。ps：也有一種思路是通過一個C#轉XX腳本工具來實現C#編碼，解析執行，但如果你是一個已有項目想這麼轉一下，大概率是失敗的，除非你一開始就在用這方式在開發，碰到坑就避開，因為這類方案往往不是完整支持全部語法，支持的語法也不一定能完全一致。
基於性能，實現便利性等的考慮，一般遊戲有些地方要以原生的方式跑，這些原生跑的代碼出了bug這種方式是無能為力的。 如果使用的腳本是動態類型語言，還會帶來代碼維護困難的問題。 優點是可以新增功能，有的遊戲甚至可以做到一次下載，後續不用整包更新。但蘋果條款分析的章節可以看到，這也不一定是好事。另外一類是以原生方式跑，如果有bug，把邏輯重定向到新的，解析執行的邏輯。這種方式的特點：
侵入性低，後期項目也可以使用。 正常邏輯是原生方式運行，有問題只是局部切換到解析執行，所以性能比較好。 會導致代碼段增大，增大正比於注入的類的數量。 這種方式往往難以新增功能。第二種方式是接下來討論的重點，方便起見，我們稱之為「熱修復」，熱修復最早的成熟方案是xLua提供，經過兩年來的使用已經逐漸被接受，tolua#後來也加入了這功能，也有一些網友基於ILRuntime做了熱修復功能。
InjectFix是什麼？InjectFix就是一個熱修復的實現。那它和其它熱修複方案又有什麼不同呢？
設想這麼個場景，我們有一個一千行代碼的函數，其中有一行有問題，我們需要修復它。
如果用xLua，需要用lua去重新實現一遍這個函數，工作量大。而基於ILRuntime的熱修復，由於其補丁是另一個程序集，它無法直接訪問原類的私有成員，所以那999行正常代碼一般也不能直接使用，需要做較多修改。
而InjectFix不需要用lua，也不需要像ILRuntime熱修復那樣另外建一個工程把那一千行邏輯重實現。只需要在Unity原工程直接改掉這行代碼，然後標註這函數要更新即可。
不僅如此，InjectFix還有其它優勢：
運行時非常小巧，僅100K左右，比各lua方案，ILRuntime都要小很多，而且不依賴第三方庫，純C#實現。 支持每個遊戲生成一份自己私有的補丁格式，私有的指令定義。這樣相比通用的lua原代碼，lua字節碼，clr程序集都更安全些。 支持Assembly-CSharp.dll之外的dll的修復。 免代碼生成，更乾淨。它也有缺點，不支持新增類，也不支持在已有類新增欄位，修bug還是夠用的，但難以通過熱更為遊戲增加新功能。InjectFix就一個純粹的修bug工具而已。
黑科技由於InjectFix支持重複加載補丁，新加載補丁會自動覆蓋上一個，這特性可以用來實現真機代碼邏輯實時修改。
（視頻地址：https://v.qq.com/x/page/v09240mo6ai.html?&ptag=4_7.2.5.22206_copy）
蘋果政策合規性各熱更方案群的問的頻率最高的問題之一：這方案會不會導致我遊戲蘋果審核不通過。
讓我們看看蘋果的熱更新條款:
可以看到最新條款允許下載代碼解析執行，但前提是不能通過新增特性和功能來把程序改得（和審核時相比）面目全非。再看看通常被拒時的理由中的Guideline 2.5.2裡的一句：
Your app, extension, or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval。
有「新增特性和功能」能力的熱更新方案的尷尬之處在於有「改得面目全非」的能力。而InjectFix從它提供的能力（只能修改已有函數）來看，並不具備「新增特性和功能」的能力，這本來是弱點，放在這裡卻成為合規性的保證了。
基本原理InjectFix項目的研發挺曲折的。InjectFix和xLua是同一個作者，也是本文筆者，當時xLua開源後，不斷有人提希望提供個C#轉lua的工具，而深入研究覺得實現個il虛擬機工作量還更小，這樣還能避免lua的一些gc問題。
決定要做il虛擬機後，也曾想過直接使用ILRuntime，評估後覺得不太符合我們的使用場景：ILRuntime並不能實現和原生代碼的函數級別配合，這是我們能實現原工程直接改Bug的關鍵；ILRuntime運行時部分依賴cecil，除了資源佔用大之外，還容易和unity自帶或者某些插件的cecil衝突；加載的是標準的程序集在安全性方面也比較堪憂。雖說這些都可以改，但修改的工作量也挺大的，還不如自己寫一個。
InjectFix實現bug修復主要靠這兩部分：虛擬機負責新邏輯的解析執行；注入代碼負責把調用重定向到虛擬機；下面我們結合最簡單的例子介紹下這兩部分。
虛擬機關鍵部分用幾行偽碼就可以描述清楚：
導讀
pc指向的是函數的第一條指令； argumentBase指向的是第一個參數； while+switch一條條指令往下執行，具體指令的操作在case那；argumentBase指向的是求值棧該函數的棧幀，棧幀是這麼安排的：
先放參數（如果有的話），再放本地變量（如果有的話），接著是臨時區域，當函數返回時彈掉所有東西，如果有返回值就放到棧頂（函數執行前參數0的位置）。
用如下一個靜態方法來演示下虛擬機怎麼運行：
public static float Add(float a, float b){ return a - b;}
這函數編譯後是這四條指令
Add函數的執行過程
指令1把參數0 Push到棧頂； 指令2把參數1 Push到棧頂； 指令3把兩個棧頂元素彈出（Pop）並相加，結果Push到棧頂； 指令4把棧頂拷貝到參數0的位置，清理棧，退出循環，Execute函數執行結束。代碼注入上面的Add函數注入後是這樣的
public static float Add(float a, float b){ if (WrappersManagerImpl.IsPatched(92)) { return WrappersManagerImpl.GetPatch(92).__Gen_Wrap_25(a, b); } return a - b;}
比較簡單，發現這函數有patch的話，就重定向到虛擬機。
而__Gen_Wrap_25是個適配器函數，賦值把參數壓棧，調用虛擬機的Execute函數，並把結果返回。__Gen_Wrap_25的實現如下：
public float __Gen_Wrap_25(float P0, float P1){ Call call = Call.Begin(); call.PushSingle(P0); call.PushSingle(P1); this.virtualMachine.Execute(this.methodId, ref call, 2, 0); return call.GetSingle(0);}
PS：我們的例子僅有三種指令，和這幾條指令無關的代碼全部簡化了，真正複雜得多，有興趣可以看源碼了解。
總結InjectFix使用簡單，小巧，合規且安全。即使你不打算用它來更新線上版本，只要你程序有原生部分，接入也能一定程度上提高開發效率，沒什麼拒絕它的理由，是吧？