Android插件化原理

1,Android平时开发过程中会用到系统资源(android.R),这些资源并不在我们自己的APK中,为何可以引用?

TestActivity.java

Drawable drawable = getResources().getDrawable(android.R.drawable.sym_def_app_icon);

2,DexClassLoader的构造方法中,dexPath可以传APK路径?

DexClassLoader.java

public class DexClassLoader extends BaseDexClassLoader {

    /**

     * ...

     * @param dexPath the list of jar/apk files containing classes and

     *     resources, delimited by {@code File.pathSeparator}, which

     *     defaults to {@code ":"} on Android

     * ...

     */

    public DexClassLoader(String dexPath, String optimizedDirectory,

            String libraryPath, ClassLoader parent) {

    ...

}

下面针对上面的这两点疑问,我们来逐一分析下。

(一)Resources的创建过程

既然要分析资源如何引用,那么我们就直接从资源的获取开始吧,以获取Drawable为例(getDrawable)

Resources.java

...

public Drawable getDrawable(@DrawableRes int id) throws NotFoundException {

    final Drawable d = getDrawable(id, null);// 1,调用了下面的getDrawable

    if (d != null && d.canApplyTheme()) {

        Log.w(TAG, "Drawable " + getResourceName(id) + " has unresolved theme "

                + "attributes! Consider using Resources.getDrawable(int, Theme) or "

                + "Context.getDrawable(int).", new RuntimeException());

    }

    return d;

}

...

public Drawable getDrawable(@DrawableRes int id, @Nullable Theme theme) throws NotFoundException {

    TypedValue value;

    synchronized (mAccessLock) {

        value = mTmpValue;

        if (value == null) {

            value = new TypedValue();

        } else {

            mTmpValue = null;

        }

        getValue(id, value, true);

    }

    final Drawable res = loadDrawable(value, id, theme);//2,又调用了下面的loadDrawable

    synchronized (mAccessLock) {

        if (mTmpValue == null) {

            mTmpValue = value;

        }

    }

    return res;

}

...

Drawable loadDrawable(TypedValue value, int id, Theme theme) throws NotFoundException {

    ...

    Drawable dr;//3,dr赋值的地方,这里出现了3处

    if (cs != null) {

        dr = cs.newDrawable(this);// 3.1,从ConstantState中创建,首次获取走不到这里

    } else if (isColorDrawable) {

        dr = new ColorDrawable(value.data);//3.2,是一个颜色Drawable

    } else {

        dr = loadDrawableForCookie(value, id, null);//3.3,图片就是这个方法里面加载出来的,那么继续看

    }

    ...

    return dr;

}

...

private Drawable loadDrawableForCookie(TypedValue value, int id, Theme theme) {

    if (value.string == null) {

        // 这里抛出了NotFound异常,留意一下,先不管

        throw new NotFoundException("Resource \"" + getResourceName(id) + "\" ("

                + Integer.toHexString(id) + ") is not a Drawable (color or path): " + value);

    }


    final String file = value.string.toString();


    if (TRACE_FOR_MISS_PRELOAD) {

        // Log only framework resources

        if ((id >>> 24) == 0x1) {

            final String name = getResourceName(id);// 这里获取了一下Resource Name,只是为了Log下? 留意一下,也不用管

            if (name != null) {

                Log.d(TAG, "Loading framework drawable #" + Integer.toHexString(id)

                        + ": " + name + " at " + file);

            }

        }

    }


    if (DEBUG_LOAD) {

        Log.v(TAG, "Loading drawable for cookie " + value.assetCookie + ": " + file);

    }


    final Drawable dr;//4,这里开始,准备加载图片了


    Trace.traceBegin(Trace.TRACE_TAG_RESOURCES, file);

    try {

        if (file.endsWith(".xml")) {

            // 4.1,这里是获取.xml的,不用看

            final XmlResourceParser rp = loadXmlResourceParser(

                    file, id, value.assetCookie, "drawable");

            dr = Drawable.createFromXml(this, rp, theme);

            rp.close();

        } else {

            // 4.2,那么获取图片的地方,就是这里了,走到了mAssets里面

            final InputStream is = mAssets.openNonAsset(

                    value.assetCookie, file, AssetManager.ACCESS_STREAMING);

            dr = Drawable.createFromResourceStream(this, value, is, file, null);

            is.close();

        }

    } catch (Exception e) {

        Trace.traceEnd(Trace.TRACE_TAG_RESOURCES);

        final NotFoundException rnf = new NotFoundException(

                "File " + file + " from drawable resource ID #0x" + Integer.toHexString(id));

        rnf.initCause(e);

        throw rnf;

    }

    Trace.traceEnd(Trace.TRACE_TAG_RESOURCES);


    return dr;

}

既然跑到了mAssets里面,那么继续进入mAssets里面分析了,查看Resources中mAssets这个全局变量,可以知道这个mAssets是一个AssetManager对象,

那么我们就去AssetManager中继续查看这个openNonAsset方法:

AssetManager.java

...

public final InputStream openNonAsset(String fileName) throws IOException {

    return openNonAsset(0, fileName, ACCESS_STREAMING);//5,走到了下面的openNonAsset方法

}

...

public final InputStream openNonAsset(int cookie, String fileName, int accessMode)

    throws IOException {

    synchronized (this) {

        if (!mOpen) {

            throw new RuntimeException("Assetmanager has been closed");//

        }

        long asset = openNonAssetNative(cookie, fileName, accessMode);//6,走到了下面的native方法里面

        if (asset != 0) {

            AssetInputStream res = new AssetInputStream(asset);//根据native返回的long值,得到了我们想要的图片流

            incRefsLocked(res.hashCode());

            return res;

        }

    }

    throw new FileNotFoundException("Asset absolute file: " + fileName);//

}

...

private native final long openNonAssetNative(int cookie, String fileName, int accessMode);

...

到这里,如果继续分析,一方面是语言方面的阻力,另一方面容易忘记我们最初的目的(Resource如何加载一张图片);

好,我们到这里先停下来回顾一下刚才的流程,整个流程中,出现异常的地方有4处,

其中和的异常,正常的图片加载过程中,不会出现,不用管,抛出的是FileNotFound异常,属于找具体资源文件时抛出的异常,

我们知道,ID和资源是一一对应的,也就是说ID和资源的名称ResourceName也是一一对应的,假如能通过ID找到对于的ResourceName,一般这个

资源就可以被正常加载了,对照上面的代码,也就是假如没有抛出异常,基本上也不会抛出异常。

(关于资源的详细打包&获取,大家可以阅读下老罗关于资源的系列分析文章:传送门)

好,那我们继续看下对应的方法getResourceName:

Resources.java

...

public String getResourceName(@AnyRes int resid) throws NotFoundException {

    String str = mAssets.getResourceName(resid);// 这里又走到了mAssets里面

    if (str != null) return str;

    throw new NotFoundException("Unable to find resource ID #0x"

            + Integer.toHexString(resid));

}

...

继续分析

AssetManager.java

...

/*package*/ native final String getResourceName(int resid);

...

我们发现又进入了native代码,同样,我们不再继续分析native代码,现在我们冷静的回顾一下之前的整个流程,我们通过传入一个图片ID,

一步步走,无论是获取ResourceName,还是获取最终的图片流,都会走到这个AssetManager里面。

好,到这里,我们结合一下一开始开发出的疑问【Android平时开发过程中会用到系统资源(android.R),这些资源并不在我们自己的APK中,为何可以引用?】,

应用程序是通过一个Resources实例来获取资源的,而Resource又是通过一个AssetManager来获取资源的,那么这个AssetManager在应用程序初始化的时候,

一定会有添加系统资源的环节,要么在构造方法里面,要么就是提供了public的添加接口。

我们先分析AssetManager的构造方法:

AssetManager.java

...

public AssetManager() {

    synchronized (this) {

        if (DEBUG_REFS) {

            mNumRefs = 0;

            incRefsLocked(this.hashCode());

        }

        init(false);// 1,调用了native的init方法

        if (localLOGV) Log.v(TAG, "New asset manager: " + this);

        ensureSystemAssets();// 2,构造一个SystemAsset

    }

}


private static void ensureSystemAssets() {

    synchronized (sSync) {

        if (sSystem == null) {

            AssetManager system = new AssetManager(true);//3,构造一个system的AssetManager

            system.makeStringBlocks(null);

            sSystem = system;

        }

    }

}


private AssetManager(boolean isSystem) {

    if (DEBUG_REFS) {

        synchronized (this) {

            mNumRefs = 0;

            incRefsLocked(this.hashCode());

        }

    }

    init(true);//4,同样调用了native的init方法

    if (localLOGV) Log.v(TAG, "New asset manager: " + this);

}

...

private native final void init(boolean isSystem);

...

sSystem?一个static的AssetManager,难道这个就是用来加载系统资源的?

如果是,我们传入系统资源id: android.R.drawable.sym_def_app_icon,调用getResourceName的时候,一定会调用了这个sSystem实例,

而getResourceName是一个native方法,难道native里面使用了sSystem这个Java层的变量了?

android_util_AssetManager.cpp

...

static jstring android_content_AssetManager_getResourceName(JNIEnv* env, jobject clazz,

                                                            jint resid)

{

    ...

    ResTable::resource_name name;

    if (!am->getResources().getResourceName(resid, &name)) {

        return NULL;

    }

    ...

}

...

走到了ResourceTypes.cpp

ResourceTypes.cpp

...

bool ResTable::getResourceName(uint32_t resID, resource_name* outName) const

{

    if (mError != NO_ERROR) {

        return false;

    }


    const ssize_t p = getResourcePackageIndex(resID);

    const int t = Res_GETTYPE(resID);

    const int e = Res_GETENTRY(resID);


    if (p < 0) {

        if (Res_GETPACKAGE(resID)+1 == 0) {

            LOGW("No package identifier when getting name for resource number 0x%08x", resID);

        } else {

            LOGW("No known package when getting name for resource number 0x%08x", resID);

        }

        return false;

    }

    if (t < 0) {

        LOGW("No type identifier when getting name for resource number 0x%08x", resID);

        return false;

    }


    const PackageGroup* const grp = mPackageGroups[p];

    if (grp == NULL) {

        LOGW("Bad identifier when getting name for resource number 0x%08x", resID);

        return false;

    }

    if (grp->packages.size() > 0) {

        const Package* const package = grp->packages[0];


        const ResTable_type* type;

        const ResTable_entry* entry;

        ssize_t offset = getEntry(package, t, e, NULL, &type, &entry, NULL);

        if (offset <= 0) {

            return false;

        }


        outName->package = grp->name.string();

        outName->packageLen = grp->name.size();

        outName->type = grp->basePackage->typeStrings.stringAt(t, &outName->typeLen);

        outName->name = grp->basePackage->keyStrings.stringAt(

            dtohl(entry->key.index), &outName->nameLen);


        // If we have a bad index for some reason, we should abort.

        if (outName->type == NULL || outName->name == NULL) {

            return false;

        }


        return true;

    }

    return false;

}

...

追踪了下native层的代码,发现并没有使用mSystem这个变量,那说明:系统资源的获取并不是通过mSystem这个实例来获取的;

回顾之前的AssetManager,两个构造方法里面都调用了native的init方法:

android_util_AssetManager.cpp

...

static void android_content_AssetManager_init(JNIEnv* env, jobject clazz, jboolean isSystem)

{

    if (isSystem) {

        verifySystemIdmaps();

    }

    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->SetLongField(clazz, gAssetManagerOffsets.mObject, reinterpret_cast(am));

}

...

走到AssetManager.cpp中:

AssetManager.cpp

...

static const char* kSystemAssets = "framework/framework-res.apk";// 系统资源文件

...

bool AssetManager::addDefaultAssets()

{

    const char* root = getenv("ANDROID_ROOT");

    LOG_ALWAYS_FATAL_IF(root == NULL, "ANDROID_ROOT not set");


    String8 path(root);// 获取系统root目录,即 /system/

    path.appendPath(kSystemAssets);// 拼接得到 /system/framework/framework-res.apk


    return addAssetPath(path, NULL);// 添加系统资源路径

}

...

果然是在这个native的init里面添加系统资源的,找一个root过的手机进到这个路劲下看了下:


Android插件化原理_第1张图片

原来系统资源就是这么简单的添加进去的,那么这个addAssetPath在Java层有没有提供入口呢,反过来看AssetManager的代码:

AssetManager.java

...

/**

 * Add an additional set of assets to the asset manager.  This can be

 * either a directory or ZIP file.  Not for use by applications.  Returns

 * the cookie of the added asset, or 0 on failure.

 * {@hide}

 */

public final int addAssetPath(String path) {

    synchronized (this) {

        int res = addAssetPathNative(path);

        makeStringBlocks(mStringBlocks);

        return res;

    }

}

...

果然有这个方法,虽然是hide的,但是有反射,就不成问题。

那么既然可以通过添加一个APK的路径到AssetManager中,那么插件资源的获取自然也就不是问题了,

APNP就是通过这种方法,添加插件的APK路径,并且更换相应的AssetManager来获取插件资源的。


下面我继续分析DexClassLoader的疑问(DexClassLoader的构造方法中,dexPath可以传APK路径?)

(二)DexClassLoader加载过程

说到DexClassLoader,单纯Java层的使用,其实并没有太多内容可说,但是基于Dalvik虚拟机(4.4出现ART)虚拟机如何加载class文件,

倒是有些内容需要大家提前了解下,也正是这块的内容决定了Android插件化的可行性。

1,Android的安装文件APK到底是啥?

APK即Android安装包文件,但是对于Android虚拟机来说,APK并不能直接执行,需要在运行的时候将APK文件中的DEX翻译成机器码再执行,

应用程序安装的时候,虚拟机会抽取apk中的dex文件,并且进行一定的优化(即dexopt,ART下为dex2oat),最后生成odex文件(即optimized dex);

在运行的时候,则通过DexClassLoader加载优化过后的odex文件翻译成机器码后执行;

apk中还包括了Android的资源文件.arsc,资源文件的加载就是上面的AssetManager来操作的,这里不再详情描述,所以大家只要把APK文件理解成

Java类 + 资源文件的统一存储文件好了。

2,Dex文件过大无法运行?

随着业务的迭代,大家可能都遇到了“65535”这个问题,这个是Dalvik虚拟机的限制,也就是说方法、类、属性值过多了,虚拟机记录不了了,

所以在生成DEX文件的时候,如果方法、类、属性数量超过就抛出异常。

后来Google通过MultiDex解决了这个问题,即一个APK文件不再是只有一个dex文件,可以有多个dex,也正是这项技术的出现,让插件化技术浮出水面。

(其实MultiDex只是给开发者提供了一种多dex的方案,翻读1.6的DexClassLoader源码就可以发现,那个时候插件化就可以做了)

3,插件化类加载的最终原理

既然虚拟机是通过DexClassLoader来加载类的,我们先来看一下这个DexClassLoader(android 4.0)

DexClassLoader.java

public class DexClassLoader extends BaseDexClassLoader {

    public DexClassLoader(String dexPath, String optimizedDirectory,

            String libraryPath, ClassLoader parent) {

        super(dexPath, new File(optimizedDirectory), libraryPath, parent);

    }

}

很显然,DexClassLoader只是一个空壳子,其实在早些版本的时候,几乎加载类的所有逻辑都在DexClassLoader中,只是4.0在原来的基础上,

让代码结构更合理,更优化了,继续看BaseDexClassLoader:

BaseDexClassLoader.java

...

public class BaseDexClassLoader extends ClassLoader {

    ...

    private final DexPathList pathList;

    ...

    public BaseDexClassLoader(String dexPath, File optimizedDirectory,

            String libraryPath, ClassLoader parent) {

        super(parent);


        this.originalPath = dexPath;

        this.pathList =

            new DexPathList(this, dexPath, libraryPath, optimizedDirectory);

    }


    @Override

    protected Class findClass(String name) throws ClassNotFoundException {

        Class clazz = pathList.findClass(name);


        if (clazz == null) {

            throw new ClassNotFoundException(name);

        }


        return clazz;

    }

    ...

}

在上面的findClass中,BaseDexClassLoader是通过全局变量DexPathList来寻找目标类的,继续看DexPathList:

DexPathList.java

...

/*package*/ final class DexPathList {

    ...

    private final Element[] dexElements;

    ...

    public DexPathList(ClassLoader definingContext, String dexPath,

            String libraryPath, File optimizedDirectory) {

        ...

        this.dexElements =

            makeDexElements(splitDexPath(dexPath), optimizedDirectory);

        ...

    }

    ...

    public Class findClass(String name) {

        for (Element element : dexElements) {

            DexFile dex = element.dexFile;


            if (dex != null) {

                Class clazz = dex.loadClassBinaryName(name, definingContext);

                if (clazz != null) {

                    return clazz;

                }

            }

        }


        return null;

    }

    ...


    /*package*/ static class Element {

        ...

        public final DexFile dexFile;


        public Element(File file, ZipFile zipFile, DexFile dexFile) {

            ...

            this.dexFile = dexFile;

        }

        ...

    }

}

到这里,似乎已经很明显了,DexPathList这有一个Element列表,每个Element中包含一个DexFile,如果大家去看下makeDexElements的源码就会发现:

每个DexFile都对应一个Dex文件!

DexFile最终会通过一个native方法加载目标类,我们无须关注这个native方法是如何加载的,到这里我们来看下APK和BaseDexClassLoader的对应关系:


Android插件化原理_第2张图片

虚拟机最终都会通过DexPathList来加载class,通过DexPathList的findClass方法可以知道,它正是通过遍历每个DexFile来寻找目标class的。

 那么现在我们思考一下,假如我们想加载一个其他的APK文件中的类,怎么办?

返回到我们最初的疑问,DexClassLoader是可以自己构造的,并且必须需要传入一个APK的路径,并通过一些列的解析,把APK文件最终分解成一个DexFile数组,

既然这样,假如我们构造一个其他APK的DexClassLoader,然后它里面的DexFile数组合并到系统的DexClassLoader中去,这样系统不就可以找到其他APK的类了么!

基本操作如下:


Android插件化原理_第3张图片

通过把我们自己构造出来的DexClassLoader合并到系统的Classloader中,我们就可以成功的加载一个未安装的APK文件中的class了,而这正是MultiDex的基本原理!

(其实,如果上面把插件的DexFile放到列表的前面,还可以当热修复来使用,大家可以简单思考下~)

你可能感兴趣的:(Android插件化原理)