转载&＃xff1a;http://blog.kymjs.com/cjframeforandroid/2014/10/15/01/

查看我的全部开源项目【开源实验室】 欢迎加入我的QQ群&＃xff1a;【201055521】&＃xff0c;本博客客户端下载【请点击】

如果你还不知道什么叫插件化开发&＃xff0c;那么你应该先读一读之前写的这篇博客&＃xff1a;Android插件化开发&＃xff0c;初入殿堂

上一篇博客主要从整体角度分析了一下Android插件化开发的几个难点与动态加载没有被安装的apk中的Activity和资源的方法。其实一般的插件开发主要也就是加载个Activity&＃xff0c;读取一些资源图片之类的。但是总有遇到特殊情况的时候&＃xff0c;比如加载Service。

要动态加载Service&＃xff0c;有两种思路&＃xff1a;一是通过NDK的形式&＃xff0c;将Service通过C&＃43;&＃43;运行起来&＃xff08;这种方法我没有尝试&＃xff0c;只听群里的朋友说实现过&＃xff09;&＃xff1b;另一种就是我使用的&＃xff0c;具体思路和上一篇中提到加载Activity的方法一样&＃xff0c;使用托管所的形式&＃xff0c;由于上一篇博客没有讲清楚&＃xff0c;这里就详细讲一下通过托管所实现加载插件中Service的方法。

以下几点是每一个Android开发组肯定都知到的&＃xff1a; 一个apk如果没有被安装的话是没有办法直接运行的。一个JAVA类的class文件是可以通过classload类加载器读取的。一个apk实际上就是一个压缩包&＃xff0c;其中包含了一个.dex文件就是我们的代码文件。那么&＃xff0c;接下来基本思路我们就可以明确了&＃xff1a;apk没办法直接运行&＃xff0c;apk中有代码文件&＃xff0c;代码文件可以被classload读取。

在Android中有两种classload&＃xff0c;分别是DexClassLoader、PathClassLoader。后者只能加载/data/app目录下的apk也就是apk必须要安装才能被加载&＃xff0c;这不是我们想要的&＃xff0c;所以我们使用前者&＃xff1a;DexClassLoader。

