热更新大乱斗，腾讯正式开源面向Unity项目的Bug修复神器InjectFix

发表于 5年以前 | 总阅读数：1047 次

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支持重复加载补丁，新加载补丁会自动覆盖上一个，这特性可以用来实现真机代码逻辑实时修改。

（视频地址：点此链接。）

苹果政策合规性

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

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

可以看到最新条款允许下载代码解析执行，但前提是不能通过新增特性和功能来把程序改得（和审核时相比）面目全非。再看看通常被拒时的理由中的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的位置）。

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

<pre class="brush:bash;toolbar:false">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函数注入后是这样的

<pre class="brush:bash;toolbar:false">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的实现如下：

<pre class="brush:bash;toolbar:false">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使用简单，小巧，合规且安全。即使你不打算用它来更新线上版本，只要你程序有原生部分，接入也能一定程度上提高开发效率，没什么拒绝它的理由，是吧？