插件化原理概要总结

插件化框架

如果加载的插件不需要和宿主有任何搞合，也无须和宿主进行通信，比如加载第三方App ，那么推荐使用RePlugin ，其他的情况推荐使用VirtualApk。

https://github.com/CtripMobile/DynamicAPK  更新到2015年

https://github.com/DroidPluginTeam/DroidPlugin 仍在更新

https://github.com/Qihoo360/RePlugin 仍在更新

https://github.com/singwhatiwanna/dynamic-load-apk 更新到2017年

https://github.com/wequick/Small  更新到2018年，跨平台 android,ios

https://github.com/didi/VirtualAPK 仍在更新

四大组件插件化

Activity 插件化

四大组件的插件化是插件化技术的核心知识点，而Activity 插件化更是重中之重，Activity 插件化主要有3 种实现方式，分别是反射实现、接口实现和Hook 技术实现。反射实现会对性能有所影响，主流的插件化框架没有采用此方式，关于接口实现可以阅读
dynamic-load-apk 的源码，这里不做介绍，目前Hook 技术实现是主流，因此本章主要介绍Hook 技术实现。
Hook 技术实现主要有两种解决方案， 一种是通过Hook IActivityManager 来实现，另一种是Hook Instrumentation 实现

 

Service 插件化

Activity 插件化的重点在于要保证它的生命周期，而Service 插件化的重点是保证它的优先级，这就需要用一个真正的Service 来实现，而不是像占坑Activity 那样起一个占坑的作用。当启动插件Service 时，就会先启动代理Service ，当这个代理Service 运行起来之后，在它的onStartCommand 等方法里面进行分发，执行插件Ta电etService 的onCreate 等方法，这一方案就叫作代理分发。

 

ContentProvider 插件化

ContentProvider 插件化的关键在于将ContentProvider 插件共享给整个系统。和Service插件化类似，需要注册一个真正的Co ntentProvider 作为代理ContentProvider ，并把这个代理ContentProvider 共享给整个系统，对于插件ContentProvider 的请求会全部交由代理ContentProvider 处理并分发给对应的插件ContentProvider 。

 

BroadcastReceiver 的插件化

将静态注册的BroadcastReceiver，全部转换为动态注册来处理。

 

代码插件化

将宿主和插件的DexElements 合并得到allDexElements，并通过反射用allDexElements 替换dexElements。

 

资源的插件化

资源的插件化方案主要有两种：

一种是合并资源方案，将插件的资惊全部添加到宿主的Resources中，这种方案插件可以访问宿主的资源。

另一种是构建插件资源方案，每个插件都构造出独立的Resources ，这种方案插件不可以访问宿主资源。

 

so 的插件化

so 的插件化的简单来说就是将so 插件插入到NativeLibraryElement 数组中，井且将存储so 插件的文件添加到nativeLibraryDirectories 集合中就可以了。

 

摘自：<Android进阶解密>第15章，插件化原理