Android插件化初识
含义:可以简单理解为将一个app分为多个小的app,其中有一个为宿主app。
解决的主要问题:代码加载、资源加载。
插件的方式:apk安装,apk不安装,dex包
插件化的优点:
1) 模块解耦,应用程序扩展性强
2) 解除单个dex函数不能超过 65535的限制
3) 动态升级,下载更新节省流量
4) 高效开发(编译速度更快)
插件化的缺点:
1) 增加了主应用程序的逻辑难度
2) 技术有难度,目前一些成熟的框架都是闭源的
插件化开发—动态加载技术加载已安装和未安装的apk
动态加载技术就是使用类加载器加载相应的apk、dex、jar(必须含有dex文件),再通过反射获得该apk、dex、jar内部的资源(class、图片、color等等)进而供宿主app使用。
代码加载:
类的加载可以使用Java的ClassLoader机制,还需要组件生命周期管理。
资源加载:
用AssetManager的隐藏方法addAssetPath。
插件化必备基础:
ClassLoader类加载器
要想实现加载外部dex文件(即插件)来实现热部署,那么必然要把其中的class文件加载到内存中。
其中涉及到两种ClassLoader:DexClassLoader和PathClassLoader。而DexClassLoader可以加载外部的jar,dex等文件,正是我们需要的。
Java反射
因为插件apk与宿主apk不在一个apk内,那么一些类的访问必然要通过反射进行获取。所以了解反射对插件化的学习是必须的。
插件资源访问
res里的每一个资源都会在R.java里生成一个对应的Integer类型的id,APP启动时会先把R.java注册到当前的上下文环境,我们在代码里以R文件的方式使用资源时正是通过使用这些id访问res资源,然而插件的R.java并没有注册到当前的上下文环境,所以插件的res资源也就无法通过id使用了。
查看源码,通过“addAssetPath”方法重新生成一个新的Resource对象来保存插件中的资源,避免冲突。
代理模式
插件化实现的过程主要靠欺上瞒下,坑蒙拐骗来实现。想想虽然加载进来了Activity等组件,但也仅仅是最为一个对象而存在,并没有在AndroidManifest中注册,没有生命周期的回调,并不能实现我们想要的效果。因此无论是dynamic_load_apk通过代理activity来操控插件activity的方式,还是DroidPlugin通过hook activity启动过程来启动插件activity的方式,都是对代理模式的应用。