快捷導(dǎo)航

Android源碼探究之BaseDexClassLoader的使用

更新時(shí)間：2022年08月10日 11:41:45 作者：失落夏天

今天解決一個(gè)插件化問題的時(shí)候，竟然發(fā)現(xiàn)SO沒有正常加載，很怪異，最終排查下來發(fā)現(xiàn)竟然是參數(shù)傳入錯(cuò)誤導(dǎo)致的。這就扯到了本文的標(biāo)題上了，BaseDexClassLoader中的4個(gè)參數(shù)該如何傳入，傳入的又是什么呢

前言

一共有4個(gè)參數(shù)，分來來講。

1：dexFile（String類型）
2：optimizedDirectory（File類型）
3：librarySearchPath（String類型）
4：parent（ClassLoader類型）

一.dexPath(String)

官方的注釋：

     * @param dexPath the list of jar/apk files containing classes and
     * resources, delimited by {@code File.pathSeparator}, which
     * defaults to {@code ":"} on Android.

包含類和類的jar/apk文件列表資源，由{@code File.pathSeparator}分隔，其中Android上的默認(rèn)值為{@code”：“}。

也就是說這里其實(shí)是可以傳入一個(gè)集合的。

比如如下的參數(shù)都是可以被接受的：

sdcard/test/aa.apk

sdcard/test/aa.apk：sdcard/test/bb.apk：sdcard/test/cc.apk

sdcard/test/aa.apk：sdcard/test/dd.jar

其中分隔符：，保險(xiǎn)起見，可以使用File.pathSeparator替代。

示例代碼如下：

private void loadDex(List<File> apkList) {
        StringBuilder builder = new StringBuilder();
        for (File f : apkList) {
            builder.append(f.getAbsolutePath());
            builder.append(File.separatorChar);
        }
        DexClassLoader dexClassLoader = new DexClassLoader(builder.toString(), null, null, getClass().getClassLoader());
    }

二.optimizedDirectory

官方的注釋：

this parameter is deprecated and has no effect since API level 26.

解壓的路徑，這里傳入路徑的最主要目的就是為了生成odex文件夾，方便后續(xù)存儲(chǔ)odex文件。

如注釋中所寫，這個(gè)參數(shù)26開始已經(jīng)失效了。所以這里就不擴(kuò)展去講了。

三.librarySearchPath

官方的注釋：

* @param librarySearchPath the list of directories containing native

包含native目錄的目錄列表，這里要注意的，傳入的一定是so的上一級(jí)目錄才可以。如果是更上一層的目錄是不行的。前言中的問題就出在這，傳入了一個(gè)更上一層的目錄地址。

排查流程：

最終使用librarySearchPath的地方是在DexPathList的splitPaths方法中。生成File加入List中：

@UnsupportedAppUsage
    private static List<File> splitPaths(String searchPath, boolean directoriesOnly) {
        List<File> result = new ArrayList<>();
        if (searchPath != null) {
            for (String path : searchPath.split(File.pathSeparator)) {
                ...
                result.add(new File(path));
            }
        }
        return result;
    }

而使用的時(shí)候，是使用了findLibrary的方法，for循環(huán)便利上面集合中的所有path，看是否存在。

public String findLibrary(String libraryName) {
        String fileName = System.mapLibraryName(libraryName);
        for (NativeLibraryElement element : nativeLibraryPathElements) {
            String path = element.findNativeLibrary(fileName);
            if (path != null) {
                return path;
            }
        }
        return null;
    }

而尋找的最終會(huì)調(diào)用到NativeLibraryElement的findNativeLibrary方法：

public String findNativeLibrary(String name) {
            maybeInit();
            if (zipDir == null) {
                String entryPath = new File(path, name).getPath();
                if (IoUtils.canOpenReadOnly(entryPath)) {
                    return entryPath;
                }
            } else if (urlHandler != null) {
                // Having a urlHandler means the element has a zip file.
                // In this case Android supports loading the library iff
                // it is stored in the zip uncompressed.
                String entryName = zipDir + '/' + name;
                if (urlHandler.isEntryStored(entryName)) {
                  return path.getPath() + zipSeparator + entryName;
                }
            }
            return null;
        }

這段代碼也就是問題的核心了，直接使用了new File(path,name)的方式，而不是循環(huán)查找，所以只有上一層才可以。

四.parent

官方的注釋：

@param parent the parent class loader

這個(gè)比較簡(jiǎn)單，就是上一層的classLoader。

五.總結(jié)

無論是dexPath還是librarySearchPath，都是支持多路徑傳入的。路徑之間使用File.pathSeparator進(jìn)行分隔。dexPath中必須是APK或者Jar包的路徑，而librarySearchPath中必須是so文件的上一層級(jí)文件夾才可以。

到此這篇關(guān)于Android源碼探究之BaseDexClassLoader的使用的文章就介紹到這了,更多相關(guān)Android BaseDexClassLoader內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: