【Android】Instant Run原理解析

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处理代码变化的思路，对资源变化没有分析。