基于Fragment的轻量级Android插件化框架
概述
Android插件化顾名思义，就是把APP分成N多插件，可以随意对插件进行热插拔。插件化带来的好处是，减小了软件耦合，同时开发人员可以模块开发，提高了开发效率，而且线上bug可以通过升级插件方式快速修复。
一般情况下Android的插件就是一个单独的apk，开发模式与Android原生应用没有太大区别。我们要解决的问题是，如何在不安装的情况下把这个apk运行起来。apk内主要包含class.dex和相关资源文件，class.dex内部是Android虚拟机字节码。所以要想APP能运行，需要载入Android虚拟机字节码与插件apk中的资源。
本文写了一个简单的插件化框架，下载地址https://github.com/pengyuntao/yuntao-plugin
本插件使用fragment来构建页面，没有实现service，receiver，provider等的动态加载，这里只是作为学习的例子，当然纯界面应用也可以使用这种架构来分模块开发，动态升级替换模块。
该例子代码不多，阅读下文请对照例子。核心类只有PluginInstallUtils，PluginHostActivity两个类。host工程是宿主工程，plugin1，plugin2，plugin3是插件工程，pluginlib是依赖库工程。运行时候请将三个插件工程打包成apk放在sdcard/yuntao-plugin目录下，没有请创建该目录。
类加载
参考PluginInstallUtils类
要想实现动态加载，第一步需要实现加载插件中的类。JAVA提供了类加载器来加载jar中的类。但是Android识别的是dex文件不同与class文件，所以不能使用JAVA原生的类加载器，还好Android提供了用于加载dex中类的类加载器，DexClassLoader，PathClassLoader。
这两者的区别在于DexClassLoader需要提供一个可写的outpath路径，用来释放.apk包或者.jar包中的dex文件。换个说法来说，就是PathClassLoader不能主动从zip包中释放出dex，因此只支持直接操作dex格式文件，或者已经安装的apk（因为已经安装的apk在cache中存在缓存的dex文件）。而DexClassLoader可以支持.apk、.jar和.dex文件，并且会在指定的outpath路径释放出dex文件。
看DexClassLoader构造方法的几个参数
String dexPath 要加载的apk的绝对路径
String optimizedDirectory apk解压出来的目录
String libraryPath native lib的路径，可以为null
ClassLoader parent 父类加载器
所以我们可以使用以下代码方式来加载一个apk中的类到内存中。
private DexClassLoader createDexClassLoader(Context context,String dexPath){
File dexOutputDir = mContext.getDir("dex", Context.MODE_PRIVATE);
dexOutputPath = dexOutputDir.getAbsolutePath();
DexClassLoader loader = new DexClassLoader(dexPath, dexOutputPath, null, context.getClassLoader());
return loader;
}
资源加载
参考PluginInstallUtils类
资源加载的方法是调用AssetManager中的addAssetPath方法，我们可以将一个apk中的资源加载到Resources中，由于addAssetPath是隐藏api我们无法直接调用，所以只能通过反射，通过注释我们可以看出，传递的路径可以是zip文件也可以是一个资源目录，而apk就是一个zip，所以直接将apk的路径传给它，资源就加载到AssetManager中了，然后再通过AssetManager来创建一个新的Resources对象，这个对象就是我们可以使用的apk中的资源了，这样我们的问题就解决了。
/**
* 创建AssetManager对象
*
* @param dexPath apk路径
* @return
*/
private AssetManager createAssetManager(String dexPath) {
try {
AssetManager assetManager = AssetManager.class.newInstance();
Method addAssetPath = assetManager.getClass().getMethod("addAssetPath", String.class);
addAssetPath.invoke(assetManager, dexPath);
return assetManager;
} catch (Exception e) {
e.printStackTrace();
return null;
}
}
/**
* 创建Resource对象
*
* @param assetManager 上边方法创建的assetManager
* @return
*/
private Resources createResources(AssetManager assetManager) {
Resources superRes = mContext.getResources();
Resources resources = new Resources(assetManager, superRes.getDisplayMetrics(), superRes.getConfiguration());
return resources;
}如何让插件环境载入APP上下文
参考PluginHostActivity类
类与资源已经载入到内存中了，那么如何使用他们呢。
由于我们的界面使用的是fragment，然而fragment必须附加到一个Activity上，因此fragment使用的资源，ClassLoader等都是与附加的Activity相同的。Activity是继承自Context，Context涉及到资源与类加载的有下列三个抽象方法，我们只要实现下列方法就可以了，让下列方法返回上两节中创建的插件的AssetManager，Resources，ClassLoader。
/** Return an AssetManager instance for your application's package. */
public abstract AssetManager getAssets();
/** Return a Resources instance for your application's package. */
public abstract Resources getResources();
/** Return a class loader you can use to retrieve classes in this package.*/
public abstract ClassLoader getClassLoader();由于我们做的是界面相关的还要再实现一个Theme的方法
/** Return the Theme object associated with this Context.*/
public abstract Resources.Theme getTheme();最后我们还是要提供一个Activity当做宿主，我们重写这个Activity的上述四个方法（如果了解Context的架构可以修改ContextImpl也可以，我们直接修改Activity的满足要求了，就没必要去改ContextImpl了）。当然这个时候通过反射加载类并调用方法，有兴趣可以往类中随便写个方法打log测试下。
使用fragment构建页面
参考PluginHostActivity类
由于大多数APP都是由一个个页面组成的，使用Activity来构建页面需要在mainifest文件中注册Activity，APP在安装之初内部的Activity就固定了，不能动态任意添加删除Activity，同时Activity还需要管理生命周期，比较复杂（当然有好多插件框架实现了动态加载任意四大组件，例如DroidPlugin，DL等，有兴趣可以自己去了解相关技术），这里为了简单我们使用fragment来创建界面，fragment没有mainifest的限制，同时fragment由FragmentManager管理，可以任意的创建销毁，所以我们可以做一个纯fragment的应用。
/**
* 反射创建fragment,通过fragmentManager把创建的fragment附加到Activity
* @param fragClass
*/
protected void installPluginFragment(String fragClass) {
try {
if (isFinishing()) {
return;
}
ClassLoader classLoader = getClassLoader();
Fragment fg = (Fragment) classLoader.loadClass(fragClass).newInstance();
Bundle bundle = getIntent().getExtras();
fg.setArguments(bundle);
getSupportFragmentManager().beginTransaction()
.replace(android.R.id.primary, fg).commitAllowingStateLoss();
} catch (Exception e) {
e.printStackTrace();
}
}上述代码通过fragment类全名打开一个fragment，添加到PluginHostActivity中，详情参考PluginHostActivity
fragment之间跳转
参考BaseFragment,PluginHostActivity类
我们设置Activity启动模式为standard模式，每次打开一个Activity实例附加一个fragment，通过Intent把fragment类名传递给Activity，让Activity去反射创建fragment并且加载他，可以BaseFragment里封装一个startFragment方法用来打开页面
加载多个插件
参考PluginInstallUtils,PluginEnv类
加载插件的过程还是很耗时的，所以我们可以通过一个Map把插件加载的数据缓存起来，下次遇到相同的插件就直接取出。
public final static HashMap mPackagesHolder = new HashMap(); 这里使用apkPath作为key，当然这个key只要是唯一的就行，比如可以定义插件id之类的，总之就是为了不重复加载，下次可以根据这个标志能拿到缓存的数据即可。使用插件id也可以达到通过服务器下发插件id来加载插件的目的。value里存储的就是一些插件相关环境，Resource，ClassLoader等
/**
* 插件的运行环境
*/
public class PluginEnv {
public ClassLoader pluginClassLoader;
public Resources pluginRes;
public AssetManager pluginAsset;
public Resources.Theme pluginTheme;
public String localPath;
public PluginEnv(String localPath, ClassLoader pluginClassLoader, Resources pluginRes, AssetManager pluginAsset, Resources.Theme pluginTheme) {
this.pluginClassLoader = pluginClassLoader;
this.pluginRes = pluginRes;
this.pluginAsset = pluginAsset;
this.pluginTheme = pluginTheme;
this.localPath = localPath;
}
}类重复加载导致的类冲突异常问题
参考PluginClassLoader,PluginInstallUtils类
加载多个插件的时候会遇到一个问题，就是当多个插件都引用一个lib，该lib内的类会被加载多次，这个时候使用这些类的时候，就会发生错误。
两种解决方案：让依赖包只参与编译，不打入最终的包内，这个好处是能让插件包小一些；重写类加载器，Android的类加载器是支持双亲委派的，可以保证宿主加载lib的类一份就行了。我们这里使用了第二种重写类加载器的方式。
public class PluginClassLoader extends DexClassLoader {
public PluginClassLoader(String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parent) {
super(dexPath, optimizedDirectory, libraryPath, parent);
}
@Override
protected Class loadClass(String className, boolean resolve) throws ClassNotFoundException {
//如果vm已经加载了,返回该类,否则返回null
Class clazz = findLoadedClass(className);
if (clazz == null) {
//如果vm没有加载让该类的父加载器加载
try {
clazz = this.getParent().loadClass(className);
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
if (clazz == null) {
//当前加载器加载
clazz = findClass(className);
}
}
return clazz;
}
}插件之间跳转
参考PluginHostActivity
其实PluginHostActivity是在宿主中注册的，插件不依赖宿主，所以不能直接显示的startActivity，我们可以通过action方式来让宿主的PluginHostActivity来加载其他插件的fragment。
LayoutInflate加载布局文件自定义控件导致类转换错误问题
参考WidgetLayoutInflaterFactory，PluginHostActivity类
在使用插件升级的时候，使用新的插件替换了旧插件，当layout布局文件中写了自定义控件的时候，打开该页面通常会抛出以下异常。
......
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.yuntao.host/com.yuntao.pluginlib.PluginHostActivity}: java.lang.ClassCastException: com.yuntao.plugin3.CustomTextView cannot be cast to com.yuntao.plugin3.CustomTextView
......
Caused by: java.lang.ClassCastException: com.yuntao.plugin3.CustomTextView cannot be cast to com.yuntao.plugin3.CustomTextView
......在LayoutInflate内部有个静态的Map保存了曾经解析出的View的构造函数，key为控件的name，所以在升级插件之后，由于不同的插件使用了不同的类加载器，类加载器变了，在解析View的时候首先根据name去map中取，会返回旧插件的View。然而当前插件与上个版本插件的ClassLoader不一样，所以会出现类转换错误。
研究下源码，下边代码为缓存的数据结构
private static final HashMap> sConstructorMap =
new HashMap>(); 查看创建view的过程，就是根据view的name，把constructor缓存了起来，存在就直接实例化了，不存在才创建
public final View createView(String name, String prefix, AttributeSet attrs{//略去throws
Constructor constructor = sConstructorMap.get(name);
Class clazz = null;
//略去try catch
if (constructor == null) {
clazz = mContext.getClassLoader().loadClass(
prefix != null ? (prefix + name) : name).asSubclass(View.class);
//此处略去几行
constructor = clazz.getConstructor(mConstructorSignature);
constructor.setAccessible(true);
sConstructorMap.put(name, constructor);
} else {
//此处略去n多行
}
Object[] args = mConstructorArgs;
args[1] = attrs;
final View view = constructor.newInstance(args);
if (view instanceof ViewStub) {
// Use the same context when inflating ViewStub later.
final ViewStub viewStub = (ViewStub) view;
viewStub.setLayoutInflater(cloneInContext((Context) args[0]));
}
return view;
}查看调用createView的代码片段，调用之前会执行几个factory的onCreateView方法，如果factory创建了view，则就返回这个view，就不会走createView的逻辑了。
View view;
if (mFactory2 != null) {
view = mFactory2.onCreateView(parent, name, context, attrs);
} else if (mFactory != null) {
view = mFactory.onCreateView(name, context, attrs);
} else {
view = null;
}
if (view == null && mPrivateFactory != null) {
view = mPrivateFactory.onCreateView(parent, name, context, attrs);
}
if (view == null) {
final Object lastContext = mConstructorArgs[0];
mConstructorArgs[0] = context;
try {
if (-1 == name.indexOf('.')) {
view = onCreateView(parent, name, attrs);
} else {
view = createView(name, null, attrs);
}所以我们可以给LayoutInflate设置一个factory，由于factory2在最前边我们设置factory2，在PluginHostActivity的onCreate方法中设置下列代码
getLayoutInflater().setFactory2(new WidgetLayoutInflaterFactory());WidgetLayoutInflaterFactory实现Factory2接口，自己接管了自定义控件的创建过程。详细可以见Demo的WidgetLayoutInflaterFactory类
class WidgetLayoutInflaterFactory implements LayoutInflater.Factory2 {
private final HashMap> sConstructorMap = new
HashMap>();
private final Class[] mConstructorSignature = new Class[]{Context.class, AttributeSet.class};
private final Object[] mConstructorArgs = new Object[2];
@Override
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
if (name.equals("view")) {
name = attrs.getAttributeValue(null, "class");
}
//如果没有'.'，说明是Android系统控件，直接返回null，让系统自己createView
if (-1 == name.indexOf('.')) {
return null;
}
Context lastContext = (Context) mConstructorArgs[0];
mConstructorArgs[0] = context;
Class clazz = null;
//先从本地缓存读取
Constructor constructor = sConstructorMap.get(name);
try {
if (constructor == null) {
//没有缓存，根据类名创建Constructor对象存入缓存
// Class not found in the cache, see if it's real, and try to add it
clazz = context.getClassLoader().loadClass(name).asSubclass(View.class);
constructor = clazz.getConstructor(mConstructorSignature);
sConstructorMap.put(name, constructor);
}
Object[] args = mConstructorArgs;
args[1] = attrs;
constructor.setAccessible(true);
return constructor.newInstance(args);
} catch (NoSuchMethodException e) {
InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Error inflating class " + name);
ie.initCause(e);
throw ie;
} catch (ClassCastException e) {
// If loaded class is not a View subclass
InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Class is not a View " + name);
ie.initCause(e);
throw ie;
} catch (ClassNotFoundException e) {
// If loaded class is not a View subclass
InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Class not found " + name);
ie.initCause(e);
throw ie;
} catch (Exception e) {
InflateException ie = new InflateException(attrs.getPositionDescription()
+ ": Error inflating class " + (clazz == null ? "" : clazz.getName()));
ie.initCause(e);
throw ie;
} finally {
mConstructorArgs[0] = lastContext;
mConstructorArgs[1] = null;
}
}
@Override
public View onCreateView(String name, Context context, AttributeSet attrs) {
return onCreateView(null, name, context, attrs);
}
} 思考
- 插件包传输过程需要加密，然而虚拟机不能解密，只能解密后加载入虚拟机，要及时删除解密后的插件。
- 为了减小插件大小，还是使用脚本让依赖包只参与编译
- 如果修改了依赖包中的代码与文件，只是发布插件，由于依赖包没有重新加载，所以需要重新发主程序包。
- 依赖包中的资源改变了，R文件变化了，可能导致新发出去的插件，在旧的主程序中找不到资源。
Android类动态加载技术http://www.blogjava.net/zh-weir/archive/2011/10/29/362294.html