前言

  • Robust基于Google提出的Instant run实现。

冷启动更新和热更新

  • 修改代码需要重启进程加载补丁dex，称之为：冷启动更新
  • 修改代码不需要重启进程，称之为：热更新
  • 从Robust的实现机制来看，是可以直接进行热更新功能的。

接入

接入前准备：

  • 依赖关系的统一。
    • 我们在开发中其实会引入非常多的三方库，这些三方库之间可能会有重复的项目依赖关系，看似没什么问题，但是其实很容易引起编译错误。
    • 而Robust的接入，是会进行字节码插桩操作的，它在读取一些中间生成的jar包的时候，如果出现依赖重复的情况，也会导致编译失败。
    • 因此第一步我们就是需要先完成依赖关系的统一。
    • 比如：
      • 在整个工程中所有的support库版本就应该是统一的。
  • 依赖关系的统一，各位可以参考我下面的这篇文章

接入

  • 其实，美团开源出来的robust，已经很长时间不再进行细致的维护了。基本上是处于停止开发的状态，同时一段时间，接收一下大家的PR，做一些merge工作而已。
  • 我猜他们只是把内部robust的一个里程碑做了开源，后续的开发包括资源修复等更高级的功能，应该是不会考虑开源了。
  • 所以，各位同学感兴趣使用robust的话，建议自己fork一份，有什么问题改改，一来能读读源码，而来解决了一些问题也可以提PR。

接入：

优化点：

  • 打包编译控制：

    • 因为在app module中，我们在正常打包的时候，调用的是robust的：

      apply plugin: 'robust'

    • 上面这个插件，是编译apk过程中，robust对class代码进行字节码插桩的插件。这个插件走完，编译出来的apk，是预埋入了热修复桩位逻辑的。

    • 而在我们制作patch的时候，其实使用的是：

      apply plugin: 'auto-patch-plugin'

    • 因此我们完全可以使用gradle自带的控制功能来在gradle编译时，控制到底是编译apk，还是编译patch

    • 步骤如下：

      • 在根目录的build.gradle中，我们生命这样的扩展：
ext {
attach_hot_fix_insert = project.hasProperty('robustPatch')
}
  • app module的build.gradle中，配置如下：
if (rootProject.attach_hot_fix_insert) {

//componentRobustPatch:制作补丁时将这个打开，auto-patch-plugin紧跟着com.android.application
apply plugin: 'auto-patch-plugin'
} else {

apply plugin: 'robust'
}
  • 这样在我们编译项目的时候，传入参数就能控制到底是编译apk还是patch了
./gradlew assembleRelease -ProbustPatch //带上后面的-P参数，就能控制编译patch了

 评论