导语 Android系统内部是在什么时候创建AssetManager,又是如何创建的? AssetManager与Resource什么关系? Android插件化为什么可以通过重写addAssetPath方法访问插件资源? 本文参考老罗的文章,并生成自己的见解,若有错误之处,恳请指正。 详见:http://blog.csdn.net/luoshengyang/article/details/8791064
1、AssetManager与Resources
Android中的资源可以分为两类:
-
第一类资源,不对应文件的,如string资源;
-
第二类资源,对应文件的,如layout资源。
-
第一类资源只需通过资源ID查找到资源名称即可,第二类资源需根据资源名称打开相应文件。 通过下面这副图片简单的分析下资源查找的过程:
![2.png](https://img.haomeiwen.com/i1986354/c116631c1d715cdd.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
如上图所示,Resources根据资源ID查找资源,AssetManager根据资源名称查找资源。若Resources查找资源时的资源ID对应的资源是文件,那先根据资源ID查找到资源文件名称(在resources.arsc中查找到),再通过AssetManager打开相应文件。 看下Resources与AssetManager的成员变量:
-
ContextImpl提供接口getResources可以获得指向当前APK资源的Resources对象。
-
Resouces类中的mAssets是AssetManager对象,用来访问程序的非编译文件(第二类资源);mSystem是Resources对象,用来访问系统资源包,系统资源包存在/system/framework/framework-res.apk。
-
AssetManager(Java)中的sSystem是AssetManager对象,用来打开系统资源包文件;mObject是一个int地址,保存了对应C++层的AssetManager对象地址。
-
AssetManager(C++)中的mAssetPaths是资源目录,mResources为资源表,mConfig保存了设备的本地配置信息。
2、Activity启动
调用startActivity启动指定Activity,最后会调用ApplicationThread的scheduleLaunchActivity方法。流程如下所示:
-
scheduleLaunchActivity方法通过H发送消息H.LAUNCH_ACTIVITY
-
H的消息处理中,调用ActivityThread的getPackageInfoNoCheck创建LoadedAPK对象,调用handleLaunchActivity启动Activity。
-
创建的LoadedAPK对象指定资源路径为当前APK。
-
handleLaunchActivity启动Activity,先调用makeApplication创建Application对象,并未Application关联ContextImpl(baseContext)。
-
再为启动的Activity关联ComtextImpl(baseContext)。 该过程如下图所示,其中AMS(ActivityManagerService)负责Activity声明周期和Activity堆栈的管理,而ApplicationThread是App进程与AMS通信的Binder。ApplicationThread通过H(是一个Handler)实现与主线程ActivityThread的通信,进而管理者Activity的声明周期。
在上过程中,首先会为创建的Application关联AppContext,即为Application关联ContextImpl;再为启动的Activity关联BaseContext,同样为ContextImpl。该过程都会调用ContextImpl的构造方法,实现ContextImpl的创建,并调用init方法实现Resources、AssetManager的创建,那接着看ContextImpl的init过程。
(插一句,Application继承ContextWrapper,ContextWrapper继承Context;Activity继承ContextThemeWrapper,ContextThemeWrapper继承ContextWrapper。Application与Activity的基类Context是抽象类,其具有成员变量mBaseContext,采用代理模式,真正的操作都有mBaseContext实现。而真正实现Context方法的类只有ContextImpl,因此在创建Activity或Application都需要为其关联一个ContextImpl对象)
3、ActivityManager创建
接着上一步的ContextImpl的创建,先看下时序图:
4.png该过程的主要实现了:
![6.png](https://img.haomeiwen.com/i1986354/13db298d833ef0d6.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
过程还是比较多的,挑几步好好看下。
3.1、第1步:init
该步中调用LoadeAPk的getResources(..)方法获得Resources对象,LoadedAPK在上面Activity启动流程中进行创建(LoadedAPK保存了当前APK信息)。
6.png3.2、第3步:getTopLevelResources
在第2步调用LoadedAPK的getResources方法中,它会调用ActivityThread的getTopLevelResources方法。该方法的主要内容有:
7.png
如上所示,该方法主要完成以下功能:
-
从Map缓存中取Resources对象,有直接返回,没有下一步。
-
创建AssetManager,并接着添加系统资源文件路径到资源目录(mAssetPaths)中。
-
添加访问的APK文件(当前APK文件)路径到资源目录(mAssetPaths)中。
-
创建Resources对象,并返回。
3.2、第7步:addAssetPath
在前面的分析中可知,通过调用addAssetPath方法将资源文件路径添加到资源目录中,实现资源的加载。该方法的主要内容有:
8.png由上可知,addAssetPath主要是将资源文件路径添加到资源目录mAssetPaths中,并且判断添加的apk文件是否位于/system/framework/下,如果是则会在/Vendor/overlay/frame/目录下查找是否有同名的apk文件,有的话则用该apk文件覆盖原有apk。(该机制一般用于厂商自定义资源覆盖系统资源)。
4、总结
由上分析可知,ContextImpl创建过程中,会调研getResources()获得Resources对象,而getResources最后调用getTopLevelResources方法。getTopLevelResources方法首先从缓存中拿Resources对象,没有拿到则先创建AssetManager对象,并通过AssetManager的addAssetPath实现系统资源文件、当前APK资源文件的加载,然后再创建Resources对象返回。
5、后记
在andorid插件化机制中,关于如何访问插件资源。现在的一般做法是通过反射拿到AssetManager的addAssetPath方法,将插件资源路径添加到资源目录mAssetPath中,然后在创建Resources对象。
而另外一种方案则来自于DroidPlugin机制,该插件化机制采用Hook思想,当启动插件Activity时,先替换启动的插件Activity为代理Activity,再在H的消息处理中替换回插件Activity。而在H的消息处理中替换回插件Activity时,首先通过插件Acitivity信息创建LoadedAPK对象(指定资源路径为插件路径),再调用LoadedAPK的makeApplication创建插件Application。而关于makeApplication调用上面已经讲过了,它会调用ContextImpl创建过程实现插件Resources的创建以及资源加载。
网友评论