为何使用热修复？

项目开发中难免会有一些问题，需要修改，直接进行发版的话成本较高。这时候我们就需要一个可以在不进行版本更新，就可以修复问题的工具。所以说，热修复的定位就是对一些非紧急，需要解决的bug进行修复的辅助工具。

什么是Tinker？为何选用它？

• Tinker是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。

• 国内大大小小，有很多开源的热修复工具，方案。但他们或多或少有着生产项目难以接受的问题：

  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体积	较大	较小	较小	较小
  成功率	较高	较高	一般	最高

总的来说:

1. AndFix作为native解决方案，首先面临的是稳定性与兼容性问题，更重要的是它无法实现类替换，它是需要大量额外的开发成本的；
2. Robust兼容性与成功率较高，但是它与AndFix一样，无法新增变量与类只能用做的bugFix方案；
3. Qzone方案可以做到发布产品功能，但是它主要问题是插桩带来Dalvik的性能问题，以及为了解决Art下内存地址问题而导致补丁包急速增大的。

特别是在Android N之后，由于混合编译的inline策略修改，对于市面上的各种方案都不太容易解决。而Tinker热补丁方案不仅支持类、So以及资源的替换，它还是2.X－8.X(目前也支持9.0)的全平台支持。并且Tinker已运行在微信的数亿Android设备上。

已知问题

理想很美好，愿世上没有bug，or Tinker可以解决我们遇到的所有问题，但就几次线上补丁的发布以及最终结果来看，他都或多或少有以下几个问题：

• 以下都是针对我们使用的1.9.2版本来说明：
  1. 公司内部部分手机补丁没有生效，测试部门的两款Vivo手机，这个是tinker已知的问题，Vivo部分手机，会执行异步dex2oat，在dex合成等待时间内，并没有修复成功，目前于使用tinker1.9.9版本测试时，确认已经修复。
  2. 项目更新了x5 webview的版本，下发补丁。但客户反馈有手机会有手机连续闪退三次，回退到补丁前的版本。对于此问题，我们也仔细的研究了友盟后台的crash日志，发现的确有华为android 8.0，9.0存在闪退的情况。
  3. Tinker必须要重启后生效，硬伤。
  4. 对于整个android系统来说，热修复方案其实是一种逆向行为，无论是哪种方案，都可能存在兼容性问题的，而且每次android新版本发布，尤其对虚拟机等做优化时，基本上都会成为热修复的“坑”。
  5. 用户安装补丁后，可能修复过程或者修复后，app闪退，此时我们是闪退三次，再清除补丁，能否闪退一次就进行清除？
• 官方介绍说明，由于原理与系统限制，Tinker有以下已知问题：
  1. Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件(1.9.0支持新增非export的Activity)；
  2. 由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；
  3. 在Android N上，补丁对应用启动时间有轻微的影响；
  4. 不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；
  5. 对于资源替换，不支持修改remoteView。例如transition动画，notification icon以及桌面图标。

对我们有何影响？如何解决

• 1.9.2不支持vivo，目前可以通过升级Tinker版本，较为简单的解决。

• Tinker作为微信实际使用的动态代码修复方案，他们也会不断接收到来自于手机厂商，开发者反馈的各种问题，不断更新版本。目前已经迭代到1.9.11并解决了部分问题。

• 对于组件新增，目前我们的bug场景不会涉及。google市场暂时不会上架，需要上架时，我们不下发补丁即可。

• 对于此次小邑出现的崩溃，目前总结有以下两个原因：

  1. 更新X5版本，代码设计修改点很大，风险性预估不充分，测试覆盖不全面
  2. tinker版本项目中使用的还是1.9.2，此时android9.0尚未发布，厂家的定制系统可能不够适配，需要及时迭代，方可使用。

• 对于补丁异常出现三次，再进行清除，我们可以设置次数。

• 对于补丁下发，我们没有整体把控的数据支持；于此，我们增加补丁下发覆盖率（下载补丁数/活跃用户数），成功率（成功/活跃用户数）的数据统计。新增bugly渠道跟踪异常，bugly可以更及时，准确的反馈异常。

• 接下来我们重点考虑如何降低Tinker导致的异常崩溃：

  1. 对于补丁版本严格把控，对补丁修改涉及的影响点评估。并列入修改点，提供给项目经理，再向上请示，是否进行相关修改。

  2. 确认发布补丁时，需要对补丁修复后的app，测试针对影响点，尽可能多的利用公司手机，覆盖测试。

  3. 结合线上资源，对补丁进行云测，扩大覆盖面，非正式包可设置补丁成功直接重启，进而不影响云测。

  4. 启用灰度测试，仅针对部分园区下发，并跟踪成功率，崩溃率等数据，进行补丁是否全面下发的判断。