热修复技术探究

        2015年以来，Android开发领域里对热修复技术的讨论和分享越来越多，同时也出现了一些不同的解决方案，如QQ空间补丁方案、阿里AndFix以及微信Tinker，它们在原理各有不同，适用场景各异，到底采用哪种方案，是开发者比较头疼的问题。最近项目里要用热修复技术,调研了许久,算是摸到门路了,和大家分享下,希望这篇文章能给大家些参考,好了,闲话不多说,正文开始..

            技术背景

 

        本次调研分别从实现原理,类、so、资源替换,性能损耗,接入流程,修复成功率,兼容性等较多方面比选了四个当

                        下 主流的框架,由于阿里百川尚未推出hotfix2.0版本,暂时推荐微信团队的tinker

                          比选框架: QZone补丁方案, 微信团队Tinker, 阿里百川hotfix, 美团Robust

                                        建议大家先了解下dex分包原理,便于大家更好的理解

                                   http://blog.youkuaiyun.com/u010386612/article/details/50885320 

      各框架采用原理分类:

      multidex:  QZone补丁方案, 微信团队Tinker

 native hook:  Andfix

 Instant Run:  Robust

      原理简述:

     multidex:  把BUG方法修复以后，放到一个单独的DEX里，插入到dexElements数组的最前面，让虚拟机去加载修复完后的方法。

 native hook:  运行时在Native修改Filed指针的方式，实现方法的替换，达到即时生效无需重启，对应用无性能消耗的目的

 Instant Run:  对每个产品代码的每个函数都在编译打包阶段自动的插入了一段代码,类似于Android Studio Instant Run原理

 QZone超级补丁技术

  超级补丁技术基于DEX分包方案，使用了多DEX加载的原理，大致的过程就是：把BUG方法修复以后，放到一个单独的DEX里，插入到dexElements数组的最前面，让虚拟机去加载修复完后的方法。

 修复原理                        

 整体流程

    QZone总结

 优势：
没有合成整包（和微信Tinker比起来），产物比较小，比较灵活可以实现类替换，兼容性高。（某些三星手机不起作用）
  不足：
1. 不支持即时生效，必须通过重启才能生效。
2. 为了实现修复这个过程，必须在应用中加入两个dex！dalvikhack.dex中只有一个类，对性能影响不大，但是对于patch.dex来说，修复的类到了一定数量，就需要花不少的时间加载。对手淘这种航母级应用来说，启动耗时增加2s以上是不能够接受的事。
3. 在ART模式下，如果类修改了结构，就会出现内存错乱的问题。为了解决这个问题，就必须把所有相关的调用类、父类子类等等全部加载到patch.dex中，导致补丁包异常的大，进一步增加应用启动加载的时候，耗时更加严重。

 微信Tinker

     微信针对QQ空间超级补丁技术的不足提出了一个提供DEX差量包，整体替换DEX的方案。主要的原理是与QQ空间超级补丁技术基本相同，区别在于不再将patch.dex增加到elements数组中，而是差量的方式给出patch.dex，然后将patch.dex与应用的classes.dex合并，然后整体替换掉旧的DEX，达到修复的目的

    修复原理

    

     整体流程

     

      Tinker总结

     优势：
1.合成整包，不用在构造函数插入代码，防止verify，verify和opt在编译期间就已经完成，不会在运行期间进行。
2.性能提高，兼容性和稳定性比较高。
3.开发者透明，不需要对包进行额外处理。
4.目前主流框架中使用人数最多,后续开发遇到坑好解决
      不足：
1. 与超级补丁技术一样，不支持即时生效，必须通过重启应用的方式才能生效。
2. 需要给应用开启新的进程才能进行合并，并且很容易因为内存消耗等原因合并失败。
3. 合并时占用额外磁盘空间，对于多DEX的应用来说，如果修改了多个DEX文件，就需要下发多个patch.dex与对应的classes.dex进行合并操作时这种情况会更严重。

 阿里AndFix(hotfix基于andfix)

   AndFix不同于QQ空间超级补丁技术和微信Tinker通过增加或替换整个DEX的方案，提供了一种运行时在Native修改Filed指针的方式，实现方法的替换，达到即时生效无需重启，对应用无性能消耗的目的。

 修复原理

 

 整体流程

  

    AndFix总结

  优势：
1.BUG修复的即时性
2.补丁包同样采用差量技术，生成的PATCH体积小
3.对应用无侵入，几乎无性能损耗
  不足：
