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修复能力，如果你能接受这成本（主要是代码段增大），实在不应该有拒绝这项技术的理由。
