Android热修复技术选型——三大流派解析

正文

请到「今天看啥」查看全文

可以看到，这里是要加载一个libs目录下的dalvikhack.jar。在项目的assets/libs找到该文件，解压得到classes.dex文件，逆向打开该DEX文件，

通过不同的DEX加载进来，然后在每一个类的构造方法中引用其他dex中的唯一类AnitLazyLoad，避免类被打上CLASS_ISPREVERIFIED标志。

在无修复的情况下，将DO_VERIFY_CLASSES设置为false，提高性能。只有在需要修复的时候，才设置为true。

至于如何加载进来，与接下来第二个步骤基本相同。

2. 加载修复的DEX

从loadPatchDex()方法进入，经过几次跳转，到达核心的代码段，SystemClassLoaderInjector.c()。由于进行了混淆和多次方法的跳转，于是将核心代码段做了如下整理：

修复的步骤为：

1. 可以看出是通过获取到当前应用的Classloader，即为BaseDexClassloader

2. 通过反射获取到他的DexPathList属性对象pathList

3. 通过反射调用pathList的dexElements方法把patch.dex转化为Element[]

4. 两个Element[]进行合并，把patch.dex放到最前面去

5. 加载Element[]，达到修复目的

整体的流程图如下：

从流程图来看，可以很明显的找到这种方式的特点：

优势：

1. 没有合成整包（和微信Tinker比起来），产物比较小，比较灵活

2. 可以实现类替换，兼容性高。（某些三星手机不起作用）

不足：

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，达到修复的目的。

我们来逆向微信APK看一下具体的实现：

先找到应用入口TinkerApplication，在onBaseContextAttached()调用了loadTinker(),

请到「今天看啥」查看全文