在android中如何用Java加載解析so
理論基礎(chǔ)
so的加載是一種解析式裝載,這與dex有一定區(qū)別,dex是先加載進(jìn)行優(yōu)化驗證生成odex,再去解析odex文件,而so更像邊解析邊裝載,在加載過程中主要解析是load段。
下面主要是以java層的so加載進(jìn)行從源碼上進(jìn)行解析加載流程。
java層的so加載流程分析
System.loadLibrary入口點
在java層我們知道加載so文件是通過System.loadLibrary函數(shù)其實現(xiàn)的,下面就以其作為入口點進(jìn)行分析它的調(diào)用關(guān)系和實現(xiàn)。
System.loadLibrary在的函數(shù)定義系統(tǒng)source\libcore\luni\src\main\java\java\lang\system.java的文件中。
下面是其函數(shù)定義實現(xiàn)。
//參數(shù)就是要加載的so文件名稱 public static void loadLibrary(String libName) { //通過調(diào)用Runtime下面的loadLibrary函數(shù)實現(xiàn) //函數(shù)有兩個參數(shù),參數(shù)1是加載的so文件名,參數(shù)2 類加載器。 Runtime.getRuntime().loadLibrary(libName, VMStack.getCallingClassLoader()); }
Runtime的loadLibray解析
通過上面的System.java的loadLibrary函數(shù)我們需要繼續(xù)分析Runtime.java文件中的loadLibray函數(shù)的定義實現(xiàn)。
Runtime的loadLibrary函數(shù)在android系統(tǒng)中的位置是
source\libcore\luni\src\main\java\java\lang\Runtime.java文件。
下面是Runtime的 loadLibrary函數(shù)的定義實現(xiàn)源碼。
/* * Searches for and loads the given shared library using the given ClassLoader. */ void loadLibrary(String libraryName, ClassLoader loader) { if (loader != null) { //通過加載器去查找要加載的so文件名 String filename = loader.findLibrary(libraryName); //查找失敗 if (filename == null) { // It's not necessarily true that the ClassLoader used // System.mapLibraryName, but the default setup does, and it's // misleading to say we didn't find "libMyLibrary.so" when we // actually searched for "liblibMyLibrary.so.so". throw new UnsatisfiedLinkError(loader + " couldn't find \"" + System.mapLibraryName(libraryName) + "\""); } //加載so文件名 String error = doLoad(filename, loader); if (error != null) { throw new UnsatisfiedLinkError(error); } return; } String filename = System.mapLibraryName(libraryName); List<String> candidates = new ArrayList<String>(); String lastError = null; //循環(huán)遍歷文件路徑 for (String directory : mLibPaths) { //文件路徑和文件名進(jìn)行拼接 String candidate = directory + filename; candidates.add(candidate); if (IoUtils.canOpenReadOnly(candidate)) { String error = doLoad(candidate, loader); if (error == null) { return; // We successfully loaded the library. Job done. } lastError = error; } } if (lastError != null) { throw new UnsatisfiedLinkError(lastError); } throw new UnsatisfiedLinkError("Library " + libraryName + " not found; tried " + candidates); }
Runtime的doLoad解析
通過上面的Runtime的loadLibrary函數(shù),我們看到加載so的函數(shù)是走到doLoad函數(shù),那么我們就需要繼續(xù)分析Runtime下的doload函數(shù)的定義實現(xiàn)。
Rutime下的doload函數(shù)在系統(tǒng)中的
source\libcore\luni\src\main\java\java\lang\Runtime.java文件中。
下面的代碼是Runtime的doload函數(shù)的定義實現(xiàn)。
private String doLoad(String name, ClassLoader loader) { // Android apps are forked from the zygote, so they can't have a custom LD_LIBRARY_PATH, // which means that by default an app's shared library directory isn't on LD_LIBRARY_PATH. // The PathClassLoader set up by frameworks/base knows the appropriate path, so we can load // libraries with no dependencies just fine, but an app that has multiple libraries that // depend on each other needed to load them in most-dependent-first order. // We added API to Android's dynamic linker so we can update the library path used for // the currently-running process. We pull the desired path out of the ClassLoader here // and pass it to nativeLoad so that it can call the private dynamic linker API. // We didn't just change frameworks/base to update the LD_LIBRARY_PATH once at the // beginning because multiple apks can run in the same process and third party code can // use its own BaseDexClassLoader. // We didn't just add a dlopen_with_custom_LD_LIBRARY_PATH call because we wanted any // dlopen(3) calls made from a .so's JNI_OnLoad to work too. // So, find out what the native library search path is for the ClassLoader in question... String ldLibraryPath = null; if (loader != null && loader instanceof BaseDexClassLoader) { ldLibraryPath = ((BaseDexClassLoader) loader).getLdLibraryPath(); } // nativeLoad should be synchronized so there's only one LD_LIBRARY_PATH in use regardless // of how many ClassLoaders are in the system, but dalvik doesn't support synchronized // internal natives. synchronized (this) { return nativeLoad(name, loader, ldLibraryPath); } }
總結(jié)
從以上的源碼實現(xiàn)流程分析,我們可以看出Android在java層加載so的接口是System.loadLibrary(),通過層層遞進(jìn)關(guān)系從而實現(xiàn)java層的加載so。
下圖是詳細(xì)的java層加載so函數(shù)的調(diào)用關(guān)系。
到此這篇關(guān)于在android中如何用Java加載解析so的文章就介紹到這了,更多相關(guān)Android 加載so內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
MT6589平臺通話錄音時播放提示音給對方功能的具體實現(xiàn)
MT6589平臺通話錄音時如何播放提示音給對方,可以通過修改以下文件即可,希望對你有所幫助2013-06-06Android自定義控件仿iOS滑塊SwitchButton
這篇文章主要為大家詳細(xì)介紹了Android自定義控件模仿iOS滑塊SwitchButton,具有一定的參考價值,感興趣的小伙伴們可以參考一下2018-12-12Android?利用ImageView屬性實現(xiàn)選中和未選中效果
這篇文章主要介紹了Android巧用ImageView屬性實現(xiàn)選中和未選中效果,實現(xiàn)思路通常我們會選擇在布局里加個ImageView,然后通過代碼層面加個判斷去讓ImageView加載不同狀態(tài)的圖片,需要的朋友可以參考下2023-06-06