了解了android中类载入的前期知识点后,来看看android中DexClassLoader详细的实现
详细载入流程例如以下:
宿主程序会到文件系统比方SD卡中去载入APK【1】,然后通过一个叫proxy的Activity去运行apk中的Activity
关于动态载入ap。理论上可用用到DexClassLoad、PathClassLoader、URLClassLoader;
DexClassLoader: 能够载入文件系统上的jar、dex、apk
PathClassLoader:能够载入 /data/app 文件夹下的apk,这也意味着它仅仅能载入已经安装的apk
URLClassLoader:能够载入java中的jar,但因为android中的dalvik不能直接识别jar,全部该方法在android中无法使用。尽管有这个类
获取AssetsManager
载入的方法是通过反射,通过调用AssetManager中的addAssetPath方法。我们能够将一个apk中的资源载入到Resources中,因为addAssetPath是隐藏api我们无法直接调用,所以仅仅能通过反射,以下是它的声明,通过凝视我们能够看出,传递的路径能够是zip文件也能够是一个资源文件夹。而apk就是一个zip。所以直接将apk的路径传给它,资源就载入到AssetManager中了,然后再通过AssetManager来创建一个新的Resources对象,这个对象就是我们能够使用的apk中的资源了
封装数据:
1:把classLoader、assetManager、resource作为插件的成员。封装成bean
2:多插件时通过Map维护,当中key为apk的packageName
插件载入到内存流程:
载入插件的Activity:
? 插件Activity本身无法启动(生命周期,资源等问题),是通过宿主提供的ProxyActivity来载入的。
? 当我们发Intent去启动插件当Activity时实质启动的是ProxyActivity
? 为了封装细节所以封装了DXIntent
? 全部插件实现了IDXPlugin接口
PrxoyActivity接管了全部插件Activity
DXPluginBean 封装bean
?封装了每一个Plugin也就是apk的数据
? 维护在DXPluginManger类的Map中
DXPluginManager 插件管理核心类
? 载入插件、启动插件、插件维护
IDXPlugin:
?把每一个插件的Activity抽象成一个“插件”
? IDXPlugin实现了Activity的主要方法
? onAttach方法是插件专用的回调方法,当插件Activity被Proxy载入当时候。把proxy的引用赋值给that
DXIntent:
? pluginPackgeName: 跳转的Plugin的包名,也就是Manifest里的packageName
pluginClassName:跳转的Plugin中指定的ActivityName,能够传null,则默认时跳转main Activity
DXPluginBaseActivity、DXPluginBaseFragmentActivity:
全部插件Activity继承这两个Activity
该Activity实现IDXPlugin接口
onAttach方法中获得proxyActivity的引用
? 全部activity继承方法中须要对插件本身启动还是在宿主中被启动进行推断 ----》FROM_INTERNAL和FROM_EXTERNAL
DXProxyActivity、DXProxyFragmentActivity :.
? 宿主Activity
? 在host中调用插件Activity的跳转,本质就是这两个Activity之间的跳转
? 为插件提供真正的Context
? 为降低反复代码将插件的初始化放在DXPluginInitializer类中
DXPluginInitializer
?修复theme带来的崩溃问题
? 启动插件Activity
1 通过反射获得插件Activity的默认构造函数
2 通过反射new出一个插件并强转成IDXPlugin
3 回调onAttach方法传入Prxoy的引用
4 调用onCreate方法调起插件
能够直接參考demo: