导语 Android系统内部是在什么时候创建AssetManager，又是如何创建的？ AssetManager与Resource什么关系？ Android插件化为什么可以通过重写addAssetPath方法访问插件资源？ 本文参考老罗的文章，并生成自己的见解，若有错误之处，恳请指正。 详见：http://blog.csdn.net/luoshengyang/article/details/8791064
1、AssetManager与Resources
Android中的资源可以分为两类：
第一类资源，不对应文件的，如string资源；
第二类资源，对应文件的，如layout资源。
-
第一类资源只需通过资源ID查找到资源名称即可，第二类资源需根据资源名称打开相应文件。 通过下面这副图片简单的分析下资源查找的过程：
如上图所示，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的创建，先看下时序图：
该过程的主要实现了：
过程还是比较多的，挑几步好好看下。
3.1、第1步：init
该步中调用LoadeAPk的getResources(..)方法获得Resources对象，LoadedAPK在上面Activity启动流程中进行创建（LoadedAPK保存了当前APK信息）。
3.2、第3步：getTopLevelResources
在第2步调用LoadedAPK的getResources方法中，它会调用ActivityThread的getTopLevelResources方法。该方法的主要内容有：
如上所示，该方法主要完成以下功能：
从Map缓存中取Resources对象，有直接返回，没有下一步。
创建AssetManager，并接着添加系统资源文件路径到资源目录（mAssetPaths）中。
添加访问的APK文件（当前APK文件）路径到资源目录（mAssetPaths）中。
创建Resources对象，并返回。
3.2、第7步：addAssetPath
在前面的分析中可知，通过调用addAssetPath方法将资源文件路径添加到资源目录中，实现资源的加载。该方法的主要内容有：
由上可知，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的创建以及资源加载。
