欢迎大家来到IT世界,在知识的湖畔探索吧!
1.背景
最近一直在做优化相关事情,需要在启动时干预加载dex文件的过程,而AndroidManifest设定的Application类已经在dex文件中,在加载dex之前,不能找到这个Application类。所以我们需要替换原有的Application为ProxyApplication。使其应用启动时加载ProxyApplication,我们在其中实现加载dex等一些流程处理。而后要替换回原有的Application(以下为RealApplication),确保应用正常运行,并且要保持生命周期、初始化顺序不变,屏蔽对于应用中getContext,getApplicationContext的影响。
2.需要处理的问题
在我们替换ProxyApplication之后,在初始化时创建RealApplication,还需要满意以下几个条件:
创建RealApplication,维护正常的生命周期,并进行回调。
对应用中屏蔽掉ProxyApplication,对于下层无感知。在Activity等调用getApplicationContext之后,应该返回RealApplication。
ContentProvider创建时机比较特殊,在满足正常的初始化顺序之后,也要屏蔽ProxyApplication的存在。
3.方案具体实现
在AndroidManifest.xml文件中替换Application为ProxyApplication,可以使用自动化方式,或者打包方式,细节过程这里不做讨论。这里主要叙述创建RealApplication的过程。替换了ProxyApplication之后,对于系统而言ProxyApplication就是应用初始化的入口,所有的回调均是在ProxyApplication中发生。我们主要关注attachBaseContext和onCreate的回调。
3.1.创建RealApplication
创建RealApplication,我们可以使用反射的方式newInstance创建对象,然后执行回调attachBaseContext。但是对于不同的系统版本,内部执行的细节可能不同,或者有其它相关逻辑的处理,所以我们采用另一种方式进行处理。首先看系统源码的如何实现,这里选择8.0.0的系统源码进行分析,其它版本去http://androidxref.com/查看。
我们知道,Java层初始化可以认为是从android.app.ActivityThread开始,所以从ActivityThread开始查看。ActivityThread中存在静态方法currentActivityThread返回实例。
ActivityThread内部存在成员变量AppBindData mBoundApplication。AppBindData是一个静态内部类,其中包含成员变量LoadedApk info。查看android.app.LoadedApk源代码,发现创建Application的makeApplication方法。
上面去掉不相关代码之后,可以明显看出:
如果缓存mApplication不为空,则直接返回。
mApplication为空时,则创建RealApplication,并且执行相关的回调。创建RealApplication时,类名是从mApplicationInfo.className中获取。
添加新创建RealApplication到mActivityThread.mAllApplications。
赋值给缓存mApplication。
所以我们在调用makeApplication之前,需要将mApplication置为null,否则会直接返回ProxyApplication的实例。
首先,通过android.app.ActivityThread中静态方法获取实例
然后,通过ActivityThread实例,获得LoadedApk实例。为了使makeApplication顺利执行,先设置mApplication为null。移除mAllApplications中ProxyApplication的实例。LoadedApk中mApplicationInfo和AppBindData中appInfo都是ApplicationInfo类型,需要分别替换className字段的值为RealApplication的实际类全名。
之后,反射调用系统的makeApplication
最终,使用上面三个方法组合起来,完成我们的逻辑。
这样,在ProxyApplication.attachBaseContext中,调用makeApplication创建RealApplication,并且内部已经完成对于RealApplication的attchBaseContext的回调。在ProxyApplication.onCreate中只需要回调RealApplication实例的onCreate,即可完成对于RealApplication的创建,已经内部替换以及正常的生命周期的回调。而且在Activity中调用getApplicationContext返回的值,实际上也是LoadedApk中mApplication的值,同时也保证对于Activity等地方屏蔽ProxyApplication的目的。
3.2.ContentProvider中getContext问题
通过阅读系统的源代码(或者自己打log),可以很容易的知道,Application和ContentProvider的初始化顺序是:Application.attachBaseContext -> ContentProvider.onCreate -> Application.onCreate
在保持正常Application生命周期的情况下,也要保持对ContentProvider中无感知。因为ContentProvider中也存在getContext方法,看ContentProvider的源代码实现:
其中mContext被赋值的有两个地方,一个在构造方法,一个是attchInfo的时候。继续追踪源代码中使用构造方法初始化,或者调用attachInfo的地方,结果在android.app.ActivityThread中找到installProvider方法中存在着调用关系。
以上源代码中,省略了不相关的部分代码。可以看出,使用反射调用ContentProvider无参构造方法创建实例,然后调用了attachInfo,传递的Context为installProvider方法中的参数。那这个参数哪传递过来的呢?带着疑问从源码中继续追踪调用关系,发现installContentProviders内部在初始化每个ContentProvider时,分别调用了一次installProvider。看installContentProviders的主要逻辑:
可以明确,installContentProviders中调用installProvider时传递的Context,也是由方法调用时传递的参数。继续向上追踪发现ActivityThread.handleBindApplication在初始化ContentProvider时调用了installContentProviders,看源代码中关键部分。
通过这部分的源代码,我们明确知道,最终通过attachInfo设置给ContentProvider中的Context的实际类型是Application。其中返回Application这行语句中,data的类型是AppBindData,info的类型是LoadedApk,所以makeApplication的具体实现就是章节3.1中列举的源代码。
在App初始化时,系统调用makeApplication创建了ProxyApplication实例,同时回调了attachBaseContext(Context context)。所以这个方法返回的就是App初始化时ProxyApplication,调用发生ProxyApplication.attachBaseContext之后,ProxyApplication.onCreate之前。所以我们没有办法在这两个方法生命周期内进行替换为RealApplication。
如果在attachBaseContext中设置mInitialApplication的值,在初始化ContentProvider之前,又被重新设置为ProxyApplication。这样在初始化ContentProvider时传递的Context依然是ProxyApplication,在ContentProvider的onCreate调用getContext返回的依然不是RealApplication,这种情况也是不能满足对下层无感知的需求。
如果在onCreate中设置mInitialApplication,也是不能起作用的,因为此时已经完成了ContentProvider的初始化过程。
仔细阅读源代码,发现初始化ContentProvider是有一系列条件控制,那么我们可以提前修改data.providers为null,让系统不执行ContentProvider的初始化。我们在ProxyApplication.attachBaseContext主动调用installContentProviders,传递RealApplication给ContentProvider。在ProxyApplication.onCreate中恢复data.providers的数据,减小对其它逻辑可能带来的影响。具体的实现分两部分,在attachBaseContext中调用我们实现的installContentProviders,源代码如下:
在onCreate中调用的restoreProviderInfo,恢复AppBindData中的List<ProviderInfo> providers原来的值,具体源代码如下:
4. 总结
以上大致讲解了从源代码的实现进行分析,了解系统基本的实现原理之后,进行相关的反射修改内部的值,达到我们替换Application的目的。这种方案,接入成本比较低,但是新系统出现之后,可能出现兼容性的问题,需要每次发布新系统之后进行相关的适配。但是这种解决问题的思路,可以借鉴一下,从别的地方进行Java Hook,实现一些黑科技的东西。而且替换Application这个方式,不只是可以应用在安装速度优化上面,同时也可以应用在其他一些场景上。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://itzsg.com/30406.html