1. 不支持新增字段，以及修改<init>方法，也不支持对资源的替换
2. 由于厂商的自定义ROM，对少数机型暂不支持
3. 合并时占用额外磁盘空间，对于多DEX的应用来说，如果修改了多个DEX文件，就需要下发多个patch.dex与对应的classes.dex进行合并操作时这种情况会更严重。

 美团Robust
  Robust插件对每个产品代码的每个函数都在编译打包阶段自动的插入了一段代码，插入过程对业务开发是完全透明。为每个class增加了个类型为ChangeQuickRedirect的静态成员，而在每个方法前都插入了使用changeQuickRedirect相关的逻辑，当 changeQuickRedirect不为null时，可能会执行到accessDispatch从而替换掉之前老的逻辑，达到fix的目的

 修复原理

 

 Robust总结

  优势：
1.BUG修复的即时性
2.补丁包同样采用差量技术，生成的PATCH体积小

  不足：
1. 不支持新增字段，以及修改<init>方法，也不支持对资源的替换
2.使用人数较少,后续问题和坑多少未知

 综合比较:

  

   tinker接入流程(https://github.com/Tencent/tinker)

  1在项目的build.gradle中，添加tinker-patch-gradle-plugin的依赖
buildscript {
    dependencies {
        classpath ('com.tencent.tinker:tinker-patch-gradle-plugin:1.7.7')
    }
}
然后在app的gradle文件app/build.gradle，我们需要添加tinker的库依赖以及apply tinker的gradle插件
dependencies {
    //optional, help to generate the final application
    provided('com.tencent.tinker:tinker-android-anno:1.7.7')
    //tinker's main Android lib
    compile('com.tencent.tinker:tinker-android-lib:1.7.7')
}

apply plugin: 'com.tencent.tinker.patch'

2 在build.gradle中的最外层添加下边的配置,这些个配置的意义可以看:https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97 ; 这些配置是从demo中挑出来的,有的配置也不是必须的;

  3 添加(或修改)项目的 Application ,使之继承DefaultApplicationLike; 这块有点奇葩,这个DefaultApplicationLike不是继承自Application,需要用注解来设置项目中真正的Application,Tinker插件会自动生成真正的Application

 

  上边的"ook.yzx.tinker.Application"就是真正的Application,不用我们自己写,是自动生成的;然后修改manifest.xml将application指向ook.yzx.tinker.Application就行,开始会报错,build一下项目就好了;

  4  Java代码操作
最开始的时候我是使用第一个构造方法，只需要传入ApplicationLike这一个参数就可以了，也可以热修复成功，但是每次修复成功后app就会被杀掉。这是因为如果使用第一个构造方法，Tinker就会使用默认参数，从第二个构造方法可以看到除了ApplicationLike外初始化的时候还使用了其它五个参数，他们的五个默认类分别是：

 

 
  (截图可能不太清楚,后边有demo链接,大家可以看源码)

  5 Java代码操作
其中DefaultTinkerResultService中能接收到热修复的结果，查看这个类的源码可以发现，当修复成功后，就调用了杀掉进程的方法。因此如果不想把进程杀掉，就需要重写这个类，修改里面的方法,最后记得在清单里面配置service

 

  

  4 编译运行原版apk(存在bug的apk)
按照往常操作一样,编译运行并安装.此时Tinker会在工程的app/build/bakApk/目录下保存打包好的apk文件,找到刚才生成的apk文件,复制其完整文件名,在app的build.gradle文件找到tinkerOldApkPath这一项设置,并将其设置为tinkerOldApkPath = "${bakPath}/<刚才生成的apk文件名>"(见图2)

 

  5 修改bug,生成差异补丁( 双击studio右侧tinkerpatchDebug)

 

  6  运行完毕后,Tinker会告诉你生成的补丁apk文件所在位置

 

  7  将patch_signed_7zip.apk这个文件拷贝到Android设备的ExternalStorageDirectory()路径下,记得加sd卡读写权限,文件的路径可以随意设定,只需在MainActivity中指明补丁Apk路径即可

  

 TinkerInstaller.onReceiveUpgradePatch方法就是加载补丁的核心方法
 在正式环境中，热修复应该是这样进行的。 后台应该提供一个接口，每次app启动的时候，访问这个接口看需不需要热修复，如果需要，后台要返回补丁包的下载地址。app获取到补丁包地址后开始下载补丁包到手机中，下载完成之后启动热修复，也就是执行上面那句代码。 修复完成之后，app需要重新启动，修复才会生效

 7 从输出日志可以判断是否加载成功,成功后结束进程,下次打开就生效了

 

 Demo地址:  https://github.com/cheweili/TinkerTestDemo.git

  官方介绍以及问题汇总：https://github.com/Tencent/tinker/wiki

  微信tinker 技术交流群：  377388954