@dodola 2017-07-15 17:45 字数 10172 阅读 230
VirtualAPK分析[资源篇]
Android 插件化[资源处理篇]
一. 概述
VitrualAPK 是滴滴开源的一款插件化框架
VirtualAPK 地址:github.com/didi/Virtua…
前两天鸿洋分析了插件的四大组件启动流程,这里针对一些具体的点分析一下。 整体会分为如下几个方面分析:
- 资源篇
- Context+ClassLoader 相关
- 四大组件相关
- 插件打包脚本分析
本篇先从资源下手分析,VirtualAPK的插件资源加载分为两种方式:
一种是插件存在一份独立的 Resources 自己使用,一种是COMBINE_RESOURCES模式,将插件的资源全部添加到宿主的Resource里
首先我们要先看一下系统是如何加载资源的。
Android 资源加载
此处简单探讨一下Android系统里资源加载查找的过程,这是插件加载资源的理论基础。
Resources对象的生成
从下向上一直可以追溯到生成Resources对象的地方
class ContextImpl extends Context {//...private ContextImpl(ContextImpl container, ActivityThread mainThread,LoadedApk packageInfo, IBinder activityToken, UserHandle user, boolean restricted,Display display, Configuration overrideConfiguration) {//....Resources resources = packageInfo.getResources(mainThread);//....}//...}
这里不去关注packageInfo是如何生成的,直接跟踪到下面去.
public final class LoadedApk {private final String mResDir;public LoadedApk(ActivityThread activityThread, ApplicationInfo aInfo,CompatibilityInfo compatInfo, ClassLoader baseLoader,boolean securityViolation, boolean includeCode, boolean registerPackage) {final int myUid = Process.myUid();aInfo = adjustNativeLibraryPaths(aInfo);mActivityThread = activityThread;mApplicationInfo = aInfo;mPackageName = aInfo.packageName;mAppDir = aInfo.sourceDir;mResDir = aInfo.uid == myUid ? aInfo.sourceDir : aInfo.publicSourceDir;// 注意一下这个sourceDir,这个是我们宿主的APK包在手机中的路径,宿主的资源通过此地址加载。// 该值的生成涉及到PMS,暂时不进行分析。// Full path to the base APK for this application.//....}//....public Resources getResources(ActivityThread mainThread) {if (mResources == null) {mResources = mainThread.getTopLevelResources(mResDir, mSplitResDirs, mOverlayDirs,mApplicationInfo.sharedLibraryFiles, Display.DEFAULT_DISPLAY, null, this);}return mResources;}//....}
进入到ActivityThread.getTopLevelResources()的逻辑中
public final class ActivityThread {Resources getTopLevelResources(String resDir, CompatibilityInfo compInfo) {//我们暂时只关注下面这一段代码AssetManager assets = new AssetManager();if (assets.addAssetPath(resDir) == 0) { //此处将上面的mResDir,也就是宿主的APK在手机中的路径当做资源包添加到AssetManager里,则Resources对象可以通过AssetManager查找资源,此处见(老罗博客:Android应用程序资源的查找过程分析)return null;}// 创建Resources对象,此处依赖AssetManager类来实现资源查找功能。r = new Resources(assets, metrics, getConfiguration(), compInfo);}}
从上面的代码中我们知道了我们常用的Resources是如何生成的了,那么理论上插件也就按照如此方式生成一个Resources对象给自己用就可以了。从VirtualAPK的代码里看一下对资源的处理
VirtualAPK 资源加载
在VirtualAPK里插件所有相关的内容都被封装到LoadedPlugin里,插件的加载行为一般都在这个类的构造方法的实现里,我们这里只关注与资源相关部分的代码
LoadedPlugin(PluginManager pluginManager, Context context, File apk) throws PackageParser.PackageParserException {//需要注意context是宿主的Context//apk 指的是插件的路径this.mResources = createResources(context, apk);this.mAssets = this.mResources.getAssets();}private static AssetManager createAssetManager(Context context, File apk) {try {//这里参照系统的方式生成AssetManager,并通过反射将插件的apk路径添加到AssetManager里//这里只适用于资源独立的情况,如果需要调用宿主资源,则需要插入到宿主的AssetManager里AssetManager am = AssetManager.class.newInstance();ReflectUtil.invoke(AssetManager.class, am, "addAssetPath", apk.getAbsolutePath());return am;} catch (Exception e) {e.printStackTrace();return null;}}@WorkerThreadprivate static Resources createResources(Context context, File apk) {if (Constants.COMBINE_RESOURCES) {//如果插件资源合并到宿主里面去的情况,插件可以访问宿主的资源Resources resources = new ResourcesManager().createResources(context, apk.getAbsolutePath());ResourcesManager.hookResources(context, resources);return resources;} else {//插件使用独立的Resources,不与宿主有关系,无法访问到宿主的资源Resources hostResources = context.getResources();AssetManager assetManager = createAssetManager(context, apk);return new Resources(assetManager, hostResources.getDisplayMetrics(), hostResources.getConfiguration());}}
如果将宿主和插件隔离,我们只需要生成一个独立的Resources对象给插件使用,如果要调用宿主资源则需要将宿主的APK和插件的APK一起添加到同一个AssetManager里。进入到ResourcesManager的逻辑里
public static synchronized Resources createResources(Context hostContext, String apk) {// hostContext 为宿主的ContextResources hostResources = hostContext.getResources();//获取到宿主的Resources对象Resources newResources = null;AssetManager assetManager;try {//-----begin---//这块的代码涉及到的内容比较多,详情见①if (Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP) {assetManager = AssetManager.class.newInstance();ReflectUtil.invoke(AssetManager.class, assetManager, "addAssetPath", hostContext.getApplicationInfo().sourceDir);} else {assetManager = hostResources.getAssets();}//------end----//------begin---ReflectUtil.invoke(AssetManager.class, assetManager, "addAssetPath", apk);List<LoadedPlugin> pluginList = PluginManager.getInstance(hostContext).getAllLoadedPlugins();for (LoadedPlugin plugin : pluginList) {ReflectUtil.invoke(AssetManager.class, assetManager, "addAssetPath", plugin.getLocation());}//------end----//-----begin-----//此处针对机型的兼容代码是可以避开的,详情见③if (isMiUi(hostResources)) {newResources = MiUiResourcesCompat.createResources(hostResources, assetManager);} else if (isVivo(hostResources)) {newResources = VivoResourcesCompat.createResources(hostContext, hostResources, assetManager);} else if (isNubia(hostResources)) {newResources = NubiaResourcesCompat.createResources(hostResources, assetManager);} else if (isNotRawResources(hostResources)) {newResources = AdaptationResourcesCompat.createResources(hostResources, assetManager);} else {// is raw android resourcesnewResources = new Resources(assetManager, hostResources.getDisplayMetrics(), hostResources.getConfiguration());}//-----end-----} catch (Exception e) {e.printStackTrace();}return newResources;}public static void hookResources(Context base, Resources resources) {if (Build.VERSION.SDK_INT >= 24) {return;}try {ReflectUtil.setField(base.getClass(), base, "mResources", resources);Object loadedApk = ReflectUtil.getPackageInfo(base);ReflectUtil.setField(loadedApk.getClass(), loadedApk, "mResources", resources);Object activityThread = ReflectUtil.getActivityThread(base);Object resManager = ReflectUtil.getField(activityThread.getClass(), activityThread, "mResourcesManager");Map<Object, WeakReference<Resources>> map = (Map<Object, WeakReference<Resources>>) ReflectUtil.getField(resManager.getClass(), resManager, "mActiveResources");Object key = map.keySet().iterator().next();map.put(key, new WeakReference<>(resources));} catch (Exception e) {e.printStackTrace();}}
①:此处针对系统版本的区分涉及到资源加载时候的兼容性问题
由于资源做过分区,则在AndroidL后直接将插件包的apk地址addAssetPath之后就可以,但是在Android L之前,addAssetPath只是把补丁包加入到资源路径列表里,但是资源的解析其实是在很早的时候就已经执行完了,问题出现在这部分代码:
AssetManager.cpp
const ResTable* AssetManager::getResTable(bool required) const{ResTable* rt = mResources;if (rt) {return rt;}//....const size_t N = mAssetPaths.size();for (size_t i=0; i<N; i++) {Asset* ass = NULL;ResTable* sharedRes = NULL;bool shared = true;const asset_path& ap = mAssetPaths.itemAt(i);MY_TRACE_BEGIN(ap.path.string());Asset* idmap = openIdmapLocked(ap);ALOGV("Looking for resource asset in '%s'\n", ap.path.string());if (ap.type != kFileTypeDirectory) {if (i == 0) {// The first item is typically the framework resources,// which we want to avoid parsing every time.sharedRes = const_cast<AssetManager*>(this)->mZipSet.getZipResourceTable(ap.path);}if (sharedRes == NULL) {ass = const_cast<AssetManager*>(this)->mZipSet.getZipResourceTableAsset(ap.path);if (ass == NULL) {ALOGV("loading resource table %s\n", ap.path.string());ass = const_cast<AssetManager*>(this)->openNonAssetInPathLocked("resources.arsc",Asset::ACCESS_BUFFER,ap);if (ass != NULL && ass != kExcludedAsset) {ass = const_cast<AssetManager*>(this)->mZipSet.setZipResourceTableAsset(ap.path, ass);}}if (i == 0 && ass != NULL) {// If this is the first resource table in the asset// manager, then we are going to cache it so that we// can quickly copy it out for others.ALOGV("Creating shared resources for %s", ap.path.string());sharedRes = new ResTable();sharedRes->add(ass, (void*)(i+1), false, idmap);sharedRes = const_cast<AssetManager*>(this)->mZipSet.setZipResourceTable(ap.path, sharedRes);}}} else {ALOGV("loading resource table %s\n", ap.path.string());Asset* ass = const_cast<AssetManager*>(this)->openNonAssetInPathLocked("resources.arsc",Asset::ACCESS_BUFFER,ap);shared = false;}}
mResources指向的是一个ResTable对象,如果它的值不等于NULL,那么就说明当前应用程序已经解析过它使用的资源包里面的resources.arsc文件,因此,这时候AssetManager类的成员函数getResources就可以直接将该ResTable对象返回给调用者。如果还没有初始化 mResources则按照一定步骤遍历当前应用所使用的每个资源包进而生成 mResources
具体的初始化过程见
老罗的博客
由于有系统资源的存在,mResources 的初始化在很早就初始化了,所以我们就算通过addAssetPath方法将 apk 添加到mAssetPaths里,在查找资源的时候也不会找到这部分的资源,因为在旧的 mResources 里没有这部分的 id。
所以在 Android L 之前是需要想办法构造一个新的AssetManager里的 mResources 才行,这里有两种方案,VirtualAPK 用的是类似 InstantRun 的那种方案,构造一个新的 AssetManager,将宿主和加载过的插件的所有 apk 全都添加一遍,然后再调用 hookResources方法将新的 Resources 替换回原来的,这样会引起两个问题,一个是每次加载新的插件都会重新构造一个
AssetManger 和 Resources,然后重新添加所有资源,这样涉及到很多机型的兼容(因为部分厂商自己修改了 Resources 的类名),一个是需要有一个替换原来Resources的过程,这样就需要涉及到很多地方,从 hookResources的实现里看,替换了四处地方,在尽量少的 hook 原则下这样的情况还是尽量避免的。
另外一种方案在淘宝发布的《深入探索 Android 热修复技术原理》的文档里有说明,这里引用过来介绍一下。
在 AssetManager 里有一个方法叫做destroy方法
public final class AssetManager {//....private native final void destroy();//....}
对应的 native 代码如下
static void android_content_AssetManager_destroy(JNIEnv* env, jobject clazz){AssetManager* am = (AssetManager*)(env->GetIntField(clazz, gAssetManagerOffsets.mObject));ALOGV("Destroying AssetManager %p for Java object %p\n", am, clazz);if (am != NULL) {delete am;env->SetIntField(clazz, gAssetManagerOffsets.mObject, 0);}}
这里直接 delete am ,会导致调用AssetManager 的析构函数
AssetManager::~AssetManager(void){int count = android_atomic_dec(&gCount);//ALOGI("Destroying AssetManager in %p #%d\n", this, count);delete mConfig;delete mResources;// don't have a String class yet, so make sure we clean updelete[] mLocale;delete[] mVendor;}
这里delete mResources了
现在我们可以通过调用他的init方法,重新初始化
static void android_content_AssetManager_init(JNIEnv* env, jobject clazz){AssetManager* am = new AssetManager();if (am == NULL) {jniThrowException(env, "java/lang/OutOfMemoryError", "");return;}am->addDefaultAssets();ALOGV("Created AssetManager %p for Java object %p\n", am, clazz);env->SetIntField(clazz, gAssetManagerOffsets.mObject, (jint)am);}
此时在资源查找的时候发现mResources没有初始化就将所有的资源 add 一遍。
插件调用宿主的资源
在宿主开启了COMBINE_RESOURCES模式下,插件是可以调用宿主的资源的,理论上也是可以调用其他插件资源的(需要修改打包),但是不推荐这么做。这个问题可以看一下Replugin踩过的坑。
此处需要注意两个问题,如果宿主升级那么需要保证原来插件调用的资源id不能改变,否则宿主升级后,加载的插件还是拿取的旧版本资源id,可能会导致资源找不到和错乱情况,所以宿主要从使用插件起保证每个版本被插件所使用的资源不能变化id。感觉不是很实用。
这里用官方例子做一个简单的例子说明一下如何调用宿主资源。
-
首先我们需要将能被插件访问到的资源提取到一个公共模块中去
然后修改配置,将
comm_res这个模块引用到宿主模块中 -
切回我们的插件模块,将
common_res也引用到插件模块中
-
这样就可以在插件直接引用这个资源了,我直接在一个Activity中引用了这个资源
<ImageView android:layout_width="wrap_content"android:layout_height="wrap_content"android:src="@drawable/newsplash"/>
-
打包验证,调用插件可以看到这个图片是被引用到了
-
验证资源是否来自宿主中,首先先看一下插件里是否存在这个图片的资源
可以看到,插件里并没有打包到插件里,下一步看一下此资源的id是否和宿主中的资源id一致
插件里的id
宿主里的id
验证通过
-
此处验证一下公共资源的增加和变动是否会引起旧版本的插件调用资源错误
验证方式比较简单,增加几张图片
然后重新打包宿主,运行,发现此时运行旧的插件,已经发生错误了
查一下宿主的资源id,发现此时已经发生资源变更
-
要解决这个问题,需要注意两个地方,1,旧的资源不能删除,2,需要保持旧版本资源的id不变,具体见Tinker的实现