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的位置)。
用如下一个静态方法来演示下虚拟机怎么运行:
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使用简单,小巧,合规且安全。即使你不打算用它来更新线上版本,只要你程序有原生部分,接入也能一定程度上提高开发效率,没什么拒绝它的理由,是吧?