Instant Run 浅析

最新推荐文章于 2024-02-09 01:00:42 发布

难者亦易矣

最新推荐文章于 2024-02-09 01:00:42 发布

阅读量529

点赞数

分类专栏： Android基础文章标签： android

23 篇文章 0 订阅

订阅专栏

原文地址：http://jiajixin.cn/2015/11/25/instant-run/

google官方关于Instant Run特性的介绍在这里：https://sites.google.com/a/android.com/tools/tech-docs/instant-run，按其所述，运行FloatingActionButtonBasic样例，实验Instant Run，豪爽豪爽。

但是，修改方法竟然不用重启Activity，这是怎么做到的？

阅读一帆关于几个热补丁思路的介绍，你会发现andfix和dexposed采用jni hook方法，不用重启就能修复，而Nuwa的ClassLoader思路因为类被虚拟机加载后，不会重新加载，所以需要重启。Instant Run是怎么实现不重启加载的呢，难道也是jni hook？

和nuwa类似，一个插件一个库，Instant Run用的是gradle plugin 2.0.0-alpha1和instant-run.jar。

gradle plugin 2.0.0-alpha1主要有两个作用：

instant-run.jar的路径为Application/build/intermediates/incremental-runtime-classes/debug/instant-run.jar。

instant-run.jar是gradle plugin帮我们自动打到dex中去的，省去了compile dependency这一步。它的主要作用有两个：

设置原类的$change字段为补丁类

需要对被修改的类设置$change字段，那怎么知道哪些类被修改了？

AppPatchesLoaderImpl类不但记录了全部被修改的类，还提供load方法支持设置被修改原类$change字段，当收到补丁通知时，只需新建一个DexClassLoader，去反射加载补丁dex中的AppPatchesLoaderImpl类，调用load方法即可，load方法中会去加载全部补丁类，并赋值给对应原类的$change。
重启加载补丁类

重启后怎么办？原来的补丁文件需要加载进来。

IncrementalClassLoader会在Application中去加载该应用cache目录中的补丁dex，把它设置为默认PathClassLoader的parent，由于ClassLoader采用双亲委托模型，会先去parent查找类，所以就可以加载补丁类了。

google的介绍中，也提到了Instant Run的一些局限之处，比如变量、添加删除方法等，当然这一切都会持续优化，gradle plugin 2.0也还仅仅是个alpha版本而已。

Instant Run的实现思路蛮笨的，几乎所有的方法都修改逻辑，但不用重启这一点很赞，用这个思路可以搞一个热修复库了，有官方背景的库。

本文主要是探究Instant Run处理代码变化的思路，对资源变化没有分析，对于一些细节比如server实现、socket传输、application替换、updateMode处理亦未提及。

关注