作用
- 宿主和插件分开编译 编译时只需要编译宿主 插件是在编译完成之后下发到宿主的
- 并发开发 宿主发布版本不受插件影响 只需要提供一个入口给插件
- 动态更新插件
- 按需下载模块
- 65536
与组件化的区别
- 组件化将app拆分成多个模块 开发过程中相互依赖或者单独调试 每个组件相当于一个lib
- 插件化也是拆分成很多模块 包括宿主和插件 每个插件都是一个apk
生命周期方案
- 接口回调控制生命周期
- 利用ActivityThread 和Instrumentation hook ProxyActivity
- 改变AMS PMS 源码
步骤
① PackageManager获取插件入口activity
② 构造dexclassloader更换ProxyActivity的classloader
③ 反射AssetManager 重新构造resources
难点
- 插件中 ClassLoader 的问题；
DexClassLoader可以加载jar/apk/dex 可以加载未安装的apk; PathClassLoader只能加载已经安装过的apk
替换宿主activity的classloader目的是 加载插件apk的class - 插件中的资源文件访问问题；
AssetManager实例并且反射调用addAssetPath方法 - 插件中 Activity 组件的生命周期问题；
封装一个instrumentation，替换掉宿主的 (InstrumentationWrapper) - .so 文件加载
- Service 插件化
small分析
为什么用到.so?
- so机制让开发者最大化利用已有的C和C++代码，达到重用的效果，利用软件世界积累了几十年的优秀代码
- so是二进制，没有解释编译的开消，用so实现的功能比纯java实现的功能要快
- so内存分配不受Dalivik/ART的单个应用限制，减少OOM
- 相对于java代码，二进制代码的反编译难度更大，一些核心代码可以考虑放在so中
通过buildLib和buildBundle来把非宿主的app中的文件打包为.so文件，我们最终安装到手机上的apk其实就是只有宿主的apk和其内部的.so文件，通过加载.so文件来实现加载插件中的文件
使用注意点
- 模块名形如：app., lib.或者web.* ; 包名包含：.app., .lib.或者.web. Small会根据包名对插件进行归类
- bundle.json 注册依赖模块
- 宿主moudle不能引入依赖模块(lib) 只能是插件模块引入依赖模块
- 列表内容更新：cleanLib->cleanBundle->buildLib(准备基础库)->buildBundle(打包所有组件)
- 各个插件模块的fragment命名一定要是MainFragment不然会出现空指针异常
- createObject前，需要再此页面之前已经存在activity
核心原理
- Android类由DexClassLoader加载
- 安卓资源由AssetManager加载 创建AssetManager实例并且反射调用addAssetPath方法添加资源搜索路径 ；为避免id冲突宿主以及各个插件之间的资源id需要分段处理，解决方案：重新打包，重新设置id
- 生命周期受Instrumentation监控 封装一个instrumentation，替换掉宿主的 (InstrumentationWrapper)
关于smallLibs
- 存放组件.so包
- 宿主运行时自动复制其下.so到缓存区
相关问题
- 对Service的支持
支持动态加载，不支持动态注册 - 插件和宿主必须在同一个进程
- 宿主和各个插件之间的资源可以互相访问 支持sf
