Android的Proxy/Delegate Application框架

转载:http://blogs.360.cn/blog/proxydelegate-application/

有的时候,为了实现一些特殊需求,如界面换肤、插件化等,我们希望改变应用的运行环境(surrounding)。例如,我们希望某个应用在运行时,所有Class(包括自定义Application,下面假设它叫MyApplication)都被一个自定义的ClassLoader加载。

要实现这个需求,需要在MyApplication被加载之前,先替换掉API层的默认ClassLoader,否则MyApplication就会被默认ClassLoader加载。但这会产生一个悖论,MyApplication被加载之前,没有任何应用代码可以运行,替换ClassLoader无法办到。Proxy/Delegate Application框架就是用来解决这类问题的。

Proxy/Delegate Application简介

在Proxy/Delegate Application框架里,应用一共有两个Application对象,一个称为ProxyApplication,另一个称为DelegateApplication:

(1) ProxyApplication:框架会提供一个ProxyApplication抽象基类(abstract class),使用者需要继承这个类,并重载其initProxyApplication()方法,在其中改变surrounding,如替换ClassLoader等。

(2) DelegateApplication:即应用原有的Application,应用从getApplicationContext()等方法中取到的都是DelegateApplication。注意DelegateApplication只是一个称谓,并没有一个叫DelegateApplication的基类存在。

使用Proxy/Delegate Application框架,使用者可以在对原有Application类不做任何修改的情况下,改变整个应用的运行环境。所需要做的只是添加一个新的Application类,并相应的修改AndroidManifest.xml。

老的AndroidManifest.xml:

1 <application
2 android:name=".MyApplication"
3 android:icon="@drawable/icon"
4 android:label="@string/app_name" >

添加的Application类:

1 public class MyProxyApplication extends ProxyApplication {
2     @Override
3     protected void initProxyApplication() {
4         // 在这里替换运行环境,如将ClassLoader替换为自定义的
5         // ......
6     }
7 }

新的AndroidManifest.xml:

1 <application
2 android:name=".MyProxyApplication"
3 android:icon="@drawable/icon"
4 android:label="@string/app_name" >
5     <meta-data
6     android:name="DELEGATE_APPLICATION_CLASS_NAME"
7     android:value=".MyApplication" >
8     </meta-data>

MyProxyApplication(ProxyApplication)对象对应用是不可见的,应用看到的Application是MyApplication(DelegateApplication),也就是以前的Application对象。这样对于应用而已,似乎一切都没有改变;但它的运行环境已经改变,例如所有的类已经被新的ClassLoader加载了。整个实现是非侵入式的,已有代码无须任何修改,只有AndroidManifest.xml略有改动。


下面开始探讨ProxyApplication本身如何实现。核心问题是两个,一是什么时机调用子类的initProxyApplication()方法,让子类改变surrounding;二是如何加载DelegateApplication并让应用认为它就是真实的Application。另外Android四大组件之一的ContentProvider会给我们带来不少麻烦,需要妥善处理。

ProxyApplication实现:时机

理论上ProxyApplication对任何能够访问到的变量,包括Java层和Native层,都是可以替换(或者HOOK,类似的含义)的;比较有意义的除了ClassLoader外,还有Resources和各路Binder对象。通过这些手段可以实现非常多有意思的功能。具体如何替换ClassLoader、Resources等这里不深入讨论,如有兴趣,在网上可以找到很多相关资料。本文的重点是介绍框架本身,替换ClassLoader仅作为一个例子。

现在的问题是改变surrounding的时机必须足够早,特别是对于ClassLoader来说尤为重要。是否可以在Application:onCreate()里做?我们通常认为,Application是一个Android应用最早被加载的组件;但当应用注册有ContentProvider的时候,这并不正确的。ContentProvider:onCreate()调用优先于Application:onCreate()。

幸好,我们还有另一个方法:attachBaseContext()。Android的几个主要顶级组件(Application、Activity、Service)都是ContextWrapper的子类。ContextWrapper一方面继承(inherit)了Context,一方面又包含(composite)了一个Context对象(称为mBase),对Context的实现为转发给mBase对象处理。这一个听起来很绕的设计,是为了对这些顶级组件中的Context功能做延迟初始化(delay init)的处理。这里不展开讨论了,仅贴一些Android源代码片段做参考。

01 // android.app.Application
02 public class Application extends ContextWrapper {
03     // ...
04     public application() {
05         super(null);
06     }
07     // ...
08 }
09 // android.content.ContextWrapper
10 public class ContextWrapper extends Context {
11     Context mBase;
12     // ...
13     public ContextWrapper(Context base) {
14         mBase = base;
15     }
16     protected void attachBaseContext(Context base) {
17         if (mBase != null) {
18             throw new IllegalStateException("Base context already set");
19         }
20         mBase = base;
21     }
22     // ...
23     @Override
24     public AssetManager getAssets() {
25         return mBase.getAssets();
26     }
27     @Override
28     public Resources getResources()
29     {
30         return mBase.getResources();
31     }
32     // ...
33 }

ContextWrapper完成这个delay init语义的方法就是attachBaseContext()。可以这样说,Application对象在刚刚构造完成时是“残废”的,访问所有Context的方法都会抛出NullPointerException。只有attachBaseContext()执行完后,它的功能才完整。

在ContentProvider:onCreate()中,我们知道Application:onCreate()还没有运行,但已经可以使用getContext().getApplicationContext()函数获取Application对象,并访问其Context方法。显然,Android的API设计者不能允许此时获取的Application是“残废”的。结论是Application:attachBaseContext()必须要发生在ContentProvider:onCreate()之前,否则API将出现BUG;无论Android的系统版本如何变化,这一点也不能改变。

