现状
基于上述可安装的插件化方案，跳转Activity由于android底层机制限制，是需要在宿主中的AndroidManifest.xml 注册该Activity。但插件化宿主无法预先知道插件需要使用到的Activity并提前注册，所以位于插件的Activity是无法被直接使用的。但恰恰Activity属于日常开发中最最常用的视图容器类，因此咱们还是需要兼容插件模式下的Activity调用。
方案设计
- hook方案：
着眼于突破底层限制，首先了解Activity启动流程，ActivityThread中总线Instrumentation.execStartActivity 为启动Activity的入口，一系列对待跳转的Activity的判断逻辑都在里面，这里是很好的一个hook点。总体而言是可以新增代理类InstrumentationProxy重写execStartActivity方法干一些有趣的事情_。
- 代理Activity方案：
首先在宿主AndroidManifest.xml中注册一个代理Activity，插件启动Activity时首先调起代理Activity，再通过ClassLoader加载并调用插件Activity的实现方法，模拟Activity启动及生命周期的整个过程。
本次介绍的是代理Activity方案，减少对系统SDK的侵入性。
实现篇：
- 把Activity实现机制抽象成接口，方便宿主与插件对接。
示例代码：
接口类.png
- 预先注册BaseProxyActivity实现静态代理，重写在插件中常用会触发到的方法（生命周期），再就是可以根据intent获取真正的插件实现RootActivity，使得宿主触发ProxyActivity的各种方法时，能同步调用到插件。
示例代码：
代理类.png
- 通过以上方式，优点是可以对源码无入侵而实现调起插件Activity逻辑，缺点是插件开发过程中，并不能保证无感知的被修改的插件Activity开发，而需要适当地做下调整，如插件Activity需实现接口IPluginActivity、还有Theme实现，仍需要对宿主的BaseProxyActivity做兼容或修改。
网友评论