一项被低估的Unity技术

xLua在2017年初第一次把“热补丁”这个概念引入到Unity，一直都争议不断，有人认为“功德无量”，也有人认为“没啥价值”，这两个极端至今存在。甚至作者本人，也只是觉得会对游戏有帮助，但具体能有多大帮助也没底。而最近的一个用户调查却发现，可能连作者本人都低估了这项技术的价值。

（注：这里说的“热补丁”特指的是运行时用lua函数替换c#函数的功能）

热补丁用户调查

我们调查了8个游戏：

其中3个上过全球收入季度榜前十，1个是多端（手机+PC）同发，装机量3亿+，4个是中小型公司的作品。

游戏品类覆盖了横版过关、竞速、FPS、棋牌、mmorpg、卡牌rpg

其中5个纯用热补丁，3个既用了热补丁，也用了传统的lua更新

调查结果总结：

1、注入代码不会带来可以察觉的性能下降，包括对性能敏感的竞速和FPS游戏。

2、只要配置了注入的类型，且在加载补丁后运行的代码，都能修复。

3、纯用热补丁：一个月修复10~30个C# bug不等。混合使用：其中一个几乎纯用lua实现的游戏一个版本偶尔修复一个C# bug，其它两个的2~3个。

4、改进意见：代码段大小，泛型使用，大函数修复的工作量。

超乎预料的修复能力

只要注入了，运行时机在补丁加载之后的代码，都能修复！

由于补丁里头能访问、调用到任意的C#代码，所以理论上不考虑性能的话，配置了注入的代码都能被修复。

问题是逻辑转到脚本上执行，脚本肯定比原生要慢，如果脚本执行过程中要调用到C#就更慢了。那会不会有某段性能要求很高的代码，转到脚本执行后性能完全不能接受呢？

这种情况理论上完全可能的，但被调查的几个项目为啥没出现这种情况呢？

因为性能要求高代表了：1、这段代码会被频繁调用（换句话说会被频繁测试到）；2、开发人员也会特别用心去写，自测试一般也到位些；3、测试人员也会额外留意点；4、通常这类代码在一个项目占比也不多。

因此反而这些地方出现bug的概率比较低。可能被调查的项目运作都比较规范，至少保证重点保障的地方测试到了，因而没出现因为性能而不能修复的情况。

代码段攻略

由调查可知，热补丁技术使用的最大代价就是代码段了。

一方面，xLua持续的在优化代码段，也提供了各种各样的注入选项，能设定不同的注入模式以及过滤掉一些函数。合理的选择选项是可以把影响控制到“被注入代码”的10%以内的。

而“被注入代码”，随着版本的迭代，可以把一些经过几个版本沉淀已经稳定下来的代码排除掉。当然，初次上线是可以选择全注入的。

泛型增强

项目反馈说在补丁里头使用泛型比较麻烦。于是乎xLua为此做了一大波更新，现在泛型使用更直观，方便，强大了。详情可以参见相关文档。

下一代热补丁方案：iFix

改进意见里有点是关于大函数修复的工作量的，对于一些影响不大的bug，有些项目会因为这个而选择不修复。

iFix项目正是为了解决这问题而立项的，它更易用：直接原工程上改好bug，配置哪些函数要做成补丁即可。

热补丁，你值得拥有

对于已经用C#写好的项目，使用热补丁性价比非常高，低成本：原代码逻辑不需要做任何调整，只需要几行初始化代码，一些配置。高收益：能解决一些线上紧急bug。

低成本同时意味着可进可退：随时可以选择去掉，真正后顾无忧。

对于希望混合编程的项目，使用xLua意味着C#的bug也不是完全无能为力了。

全部用lua来写的游戏倒没热补丁的需求。但全lua感觉只适合卡牌，休闲类这些对性能要求不高的游戏。性能要求高的游戏用纯C#、混合的居多，甚至有些项目对于一些要求高的地方，C#都无法满足需求，得用C++。

纯lua还有其它困境：比如最近纯lua游戏容易出现机审不过的情况；大量的lua在后期维护也是个问题等等。

常见误解

一些常见的误解，这些误解是很多人接纳热补丁技术的坎。

1、“打补丁”要把C#翻译成lua，后面更新大版本又要把lua翻译成C#。

对于这种观点，我想说三点：“。。。”，抛开热补丁不说，用C#开发的项目，出bug也要在C#上修复吧？有了xLua热补丁，只是增加了能通过lua对线上紧急问题修复的能力，线上紧急问题轻则影响了口碑，重则可能导致一个游戏的没落（参见某阳师），这重要性不言而喻。

2、我不知道哪出bug，怎么知道哪些类要打Hotfix标签呢？

前面的调查我们知道，使用热补丁的唯一代价就是代码段增加，这个增加是正比于你配置了Hotfix的类的个数的。所以xLua提供的是白名单机制，让你去配置。

当你实在没底的话，可以选择把所有类都配置到Hotfix，比如刚上线的项目往往选择这种。

有人会问，全加上，一个个类的打标签不是疯了？

一个个类的打标签？不存在的，xLua的动态配置可以让你几行代码实现全部业务代码加到Hotfix列表：

[Hotfix]
public static List<Type> by_property
{
    get
    {
        return (from type in Assembly.Load("Assembly-CSharp").GetTypes() select type).ToList();
    }
}

有人会问，为啥不默认全加上呢？既然全加上只是几行代码的事情，为啥要整成默认，剥夺大家的选择权呢？

动态配置可以加些条件，比如只允许某名字空间，某个代码目录，排除某些自定类型等等。

总结

在逻辑更新领域中，bug修复时效性要求最高，而热补丁技术恰恰能低成本提供的bug修复能力，如果你能接受这成本（主要是代码段增大），实在不应该有拒绝这项技术的理由。