于是,Application与ContentProvider的初始化次序是这样的:Application:attachBaseContext()最早执行,然后是ContentProvider:onCreate(),然后是Application:onCreate()。我们的解决方案也就很简单了:

1 public abstract class ProxyApplication extends Application {
2     protected abstract void initProxyApplication();
3     @Override
4     protected void attachBaseContext (Context context) {
5         super.attachBaseContext(context); 
6         initProxyApplication();
7     }
8     // ……
9 }

ProxyApplication实现:加载DelegateApplication

当子类的initProxyApplication()返回后,ProxyApplication就要加载DelegateApplication,完成自己的历史使命。这一部分在onCreate()中完成,基本是些体力活,但也有些需要注意的地方,下面分步骤简述一下。

(1) 获取DelegateApplication的Class Name

即从AndroidManifest.xml中获取DELEGATE_APPLICAION的metadata值,若不存在,则使用android.app.Application作为默认。这一步比较简单。

01 String className = "android.app.Application";
02 String key = "DELEGATE_APPLICATION_CLASS_NAME";
03 ApplicationInfo appInfo = getPackageManager().getApplicationInfo(
04     super.getPackageName(), PackageManager.GET_META_DATA);
05 Bundle bundle = appInfo.metaData;
06 if (bundle != null && bundle.containsKey(key)) {
07     className = bundle.getString(key);
08     if (className.startsWith("."))
09         className = super.getPackageName() + className;
10 }

(2) 加载DelegateApplication并生成对象

这里要注意的是使用哪个ClassLoader?答案是应该用getClassLoader()(即Context:getClassLoader()),而不是getClass().getClassLoader()。要仔细揣摩这两者之间的差别。

1 Class delegateClass = Class.forName(className, true, getClassLoader());
2 Application delegate = (Application) delegateClass.newInstance();

 (3) 替换API层的所有Application引用

即把API层所有保存的ProxyApplication对象,都替换为新生成的DelegateApplication对象。以ProxyApplication的baseContext作为起点顺藤摸瓜,可以找到所有的位置,使用反射一一换掉。注意最后一个mAllApplications是List,要换掉其内部的内容。

1 baseContext.mOuterContext
2 baseContext.mPackageInfo.mApplication
3 baseContext.mPackageInfo.mActivityThread.mInitialApplication
4 baseContext.mPackageInfo.mActivityThread.mAllApplications

 (4) 设置baseContext并调用onCreate

将控制权交给DelegateApplication。当然,后者会认为自己就是“正牌”的Application,后续的其它组件也都会这么认为。这正是我们要的效果。

1 Method attach = Application.class.getDeclaredMethod("attach", Context.class);
2 attach.setAccessible(true);
3 attach.invoke(delegate, base);
4 delegate.onCreate();

再次对付ContentProvider

前面提到过,Android的顶级组件Application、Activity、Service都是ContextWrapper,这个列表中并没有ContentProvider。ContentProvider不是ContextWrapper,甚至不是Context,而是内部有一个mContext变量,通过getContext()函数获取这个Context。

那么,ContentProvider:getContext()获取到的是哪一个Context?实验证明,ContentProvider:getContext()获取的Context是Application;准确的说,在Proxy/Delegate Application框架里,是ProxyApplication。这就不符合框架的语义了。那么,我们需要像其它处理其它ProxyApplication引用一样,把它换成DelegateApplication吗?这是可行的:遍历API层的ContentProvider列表,将每一个ContentProvider中的mContext都替换为DelegateApplication。

但这种处理方式,会进一步增加对Android API层源代码依赖,是否必要?毕竟Android的API文档中,并没有规定ContentProvider:getContext()返回的必须是Application;如果要取得Application,正确的方式是getContext().getApplicationContext()。那么为什么getContext()就直接返回了Application对象?我们可以从源代码中找到答案:

01 // in ActivityThread:installProvider()
02 if (context.getPackageName().equals(ai.packageName)) {
03     c = context;
04 else if (mInitialApplication != null &&
05         mInitialApplication.getPackageName().equals(ai.packageName)) {
06     c = mInitialApplication;
07 else {
08     try {
09         c = context.createPackageContext(ai.packageName,
10                 Context.CONTEXT_INCLUDE_CODE);
11     catch (PackageManager.NameNotFoundException e) {
12         // Ignore
13     }
14 }

容易看出,因为ProxyApplication对象的getPackageName()函数与ContentProvider对应的包名相同,就会复用ProxyApplication对象作为Context,而不会再创建一个新的packageContext。于是解决方案也很简单了:

1 @Override
2 public String getPackageName() {
3     return "";
4 }

由于ProxyApplication不是最终的Application,这并不会产生什么副作用。


使用注意事项

不要保留ProxyApplication子类对象的引用,也不要在任何系统回调(包括onCreate)中做事情。onCreate()被基类用于加载DelegateApplication,而其它回调都不会再收到。

在ProxyApplication:onCreate()执行完成之后,虚拟机中所有的线程栈和所有的JAVA对象,都不会再有ProxyApplication对象的引用。ProxyApplication对象将在下一次GC运行时被回收,这也意味着从ProxyApplication到DelegateApplication的替换进行得非常彻底。自然地,ProxyApplication也收不到其它回调了。DelegateApplication会正常的接收所有的回调。

另外,在ProxyApplication子类中,如果需要获取当前APK的包名,需要使用getBaseContext().getPackageName(),而不能简单调用getPackageName()。原因在上面“再次对付ContentProvider”中有说明。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值