1、研究主流的热修复框架后,你会发现andfix和dexposed采用jni hook方法,不用重启就能修复,而Nuwa的ClassLoader思路因为类被虚拟机加载后,不会重新加载,所以需要重启。Instant Run是怎么实现不重启加载的呢,难道也是jni hook?
2、Instant Run原理
一个插件一个库,Instant Run用的是gradle plugin和instant-run.jar。
3、gradle plugin的两个作用
(1)第一次运行,应用transform API修改字节码。
step1:给所有的类添加$change字段,$change为IncrementalChange类型,IncrementalChange是个接口。
step2:修改类的全部方法(新的逻辑是:如果$change不为空,去调用$change的access$dispatch方法,参数为方法签名字符串和方法参数数组,否则调用原逻辑。)
(2)后续运行,dx补丁类,生成补丁dex。
step1:被修改类对应的补丁类
补丁类,并不是你修改后的类,而是由gradle plugin自动生成,实现了IncrementalChange接口的类。
该类类名在原名后面添加$override,复制修改后类的大部分方法,实现IncrementalChange 接口的access$dispatch方法,该方法会根据传递过来的方法签名,调用本类的同名方法。
只要把原类的$change字段设置为该类,那就会调用该类的access$dispatch方法,就会使用修改后的方法了。
step2:被修改类的记录类
AppPatchesLoaderImpl记录了所有被修改的类,也会被打进补丁dex。
4、instant-run.jar
设置原类的$change字段为补丁类
(1)AppPatchesLoaderImpl类不但记录了全部被修改的类,还提供load方法支持设置被修改原类$change字段.
(2)当收到补丁通知时,新建一个DexClassLoader,去反射加载补丁dex中的AppPatchesLoaderImpl类,调用load方法即可,load方法中会去加载全部补丁类,并赋值给对应原类的$change。
以上主要是探究Instant Run处理代码变化的思路,对资源变化没有分析。