关于Android插件框架机制的介绍，我打算分几章来介绍，这是第一篇也就是预热篇。
为什么使用插件化
随着应用的模块化的不断增加，APK的体积不断增长，方法数很可能会引发64K问题（解决方案），谷歌提供的方案并不完美，而且APK的启动速度会受影响。
- 提高工程的运行速度，每个模块作为一个独立的插件进行开发和调试。
- 提高应用的启动速度，应用启动时可以选择只加载必须的模块，其他模块使用时再加载
- 多团队并行开发
- 在线动态加载或更新模块
- 灵活的功能配置
基础知识
机制
插件化的根本思路就是让你的应用调用未安装的apk，jar，dex文件中的方法。
在Android中，系统提供了两个API可供选择：
- PathClassLoader:只能加载已经安装到Android系统中的APK文件，这个是另一种加载思路，但是跟插件化没关系，这里不提。
- DexClassLoader：支持加载外部的APK，Jar，或Dex文件。
基础示例
我们先写一个插件APK，新建一个工程，修改MainActivity：
public class MainActivity extends Activity {
private Activity otherActivity;
@Override
public void onCreate(Bundle savedInstanceState) {
boolean b = false;
if (savedInstanceState != null) {
b = savedInstanceState.getBoolean("KEY_START_FROM_OTHER_ACTIVITY", false);
if (b) {
this.otherActivity.setContentView(new TBSurfaceView(
this.otherActivity));
}
}
if (!b) {
super.onCreate(savedInstanceState);
// setContentView(R.layout.main);
setContentView(new TBSurfaceView(this));
}
}
public void setActivity(Activity paramActivity) {
this.otherActivity = paramActivity;
}
}
在被加载的Activity中是不是识别和加载资源文件的，所以不能用布局文件，只能用一个View。
public class TBSurfaceView extends SurfaceView implements SurfaceHolder.Callback, Runnable {
private SurfaceHolder sfh;
private Thread th;
private Canvas canvas;
private Paint paint;
public TBSurfaceView(Context context) {
super(context);
th = new Thread(this);
sfh = this.getHolder();
sfh.addCallback(this);
paint = new Paint();
paint.setAntiAlias(true);
paint.setColor(Color.RED);
this.setKeepScreenOn(true);
}
public void surfaceCreated(SurfaceHolder holder) {
th.start();
}
private void draw() {
try {
canvas = sfh.lockCanvas();
if (canvas != null) {
canvas.drawColor(Color.WHITE);
canvas.drawText("Time: " + System.currentTimeMillis(), 100,
100, paint);
}
} catch (Exception ex) {
ex.printStackTrace();
} finally {
if (canvas != null) {
sfh.unlockCanvasAndPost(canvas);
}
}
}
public void run() {
while (true) {
draw();
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public void surfaceChanged(SurfaceHolder holder, int format, int width,
int height) {
}
public void surfaceDestroyed(SurfaceHolder holder) {
}
}
然后将生成的apk，不要安装在手机，而是存入手机，比如我们就存入sd卡的根目录，可以使用adb命令：
adb push /Users/xxxxx/file/source/loadActivity/app/build/outputs/apk/app-debug.apk /sdcard/
然后我们新建一个应用，写一个加载的方法：
public void dex() {
String apkPath = "/sdcard/app-debug.apk";
String optPath = "/mnt/sdcard/";
// String libPath = info.activityInfo.applicationInfo.nativeLibraryDir;
File dexOutputDir = getDir("dex", 0);
DexClassLoader clsLoader = new DexClassLoader(apkPath, dexOutputDir.getAbsolutePath(),
null, this.getClass().getClassLoader());
try {
Class localClass = clsLoader
.loadClass("deep.loadactivity.MainActivity");
mActivityClass = localClass;
Constructor localConstructor = localClass.getConstructor(new Class[] {});
instance = localConstructor.newInstance(new Object[] {});
mActivityInstance = instance;
Method localMethodSetActivity = localClass.getDeclaredMethod(
"setActivity", new Class[] { Activity.class });
localMethodSetActivity.setAccessible(true);
localMethodSetActivity.invoke(instance, new Object[] { this });
Method methodonCreate = localClass.getDeclaredMethod("onCreate", new Class[] { Bundle.class });
methodonCreate.setAccessible(true);
Bundle paramBundle = new Bundle();
paramBundle.putBoolean("KEY_START_FROM_OTHER_ACTIVITY", true);
paramBundle.putString("str", "MainActivity");
methodonCreate.invoke(instance, new Object[] { paramBundle });
} catch (Exception e) {
e.printStackTrace();
}
}
下面主要说一下DexClassLoader：
DexClassLoader(String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parent)
dexPath:被解压的apk路径，不能为空。
optimizedDirectory：解压后的.dex文件的存储路径，不能为空。
libraryPath：库文件的的搜索路径，一般来说是 .so 库文件的路径，也可以指明多个路径。
parent：父亲加载器，一般为ClassLoader.getSystemClassLoader()。
说明
在上面的例子中我们其实是演示了一下动态加载Activity的方法，Activity被动态加载后，是没有生命周期的，只是当做一个类来做处理，由上面程序可以看出，我们是手动调用onCreate方法的。
当然，我们也可以写一些其他类或方法进行调用，不一定非要用Activity。
开源框架
说完了插件机制，我们也认识到了插件机制的一些不足，就比如刚才说的，Activity生命周期没有了，需要手动调用各个方法，那给我们的开发带来了很多不方便，但是网上的一些开源框架，解决了这些不方便，将调用的方法，顺序封装好，我们只管调用即可。
这些框架，我会在后面的文章中详细演示。
android-pluginmgr
利用DexMaker的动态热部署功能来实现Activity。
- 优点：
1.插件app不需要任何规则和限制
2.技术方法相对成熟稳定 - 缺点：
1.oom问题突出
2.只支持Activity，不支持其它组件。
dynamic-load-apk
这是基于代理的方式实现插件框架的，需要按照一定的规则来开发插件APK。
- 优点：
1.插件需要遵循一些规则，更加可控
2.方案简单 - 缺点：
1.不支持this调用组件中的方法，需要that，有些难理解
2.不支持隐式调用APK内部的Activity
3.兼容性问题较多
DynamicAPK
这是携程实现的一种多APK/DEX加载的插件框架。
- 优点：
1.很少修改即可实现改造
2.提升工程编译速度
3.可实现热更新
4.提高App的启动速度 - 缺点：
1.不支持so库
2.不支持aar，maven远程仓库的依赖
DroidPlugin
这是360实现的一种插件框架，他可以直接运行第三方独立得APK。完全不需要对APK进行修改或安装。
- 优点：
1.支持四大组件
2.支持所有系统API
3.插件与插件之间，插件与宿主之间的代码和资源完全隔离
4.实现了进程管理，占用内存低 - 缺点：
1.不支持自定义资源的Notification
2.不支持IntentFilter
3.缺乏对Native层的Hook操作
4.由于插件与插件，插件与宿主之间完全隔离，因此，如果需要通信，需要Android系统级别的通信方式。
Small
这是一个跨平台的插件化框架。
- 优点：
1.插件编码与资源文件的使用与普通开发无差别
2.通过设定URI，宿主可以方便地与插件间进行通信
3.支持Android IOS HTML5
*缺点：
不支持Service的动态注册。
总结
以上是我对插件调研的一个总结，在后面的演示中，我会将主流的插件化框架进行详细说明。
