插件化的基本概念
我们在第一篇文章中就介绍过插件化的基本概念，这里再强调一次。
随着下面这些问题的出现：
- APP的体积越来越大，功能模块越来越多
- 模块之间的耦合度高，协同开发沟通成本越来越大
- 方法数目可能超过65535，APP占用的内存过大
相应的解决办法：
- 将一个大的APK按照业务划分为多个小的APK
- 每个小的APK又可以独立运行、又可以依附于宿主APK运行
那么，就会有如下优势：
- 业务模块之间基本完全解偶
- 协同并行开发成为可能，提高了Gradle的编译速度
- 业务模块可以按照需要进行加载，降低内存的占用
于是乎，插件化的技术油然而生。
在插件化的技术中，有几个常见的属于：
- 宿主：主APP，也叫作Host，它可以独立运行，也可以加载插件。宿主必须安装到用户手机上，提供基本的类库与功能
- 插件：也叫作Plugin，跟普通APP一样，可以独立运行，也可以由宿主进行加载
- 插件化：将一个应用按照宿主&插件的方式改造的过程就叫做插件化
以Small为例，应用插件化改造后的项目架构如下（Small框架的插件以so为后缀）：
插件化与组件化、热修复的对比
插件化与组件化的对比：
- 组件化是一种编程思想，插件化是一种技术
- 组件化是为了提高代码的高度可复用性；插件化是为了解决应用越来越庞大等问题而出现的
插件化与热修复（动态更新）对比：
- 两者都是动态加载技术的应用
- 使用场景不同，热修复是为了解决线上的不过或者小功能的更新而出现的；插件化是为了解决应用越来越庞大等问题而出现的
具体的区分可以用下图来展示：
插件化原理
插件化的核心原理有一下几点：
- Class文件加载Dex原理
- Android资源加载与管理
- 四大组件的加载与管理
- Java反射原理
- so库的加载原理
- Android系统服务的运行原理
- Gradle打包原理
- 清单文件的合并处理
不同的框架，原理都有差异，鉴于文章篇幅，在这里只介绍最核心、最重要的部分。
- Dex（APK）的加载原理
首先我们需要掌握Android Classloader的分类和基本原理，这在前面的文章中已经有所介绍。
Dex（APK）的加载相关的核心代码如下：
private void loadApk(String apkPath) {
File optDir = getDir("opt", MODE_PRIVATE);
//初始化classLoader，optDir是Dex文件的解压目录
DexClassLoader classLoader = new DexClassLoader(apkPath,
optDir.getAbsolutePath(), null, this.getClassLoader());
try {
Class cls = classLoader.loadClass("具体的一个类");
if (cls != null) {
//通过反射创建对象、调用方法
Object instacne = cls.newInstance();
Method method = cls.getMethod("方法名");
method.invoke(instacne);
}
} catch (Exception e) {
e.printStackTrace();
}
}
一般来说，插件化框架都会进行自定义ClassLoader，以便于更好地管理并维护ClassLoader：
public class CustomClassLoader extends DexClassLoader {
public CustomClassLoader(String dexPath, String optimizedDirectory, String librarySearchPath, ClassLoader parent) {
super(dexPath, optimizedDirectory, librarySearchPath, parent);
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] classData = getClassData(name);
if (classData != null) {
return defineClass(name, classData, 0, classData.length);
} else {
throw new ClassNotFoundException();
}
}
private byte[] getClassData(String name) {
try {
InputStream inputStream = new FileInputStream(name);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int buffersize = 4096;
byte[] buffer = new byte[buffersize];
int bytesNumRead = -1;
while ((bytesNumRead = inputStream.read(buffer)) != -1) {
baos.write(buffer, 0, bytesNumRead);
}
return baos.toByteArray();
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
}
可以看到这里改写了findClass方法，先通过自己的getClassData方法去查找类，防止了加载不同Dex文件的同一个类不会被重复加载的问题。
- Android资源加载与管理
AssetManager、resoures等类与资源的加载与管理息息相关，无论是加载有ID或者没有ID的文件，如下图所示：
插件化框架需要为每个插件创建对应的加载器、AssetManager、resoures。代码如下所示：
//为插件apk创建对应的classLoader
private static DexClassLoader createPluginDexClassLoader(String apkPath) {
DexClassLoader classLoader = new DexClassLoader(apkPath,
mOptFile.getAbsolutePath(), null, null);
return classLoader;
}
//为对应的插件创建AssetManager
private static AssetManager createPluginAssetManager(String apkPath) {
try {
AssetManager assetManager = AssetManager.class.newInstance();
Method addAssetPath = assetManager.getClass().getMethod("addAssetPath",
String.class);
addAssetPath.invoke(assetManager, apkPath);
return assetManager;
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
//为对应的插件创建resoures
private static Resources createPluginResources(String apkPath) {
AssetManager assetManager = createPluginAssetManager(apkPath);
Resources superResources = mContext.getResources();
Resources pluginResources = new Resources(assetManager,
superResources.getDisplayMetrics(), superResources.getConfiguration());
return pluginResources;
}
AssetManager、Resources是插件资源加载与管理的最核心的类，通过反射调用AssetManager的addAssetPath把插件中的资源加载进来，并且会进行相应的管理。
注：如果是安装过的APK，系统会自动帮我们创建AssetManager，我们直接通过Context就可以获取AssetManager；如果是自己加载插件APK，就需要自己创建AssetManager了。
- 四大组件的加载与管理
四大组件最常用就是Activity，因此这里以Activity为例进行介绍。
四大组件需要解决是否需要在清单文件中注册的难题，目前流行的插件化加载与管理Activity原理有两种：
- 通过ProxyActivity进行代理
- 通过Hook系统服务Activity Manager Service绕过清单文件的注册
相应的资料可以参考任玉刚大神以及LooperJing大神的文章：
http://blog.csdn.net/singwhatiwanna/article/details/22597587
