InjectFix是腾讯最新对外开源的Unity代码逻辑热修复方案，可实现在Unity线上客户端内，不用迭代新版本，就能快速修复游戏的线上bug。

先说几个亮点：

InjectFix经腾讯内部多个项目应用反馈十分良好，不仅能解决线上bug，还可以有效的提高日常开发效率，下面我们聊下这项目的前世今生。

热更方案大乱斗

所有支持iOS的热更方案都有个共同点：更新后代码都是解析执行。如果按其更新前是否解析执行，可以分为两大类：

一类是某些模块甚至整个游戏，都一直解析执行。这是最传统的方式，目前市面上所有主流方案（xLua，slua，tolua，ILRuntime，jsb等等）都支持这种方式。这种方式的特点：

ps：也有一种思路是通过一个C#转XX脚本工具来实现C#编码，解析执行，但如果你是一个已有项目想这么转一下，大概率是失败的，除非你一开始就在用这方式在开发，碰到坑就避开，因为这类方案往往不是完整支持全部语法，支持的语法也不一定能完全一致。

另外一类是以原生方式跑，如果有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）

苹果政策合规性

各热更方案群的问的频率最高的问题之一：这方案会不会导致我游戏苹果审核不通过。

让我们看看苹果的热更新条款:

可以看到最新条款允许下载代码解析执行，但前提是不能通过新增特性和功能来把程序改得（和审核时相比）面目全非。再看看通常被拒时的理由中的Guideline2.5.2里的一句：

Yourapp,extension,orlinkedframeworkappearstocontaincodedesignedexplicitlywiththecapabilitytochangeyourapp’sbehaviororfunctionalityafterAppReviewapproval。

有“新增特性和功能”能力的热更新方案的尴尬之处在于有“改得面目全非”的能力。而InjectFix从它提供的能力（只能修改已有函数）来看，并不具备“新增特性和功能”的能力，这本来是弱点，放在这里却成为合规性的保证了。

基本原理

InjectFix项目的研发挺曲折的。InjectFix和xLua是同一个作者，也是本文笔者，当时xLua开源后，不断有人提希望提供个C#转lua的工具，而深入研究觉得实现个il虚拟机工作量还更小，这样还能避免lua的一些gc问题。

决定要做il虚拟机后，也曾想过直接使用ILRuntime，评估后觉得不太符合我们的使用场景：ILRuntime并不能实现和原生代码的函数级别配合，这是我们能实现原工程直接改Bug的关键；ILRuntime运行时部分依赖cecil，除了资源占用大之外，还容易和unity自带或者某些插件的cecil冲突；加载的是标准的程序集在安全性方面也比较堪忧。虽说这些都可以改，但修改的工作量也挺大的，还不如自己写一个。

InjectFix实现bug修复主要靠这两部分：虚拟机负责新逻辑的解析执行；注入代码负责把调用重定向到虚拟机；下面我们结合最简单的例子介绍下这两部分。

虚拟机

关键部分用几行伪码就可以描述清楚：

导读

argumentBase指向的是求值栈该函数的栈帧，栈帧是这么安排的：

先放参数（如果有的话），再放本地变量（如果有的话），接着是临时区域，当函数返回时弹掉所有东西，如果有返回值就放到栈顶（函数执行前参数0的位置）。

用如下一个静态方法来演示下虚拟机怎么运行：

这函数编译后是这四条指令

Add函数的执行过程

代码注入

上面的Add函数注入后是这样的

比较简单，发现这函数有patch的话，就重定向到虚拟机。

而__Gen_Wrap_25是个适配器函数，赋值把参数压栈，调用虚拟机的Execute函数，并把结果返回。__Gen_Wrap_25的实现如下：

PS：我们的例子仅有三种指令，和这几条指令无关的代码全部简化了，真正复杂得多，有兴趣可以看源码了解。

总结

InjectFix使用简单，小巧，合规且安全。即使你不打算用它来更新线上版本，只要你程序有原生部分，接入也能一定程度上提高开发效率，没什么拒绝它的理由，是吧？

【责任编辑：张燕妮 TEL：（010）68476606】