目標和期望
1）侵入性低
最好任何拿來的apk 就可以直接用。
（1）不侵入參與目標apk開發編譯
（2）不參與插件apk的編譯打包
（3）不調用自定義api來替換系統的api
2）高適配
兼容後續的版本，無特殊處理
3）高穩定和效率
基本抽象實現方案梳理
1）要啓動插件中的四大組件，要麼是代理組件，要麼是編譯到宿主中apk，當後者明顯侵入到打包流程了。
2）使用代理方式，要替換插件的組件爲代理類，要麼是在啓動組件之前替換成代理類組件，要麼是在進入系統流程之後找個時機hook攔截替換成代理類，所以不是侵入目標插件Apk編譯，就是攔截系統啓動組件的流程。
3）所以採用Hook方案，攔截組件加載流程，實現”偷樑換柱“：主要分爲Activity加載和其他組件兩種流程
架構圖
實現原理簡介
如上架構圖所示，爲了實現組件Activity、Service、ContentProvider的生命週期由系統AMS管理，而採取了Hook 方案，而不需要框架來實現入侵式的替換組件的父類來通過反射的方式同步生命週期。
對於插件Apk加載生成PluginApk對象由PluginManager進行統一管理插件的生命週期：校驗、脫殼解密、安裝、加載解析、啓動、檢查更新等。
對於Apk的資源和類加載分別通過創建ResourceProxy和PluginClassLoader來實現，其中自定義PluginClassLoader重寫了類的加載流程，詳見下文類加載機制。而資源提供插件是否需要合併Host宿主資源，一般插件資源獨立存在加載使用。
插件UI通信支持者UIProvideSupporter，爲實現組件化之間的通信。方便插件之間，宿主與插件之間的UI數據通信。主要是爲了解決當組件插件向外暴露View 或者 Fragment的時候，或者Dialog，需要的資源是本插件的，需要單獨提供該插件的上下問Context，故UIProvider需要實現對插件資源的Context創建暴露給相關UI控件。
同時提供ApiProvider來實現插件之間的路由跳轉，便於多PluginClassLoader之間跳轉查詢對應的Api 實體。
類加載機制
由上圖可知：
PluginClassLoader以PathClassLoader爲parent，並重寫了loadClass的流程；
PluginClassLoader自身loadClass的順序爲
findLoadedClass
findOwn： 查找dex 自身內部的class
findPath： 查找主apk中的class
資源加載機制
採用多Resources機制:對每個插件的資源單獨加載資源，生成獨立的AssetManager,供每個PluginResource使用。
爲了避免Android P的限制，不採用反射addAssetsPath接口方式來生成AssetsManager，具體方法參見Android P適配