Android源碼探究之BaseDexClassLoader的使用
前言
一共有4個參數,分來來講。
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上的默認值為{@code”:“}。
也就是說這裡其實是可以傳入一個集合的。
比如如下的參數都是可以被接受的:
sdcard/test/aa.apk
sdcard/test/aa.apk:sdcard/test/bb.apk:sdcard/test/cc.apk
sdcard/test/aa.apk:sdcard/test/dd.jar
其中分隔符:,保險起見,可以使用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文件夾,方便後續存儲odex文件。
如註釋中所寫,這個參數26開始已經失效瞭。所以這裡就不擴展去講瞭。
三.librarySearchPath
官方的註釋:
* @param librarySearchPath the list of directories containing native
包含native目錄的目錄列表,這裡要註意的,傳入的一定是so的上一級目錄才可以。如果是更上一層的目錄是不行的。前言中的問題就出在這,傳入瞭一個更上一層的目錄地址。
排查流程:
最終使用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; }
而使用的時候,是使用瞭findLibrary的方法,for循環便利上面集合中的所有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; }
而尋找的最終會調用到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)的方式,而不是循環查找,所以隻有上一層才可以。
四.parent
官方的註釋:
@param parent the parent class loader
這個比較簡單,就是上一層的classLoader。
五.總結
無論是dexPath還是librarySearchPath,都是支持多路徑傳入的。路徑之間使用File.pathSeparator進行分隔。dexPath中必須是APK或者Jar包的路徑,而librarySearchPath中必須是so文件的上一層級文件夾才可以。
到此這篇關於Android源碼探究之BaseDexClassLoader的使用的文章就介紹到這瞭,更多相關Android BaseDexClassLoader內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- Java源碼解析之ClassLoader
- Android 中的類文件和類加載器詳情
- 深入瞭解Java File分隔符和Path分隔符的使用
- Android解決getExternalStorageDirectory在29後廢棄問題(推薦)
- Java IO之File 類詳解