在过去我们做应用开发时，当用户下载安装了我们的APP之后，如果APP产生了BUG，或者有些行为想要改变时，我们只能通过重新发布一个版本，让用户覆盖安装才能解决相对应的问题，其实思考下来你会发现，这个过程它的成本还是比较高的。一批牛逼的开发者就开始思考有没有什么方案能够解决这样一个尴尬的场景，于是乎，热修复横空出世了，它可以让用户没有任何的感知就可以完成BUG的修复或者一些行为的更改，这也是它最核心的价值体现。

1.3、热修复===万事大吉？

其实啊，热修复对于我们来说只是一种亡羊补牢的手段，不到万不得已也不会去使用的，在企业中实际上发布热修复版本和发布正式版都是一样的节奏，也需要测试完全测试通过，而且市面上现有的热修复框架都有一定的兼容性问题，所以我们首先应该保证高质量的版本发布，热修复只是作为一种辅助手段，不要对其有任何的依赖心理，做好本身才是最好！

二、热修复常见技术方案对比

2.1、方案介绍

当前市面上流行的热修复方案主要是分为阿里系和腾讯系，当然也有其它一些大厂开源出来的方案，主要有以下几种：

QQ空间的超级补丁方案
微信的Tinker
阿里系：手淘Dexposed，支付宝AndFix，阿里百川HotFix，手淘技术团队联合阿里云Sophix
美团的Robust，饿了么的migo，百度的hotfix......

2.2、实现套路

实现套路	描述	方案代表
底层替换	这种方案有很大的限制，不过时效性好，即时生效	阿里系：AndFix、Sophix
类加载	这种方案限制较少，修复范围广，不过时效性差，需要重新冷启动才能见效	腾讯系：QZone、Tinker

2.3、技术对比

方案对比	Tinker	QZone	AndFix	Robust
类替换	yes	yes	no	no
So替换	yes	no	no	no
资源替换	yes	yes	no	no
全平台支持	yes	yes	yes	yes
即时生效	no	no	yes	yes
性能耗损	较小	较大	较小	较小
补丁包大小	较小	较大	一般	一般
开发透明	yes	yes	no	no
复杂度	较低	较低	复杂	复杂
gradle支持	yes	no	no	no
Rom体积	较大	较小	较小	较小
成功率	较高	较高	一般	最高

总结：

AndFix存在稳定性与兼容性问题，并且无法实现类替换，只能用作BUG修复
Robust兼容性与成功率较高，但是同样无法新增类和变量，只能用作BUG修复
QZone虽然可以做到发布产品功能，但是存在性能问题，并且补丁包较大
Tinker支持类、SO、资源替换，既可以修复BUG又可以发布产品功能，并且还运行在微信庞大的用户设备上

综合以上对比分析，更加推荐使用Tinker，因为它的功能相对来说是最齐全的。

2.4、技术选型

理清需求是什么，因为需求是否能够满足才是衡量一切的标准，技术就像女朋友，没有好坏只有适合与不适合
能满足需求的条件下，衡量学习成本的高低
学习成本一样的情况下，优先选择大公司的方案（有专门的技术团队维护相应的方案，并且久经市场考验）

综合以上考虑，我会在这个专栏里介绍两种方案的实现，一是较为简单的AndFix，二是较为复杂的Tinker，简单的和复杂的都了解一下，可以对热修复建立起一个更好的技术栈。

2.5、关于自建热修复

我在学习热修复这块的知识的时候，也在网上看了很多的文章，我发现有些文章教了大家如何手写热修复框架，在这里简单谈几点自己的思考和看法吧：

对于手写热修复框架当然是持推荐和鼓励的态度，如果你能够自己动手写一套热修复的框架，对开发者本身还是有很大的收获的，首先你会对热修复技术的实现原理有一个更好的认识，从底层到应用层建立起自己的一套清晰完整的知识体系，对于市面上的开源方案你肯定也能够做到举一反三，在自己的项目中更加容易集成和使用。
不推荐重复造轮子，当然如果你能造出更好的轮子，前面那句话当我没说。
市面上流行的热修复方案都是大厂专门的技术团队在开发维护的，首先他们的整体技术实力肯定是毋庸置疑的，其次这些方案一般都应用在自己的产品体系中，都是经历了市场上持久的考验，技术方案本身已经是相当成熟的，对于集成后产生的问题也基本上都能找到相对应的解决方案，实在没有你也可以到对应的社区或者官网上提问寻求答案。所以对于公司的企业级项目来说稳定性肯定是要有的，所以使用自建的方案能否保证稳定性，这个问题可能你得好好考虑一下。

今天的内容就到这里吧，不打扰各位约会了！总的来说就是对热修复技术做一个整体的介绍，下一篇就来把AndFix集成到项目中进行具体的使用，OK，咱们下期再会吧！

下一篇：《Android热修复实战之AndFix》

Android热修复技术简介

写在前面

一、热修复简介

1.1、什么是热修复

1.2、热修复有哪些好处