Unity下Bug修复神器，腾讯InjectFix开源啦！

640?wx_fmt=png

Unity 下 Bug 修复神器 InjectFix 开源啦！

InjectFix 使用简单，小巧，合规且安全，经过多个项目应用反馈十分良好，即使你不打算用它来更新线上版本，只要你程序有原生部分，接入也能一定程度上提高开发效率。

InjectFix 亮点：

1. 直接在Unity工程上修改C#即可更新；老项目无需修改原有代码即可使用；

2. 更符合苹果热更新条款；

3. 每个游戏一份私有补丁格式，安全更有保障。

InjectFix的那些事儿

热更方案大乱斗

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

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

这种方式：

1. 或多或少都会有些侵入性；

2. 基于性能、实现便利性等的考虑，一般在游戏中要以原生的方式跑，这些原生跑的代码出了bug时，在这种方式下是无能为力的；

3. 如果使用的脚本是动态类型语言，还会带来代码维护困难的问题；

4. 可以新增功能，有的游戏甚至可以做到一次下载，后续不用整包更新。

另外一类是原生方式，如果有bug，把逻辑重定向到新的，解析执行的逻辑。

这种方式：

1. 侵入性低，后期项目也可以使用；

2. 正常逻辑是原生方式运行，有问题只是局部切换到解析执行，所以性能比较好；

3. 会导致代码段增大，增大正比于注入的类的数量；

4. 这种方式往往难以新增功能。

第二种方式是接下来讨论的重点，方便起见，我们称之为“热修复”，热修复最早的成熟方案是xLua提供，经过两年来的使用已经逐渐被接受，tolua#后来也加入了这功能，也有一些网友基于ILRuntime做了热修复功能。

InjectFix是什么

InjectFix就是一个热修复的实现。那它和其它热修复方案又有什么不同呢？

设想这么个场景，我们有一个一千行代码的函数，其中有一行有问题，我们需要修复它。如果用xLua，需要用lua去重新实现一遍这个函数，工作量大。而基于ILRuntime的热修复，由于其补丁是另一个程序集，它无法直接访问原类的私有成员，所以那999行正常代码一般也不能直接使用，需要做较多修改。而InjectFix不需要用lua，也不需要像ILRuntime热修复那样另外建一个工程把那一千行逻辑重实现。只需要在Unity原工程直接改掉这行代码，然后标注这函数要更新即可。

InjectFix还有其它优势：

1. 运行时非常小巧，仅100K左右，比各lua方案，ILRuntime都要小很多，而且不依赖第三方库，纯C#实现；

2. 支持每个游戏生成一份自己私有的补丁格式，私有的指令定义。这样相比通用的lua原代码，lua字节码，clr程序集都更安全些。

3. 支持Assembly-CSharp.dll之外的dll的修复。

4. 免代码生成，更干净。

它也有缺点，不支持新增类，也不支持在已有类新增字段，修bug还是够用的，但难以通过热更为游戏增加新功能。InjectFix就一个纯粹的修bug工具而已。

黑科技

由于InjectFix支持重复加载补丁，新加载补丁会自动覆盖上一个，这特性可以用来实现真机代码逻辑实时修改。

苹果政策合规性

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

640?wx_fmt=png

可以看到最新条款允许下载代码解析执行，但前提是不能通过新增特性和功能来把程序改得（和审核时相比）面目全非。再看看通常被拒时的理由中的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从它提供的能力（只能修改已有函数）来看，并不具备“新增特性和功能”的能力，这本来是弱点，放在这里却成为合规性的保证了。

做项目需要用心聆听，根据反馈不断改进。而开源能够帮助听到更多的声音，在未来更好地改进这个项目。