public class CJClassLoader extends DexClassLoader {//创建一个插件加载器集合&＃xff0c;对固定的dex使用固定的加载器可以防止多个加载器同时加载一个dex造成的错误。private static final HashMapString, CJClassLoader> pluginLoader &＃61; new HashMapString, CJClassLoader>();protected CJClassLoader(String dexPath, String optimizedDirectory,String libraryPath, ClassLoader parent) {super(dexPath, optimizedDirectory, libraryPath, parent);}/*** 返回dexPath对应的加载器*/public static CJClassLoader getClassLoader(String dexPath, Context cxt,ClassLoader parent) {CJClassLoader cjLoader &＃61; pluginLoader.get(dexPath);if (cjLoader &＃61;&＃61; null) {// 获取到app的启动路径final String dexOutputPath &＃61; cxt.getDir("dex", Context.MODE_PRIVATE).getAbsolutePath();cjLoader &＃61; new CJClassLoader(dexPath, dexOutputPath, null, parent);pluginLoader.put(dexPath, cjLoader);}return cjLoader;}}

以上只是一个开始&＃xff0c;接着我们需要考虑一个问题&＃xff0c;一个Service是有oncreate->onstart->ondestroy生命周期以及一些回调方法的&＃xff0c;这些回调方法在我们正常使用的时候是由父类们&＃xff08;包括has...a...关系&＃xff09;或者说是SDK管理的&＃xff0c;那么当我们通过类加载器加载的时候&＃xff0c;它是没有能够管理的父类的&＃xff0c;也就是说我们需要自己模拟SDK去管理插件Service的回调函数。那么这个去管理插件Service的类&＃xff0c;就是之前提到的托管所。

这里是我将Service中的回调方法抽出来写成的一个接口

public interface I_CJService {IBinder onBind(Intent intent);void onCreate();int onStartCommand(Intent intent, int flags, int startId);void onDestroy();void onConfigurationChanged(Configuration newConfig);void onLowMemory();void onTrimMemory(int level);boolean onUnbind(Intent intent);void onRebind(Intent intent);void onTaskRemoved(Intent rootIntent);}

.

//一个托管所类class CJProxyService extends Service&＃xff5b;//采用包含关系protected I_CJService mPluginService; // 插件Service对象&＃xff5d;

这里采用包含关系而不是采用继承&＃xff08;或者说实现一个接口&＃xff09;的方式&＃xff0c;是由于我们需要重写Service中的方法&＃xff0c;而这些被重写的方法都需要用到接口对象相应的接口方法。

public class CJProxyService extends Service&＃xff5b; &＃64;Overridepublic void onConfigurationChanged(Configuration newConfig) {mPluginService.onConfigurationChanged(newConfig);super.onConfigurationChanged(newConfig);}&＃64;Overridepublic void onLowMemory() {mPluginService.onLowMemory();super.onLowMemory();}&＃64;Override&＃64;SuppressLint("NewApi")public void onTrimMemory(int level) {mPluginService.onTrimMemory(level);super.onTrimMemory(level);}&＃64;Overridepublic boolean onUnbind(Intent intent) {mPluginService.onUnbind(intent);return super.onUnbind(intent);}&＃64;Overridepublic void onRebind(Intent intent) {mPluginService.onRebind(intent);super.onRebind(intent);}&＃xff5d;

看到这里大家应该也就明白了&＃xff0c;托管所实际上就是一个普通的Service类&＃xff0c;但是这个托管所是正常运行的&＃xff0c;是由SDK管理回调函数的&＃xff0c;我们通过这个Service的回调函数去调用插件Service中相应的回调方法&＃xff0c;就间接的管理了插件Service的生命周期&＃xff08;此处可以类比Activity与Fragment的关系&＃xff09;

到这里为止&＃xff0c;我们已经可以成功调起一个插件Service了&＃xff0c;接下来的问题就是这个I_CJSrvice对象从哪里来&＃xff1f;很简单&＃xff0c;通过类加载器加载一个

private void init(Intent itFromApp) {Object instance &＃61; null;try {Class> serviceClass;if (CJConfig.DEF_STR.equals(mDexPath)) {serviceClass &＃61; super.getClassLoader().loadClass(mClass);} else {serviceClass &＃61; this.getClassLoader().loadClass(mClass);}Constructor> serviceConstructor &＃61; serviceClass.getConstructor(new Class[] {});instance &＃61; serviceConstructor.newInstance(new Object[] {});} catch (Exception e) {}setRemoteService(instance);mPluginService.setProxy(this, mDexPath);}/*** 保留一份插件Service对象*/protected void setRemoteService(Object service) {if (service instanceof I_CJService) {mPluginService &＃61; (I_CJService) service;} else {throw new ClassCastException("plugin service must implements I_CJService");}}

这样就可以拿到一个I_CJSrvice对象mPluginService了&＃xff0c;如果到此为止&＃xff0c;还是会有问题&＃xff0c;因为此时mPluginService中例如onStart方法还对应的是那个插件中的onStart也就是父类的onStart&＃xff08;这里比较绕&＃xff0c;我不知道该如何描述&＃xff09;&＃xff0c;而之前我们又说过&＃xff0c;通过反射加载的类是没有父类的&＃xff0c;那么如果此时强制调用那个反射对象的&＃64;Override方法是会报空指针的&＃xff0c;因为找不到父类。那么解决的办法就是再去插件Service中重写每个&＃64;Override的方法。

//.......篇幅有限&＃xff0c;部分截取public abstract class CJService extends Service implements I_CJService {/*** that指针指向的是当前插件的Context&＃xff08;由于是插件化开发&＃xff0c;this指针绝对不能使用&＃xff09;*/protected Service that; // 替代this指针&＃64;Overridepublic IBinder onBind(Intent intent) {if (mFrom &＃61;&＃61; CJConfig.FROM_PLUGIN) {return null;} else {return that.onBind(intent);}}}

通过代可以看到&＃xff1a;我们使用了一个that对象来替代原本的this对象&＃xff0c;然后我们只需要通过在托管所中将这个that对象赋值为托管所的this对象&＃xff0c;也就是插件中的所有that.xxx都相当于调用的是托管所的this.xxx&＃xff0c;那么动态替换的目的就达到了&＃xff0c;这样我们也就成功的加载了一个未被安装的插件apk中的Service。

有关本类中的代码&＃xff0c;以及完整的Demo&＃xff0c;你可以关注&＃xff1a;Android插件式开发框架 CJFrameForAndroid

但是apk中包含有.so文件时候就很难启动。