Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> 關於Android編程 >> Android中so使用知識和問題總結以及插件開發過程中加載so的方案解析

Android中so使用知識和問題總結以及插件開發過程中加載so的方案解析

編輯:關於Android編程

一、前言

Android中有時候為了效率以及平台開發庫的支持,難免會用到NDK開發,那麼都會產生一個so文件,通過native方法進行調用,開發和調用步驟很簡單,這裡就不多說了,本文主要來介紹,我們在使用so的時候總是會出現一些常見的問題,而現在插件化開發也很普遍了,有時候插件中也會包含一些so文件,需要加載,這時候也會出現一些問題。本文就來詳細總結一下這些問題出現的原因,以及解決方法,主要還是通過源碼來分析。

 

二、涉及到的源碼類

因為本文主要通過分析源碼來分析so使用的知識點和問題總結,所以涉及到了很多的源碼類,這裡就現提供一下:

1、PackageManagerService.java
+setNativeLibraryPaths:設置應用的native庫路徑
+scanPackageDirtyLI:掃描包內容初始化應用信息

2、ActivityManagerService.java
+startProcessLocked:發送命令給Zygote進程啟動一個虛擬機

3、NativeLibraryHelper.java

底層實現類:com_android_internal_content_NativeLibraryHelper.cpp

+copyNativeBinariesWithOverride:釋放apk中的so文件到本地目錄

+findSupportedAbi:遍歷apk中的so文件結合abiList值得到應用支持的abi類型索引值

4、LoadApk類和ApplicationLoaders類

5、VMRuntime.java

底層實現類:dalvik_system_VMRuntime.c

+getInstructionSet:獲取虛擬機的指令集類型

+is64BitAbi:判斷VM是否為64位

6、Runtime.java

底層實現類:dalvik/vm/native/java_lang_Runtime.cpp,dalvik/vm/Native.cpp

+nativeLoad:加載so文件

 

三、Android中so文件的編譯平台

Android中在進行NDK開發的時候,都知道因為機型雜而多的原因,沒有一個大的標准,所以很多廠商都會采用不同型號的cpu,那麼在編譯so文件的時候,就需要進行交叉編譯出多個cpu平台版本,現在主流的cpu架構版本:

armeabi/armeabi-v7a:這個架構是arm類型的,主要用於Android4.0之後的,cpu值32位的

x86/x86_64:這個架構是x86類型的,有32位和64位,占用的設備比例比較小

arm64-v8:這個架構是arm類型,主要用於Android5.0之後,cpu是64位的

這裡可以看到,其中arm類型的是往下兼容策略,比如arm64-v8a肯定兼容armeabi/armeabi-v7a,也就是說armeabi/armeabi-v7a架構的so文件可以用在arm64-v8a的設備中的,而armeabi-v7a也是兼容armeabi的,但是因為cpu型號不同,所以arm體系和x86體系之間是不能相互兼容的。

 

四、Android中so加載流程

在Android中如果想使用so的話,首先得先加載,加載現在主要有兩種方法,一種是直接System.loadLibrary方法加載工程中的libs目錄下的默認so文件,這裡的加載文件名是xxx,而整個so的文件名為:libxxx.so。還有一種是加載指定目錄下的so文件,使用System.load方法,這裡需要加載的文件名是全路徑,比如:xxx/xxx/libxxx.so。

上面的兩種加載方式,在大部分場景中用到的都是第一種方式,而第二種方式用的比較多的就是在插件中加載so文件了。

不管是第一種方式還是第二種方式,其實到最後都是調用了Runtime.java類的加載方法doLoad:

\

這裡會先從類加載中獲取到nativeLib路徑,然後在調用native方法nativeLoad(java_lang_Runtime.cpp)

\

這裡調用了一個核心的方法dvmLoadNativeCode(dalvik/vm/Native.cpp)

\

注意:

這裡有一個檢測異常的代碼,而這個錯誤,是我們在使用插件開發加載so的時候可能會遇到的錯誤,比如現在我們使用DexClassLoader類去加載插件,但是因為我們為了插件能夠實時更新,所以每次都會賦值新的DexClassLoader對象,但是第一次加載so文件到內存中了,這時候退出程序,但是沒有真正意義上的退出,只是關閉了Activity了,這時候再次啟動又會賦值新的加載器對象,那麼原先so已經加載到內存中了,但是這時候是新的類加載器那麼就報錯了,解決辦法其實很簡單,主要有兩種方式:

第一種方式:在退出程序的時候采用真正意義上的退出,比如調用System.exit(0)方法,這時候進程被殺了,加載到內存的so也就被釋放了,那麼下次賦值新的類加載就在此加載so到內存了,

第二種方式:就是全局定義一個static類型的類加載DexClassLoader也是可以的,因為static類型是保存在當前進程中,如果進程沒有被殺就一直存在這個對象,下次進入程序的時候判斷當前類加載器是否為null,如果不為null就不要賦值了,但是這個方法有一個弊端就是類加載器沒有從新賦值,如果插件這時候更新了,但是還是使用之前的加載器,那麼新插件將不會進行加載。

 

繼續往下看:

\

這裡主要調用了兩個核心的系統方法,dlopen和dlsym,這兩個方法用途還是很多的,一般是先加載so文件,然後得到指定函數的指針,最後直接調用即可,主要用於調用動態的調用so中的指定函數功能。而且這裡注意到了最開始先調用so中的JNI_OnLoad函數,這個函數是so被加載之後調用的第一個方法。

 

到這裡我們就總結一下Android中加載so的流程:

1、調用System.loadLibrary和System.load方法進行加載so文件

2、通過Runtime.java類的nativeLoad方法進行最終調用,這裡需要通過類加載器獲取到nativeLib路徑。

3、到底層之後,就開始使用dlopen方法加載so文件,然後使用dlsym方法調用JNI_OnLoad方法,最終開始了so的執行。

 

五、Android中類加載器關聯so路徑

上面分析so加載過程中可以發現有一個地方,就是通過類加載器來獲取到so的路徑,那麼Android中的主要類加載器有兩個,一個是PathClassLoader和DexClassLoader,關於這兩個類加載不多說了,網上資料很多可以自行查找閱讀。而PathClassLoader是我們Android中默認的類加載器,也就是apk文件就是由他來加載的,我們可以通過查看源碼得知,Android中加載apk的類加載可以從LoadApk.java類查找到:

\

注意:

這個類很重要的,而這個類加載器也是我們在做插件的時候,需要做一些操作,比如需要把加載插件的DexClassLoader類給添加到這個系統加載器中,就可以解決插件中組件的生命周期問題。

 

看看這個類加載器在哪裡賦值的:

\

去看看ApplicationLoaders.java類:

\

看到了,這裡就是定義了PathClassLoader類了,所以我們Android中應用的默認加載器是PathClassLoader,再去看看這個類加載器的nativeLib是哪裡:

\

 

六、Android中so文件如何釋放

我們在使用System.loadLibrary加載so的時候,傳遞的是so文件的libxxx.so中的xxx部分,那麼系統是如何找到這個so文件然後進行加載的呢?這個就要先從apk文件安裝時機說起。

我們如果還沒有分析源碼之前,大致能夠猜想到的流程是:

在安裝apk的時候,系統解析apk文件,因為so文件肯定是存放在libs下指定平台目錄中的,而apk文件本身就是一個壓縮文件,所以可以進行解壓,然後讀取libs目錄下的so文件,進行本地釋放解壓到指定目錄,然後在加載的時候就先拼接so文件的全路徑,最後在進行加載工作即可。

通過猜想,下面就通過源碼來分析一下流程,系統在安裝apk的時候,是調用系統類:PackageManagerService.java類:

主要的核心方法是scanPackageDirtyLI:

\

這個方法主要通過傳遞的pkg變量,開始構造applicationInfo信息。我們往下面看,找到設置nativeLib信息的代碼:

\

這裡注意有一個判斷,是不是多平台架構的應用:

\

所以,我們看看info.flags有沒有設置這個標志,我們看到上面的pkg變量是通過解析apk文件的類PackageParser.java類中獲取到的,所以可以去這個類中找這個標志位的設置。

\

這裡看到了,如果在AndroidManifest.xml中設置了Application中的multiArch屬性值的話就有,但是我們默認都沒有設置這個屬性值,那麼就是false,也就是說一般應用都不是多平台的。所以上面的isMultiArch方法就返回false,代碼就走到了這裡:

\

在這裡就有很多知識點了,而這裡可以看到,就涉及到了so文件的釋放工作了,主要是在NativeLibraryHelper類中,但是這裡看到首先獲取abiList值:

\

通過Build.SUPPORTED_ABIS來獲取到的:

\

最終是通過獲取系統屬性:ro.product.cpu.abilist的值來得到的,我們可以使用getprop命令來查看這個屬性值:

\

這裡獲取到的值是:arm64-v8a,armeabi-v7a,armeabi,我用的是64位的cpu設備,所以可以看到他有多個cpu架構可選,而且看到這個順序會想到,這個順序正好是向下兼容的順序。

 

現在去看看NativeLibraryHelper類的copyNativeBinariesForSupportedAbi方法:

\

這個方法中主要干了三件事:

第一件事是獲取應用所支持的arch架構類型

第二件事是通過架構類型獲取so釋放的目錄

第三件事是native層中釋放apk中的指定架構的so到設備目錄中

 

第一件事:獲取應用所支持的arch架構類型

NativeLibraryHelper類的findSupportedAbi方法,其實這個方法就是查找系統當前支持的架構型號索引值:

\

看看native方法的實現:

\

這裡看到了,會先讀取apk文件,然後遍歷apk文件中的so文件,得到全路徑然後在和傳遞進來的abiList進行比較,得到合適的索引值,其實實現邏輯很簡單:abiList是:arm64-v8a,armeabi-v7a,armeabi,然後就開始比例apk中有沒有這些架構平台的so文件,如果有,就直接返回abiList中的索引值即可,比如說apk中的libs結構如下:

\

那麼這時候返回來的索引值就是0,代表的是arm64-v8a架構的。如果apk文件中沒有arm64-v8a目錄的話,那麼就返回1,代表的是armeabi-v7a架構的。依次類推。得到應用支持的架構索引之後就可以獲取so釋放到設備中的目錄了。

 

第二件事:獲取so釋放之後的目錄

這裡主要通過VMRuntime.java中的getInstructionSet方法:

\

這裡調用了一個map結構值:

\

這裡的arch架構和目錄對應關系,如果arch是arm64-v8a的話,那麼目錄就是arm64了。

 

第三件事:釋放apk中的so文件

直接調用的是native層方法iterateOverNativeFiles:

\

 

好了到這裡就講完了上面的三件事了,而這三件事做完之後,apk中的so文件就會被釋放到本地設備中的指定目錄中了,當然這裡系統會根據abiList中的值以及apk中包含的arch類型的so來決定釋放哪個目錄中的so文件,比如這裡通過ApplicationInfo類來打印當前應用的nativeLibraryDir值:

\

打印的結果:

\

看到了,因為是arm64-v8a類型的,所以目錄是arm64的,而且可以看到這個應用不是多平台的。

 

我們可以看到Android中是如何釋放apk中的so文件到本地目錄的:

1、通過遍歷apk文件中的so文件的全路徑,然後和系統的abiList中的類型值進行比較,如果匹配到了就返回arch類型的索引值

2、得到了應用所支持的arch類型之後,就開始獲取創建本地釋放so的目錄

3、然後開始釋放so文件

 

我們在PackageMangerService類中繼續往下看:

\

這裡還要保存上面獲取到應用支持的arch類型值,我們可以使用反射打印這個值:

\

打印結果:

\

這個值在後面應用創建VM的時候會用到。

 

接著開始設置應用的nativeLib路徑了:

\

看看這個方法的實現:

\

這裡先判斷是不是64位:

\

通過arch類型對應的目錄來判斷的:

\

這裡如果是64位,目錄就是lib,如果是32位就是lib64:

\

這樣就和我們上面釋放so文件的目錄保持一致了,所以這裡的ApplicationInfo類中的lib路徑就是我們上面釋放so之後的路徑了。

 

在之前說到了類加載器中的lib路徑,我們可以打印一下庫路徑的,這裡直接使用getClassLoader得到加載器打印即可:

\

這裡看到Library的目錄包含很多路徑。

 

七、Android中64位系統如何兼容32位的so

上面分析完了,so文件的釋放工作,下面繼續來看一下如果一個64位系統的Android設備如何做到能夠運行32位的so文件,這個就需要從應用的啟動說起了,那麼這個類就是ActivityManagerService.java,有一個核心的方法:startProcessLocked,這個方法就是向Zygote進程發送一個消息,為這個應用創建虛擬機開始運行程序了:

\

這裡在發送消息給Zygote進程,看到這裡通過ApplicationInfo中的primaryCpuAbi類型告訴Zygote改創建多少位的虛擬機,我們查看系統啟動文件init.rc內容:

\

這裡會啟動一個64位的Zygote進程

\

然後啟動一個32位的Zygot進程

 

所以這裡應該就可以想明白了,原來系統啟動的時候,如果是64位的系統設備,會啟動兩個Zygote進程用來兼容32位類型的應用,我們可以使用ps命令查看進程:

\

看到了,這裡果然啟動了兩個Zygote進程,一個64位的,一個是32位的。所以兼容功能的大致流程圖應該是這樣的:

\

上層啟動應用的時候會把應用的abi類型帶過來,然後這裡會根據這個類型發送給具體的Zygote進程消息,來創建虛擬機開始運行程序,這樣就做到了兼容。

 

八、Android插件中如何加載so文件

有時候我們在開發插件的時候,可能會調用so文件,一般來說有兩種方案:

一種是在加載插件的時候,先把插件中的so文件釋放到本地目錄,然後在把目錄設置到DexClassLoader類加載器的nativeLib中。

一種在插件初始化的時候,釋放插件中的so文件到本地目錄,然後使用System.load方法去全路徑加載so文件

這兩種方式的區別在於,第一種方式的代碼邏輯放在了宿主工程中,同時so文件可以放在插件的任意目錄中,然後在解壓插件文件找到這個so文件釋放即可。第二種方式的代碼邏輯是放在了插件中,同時so文件只能放在插件的assets目錄中,然後通過把插件文件設置到程序的AssetManager中,最後通過訪問assets中的so文件進行釋放。

 

上面就全部分析完了Android中關於so加載的相關內容:

1、so編譯平台問題

2、so加載流程分析

3、so文件釋放功能分析

4、so文件兼容功能分析

5、插件中so文件調用功能分析

 

九、常見問題分析

第一個問題:Could not find libxxx.so

\

這個問題看上去很好理解,就是在調用加載so的方法的時候,到底層使用dlopen方法打開so文件,發現找不到這個so文件,那麼這個問題產生的原因主要有兩個:

第一個是我們的確忘了在工程的libs下存放so文件了;

第二個是我們把so文件放錯目錄了;

第一個原因就不多說了,主要來看第二原因:

有時候我們在開發項目的時候,可能會放多個架構類型的so文件,那麼現在假如我的設備是arm64-v8a類型的,我的項目中有三個so文件,比如叫做AAA.so,BBB.so,CCC.so,然後我再arm64-v8a目錄中放了AAA.so,BBB.so,而CCC.so忘了放了,但是會放到armeabi-v7a和armeabi目錄中,那麼這時候就會發生找不到CCC.so的錯誤,原因很簡單:

上面分析了apk中so文件的釋放邏輯,系統會先遍歷apk中所有so文件的全路徑,然後在結合abiList的值來決定最終釋放哪個目錄中的so文件,那麼現在系統是arm64-v8a了,而apk中的libs下也有arm64-v8a,所以這裡就會把apk中的libs\arm64-v8a中的所有so文件釋放解壓到本地目錄中,而不會在去釋放armeabi/armeabi-v7a了。因為arm64-v8a中沒有CCC.so文件,所以最終釋放到本地目錄中也是沒有這個so文件的,所以加載時找不到文件了。

解決辦法:就是在使用so文件的時候,需要確定在每個架構類型目錄中都要有相同的so文件即可。

 

第二個問題:32-bit instead of 64-bit

\

這個問題的原因主要是因為64位的Zygote進程創建的虛擬機中加載了32位的so文件,這個問題的產生原因主要有兩個:

第一個是我們把不同架構類型的so文件放錯目錄了,比如armeabi/armeabi-v7a的so文件放到了arm64-v8a中了

第二個是我們在開發插件的過程中,宿主工程中有arm64-v8a目錄,但是插件中加載so卻是armeabi/armeabi-v7a類型的

第一個原因就不多說了,主要是因為so放錯目錄了,來看一下第二個原因,我們在開發插件的時候有時候需要在插件中去加載so文件,一般都是使用System.load方式去加載全路徑的so文件,那麼這裡就可能存在一個問題,比如宿主工程中,放了所有架構的目錄,包括了64位的,因為考慮插件的大小,所以在插件中只放了armeabi-v7a目錄的so文件,如果設備是64位的系統,那麼這時候插件加載so文件就會報錯。原因就在於上面分析的so兼容問題中說到了,因為宿主工程中包含了64位的架構arm64-v8a類型,系統的abiList中也有arm64-v8a類型,所以這時候應用的ApplicationInfo的abi就是arm64-v8a了,那麼就會發送消息給Zygote64的進程,創建的也是64位的虛擬機了,而最後插件中加載so的類型是32位的armeabi-v7a,那麼就會報錯了,因為32位的so文件不能運行在64位的虛擬機中的。

解決辦法:宿主工程和插件工程中的so文件的架構類型保持一致,這個將會帶來一個很大的問題,就是插件包會變得很大,因為宿主工程為了兼容多數機型,加入了多個類型的架構so文件,但是插件為了減小包大小,就放了指定類型的so文件,但是最終會存在這種問題,所以這個解決辦法就要看項目需要了。

 

還有一個類似的問題:64-bit instead of 32-bit:

\

原理都是一樣的,32位的虛擬機中加載了64位的so文件問題導致的。

 

第三個問題:Shared library already opened

\

這個問題在上面介紹so加載流程中已經介紹過了,原因主要是因為之前使用DexClassLoader加載so之後,so沒有釋放還在內存中,而在此啟動有弄了一個新的DexClassLoader對象去加載so問題,就出錯了。

我們使用DexClassLoader類去加載插件,但是因為我們為了插件能夠實時更新,所以每次都會賦值新的DexClassLoader對象,但是第一次加載so文件到內存中了,這時候退出程序,但是沒有真正意義上的退出,只是關閉了Activity了,這時候再次啟動又會賦值新的加載器對象,那麼原先so已經加載到內存中了,但是這時候是新的類加載器那麼就報錯了。

解決辦法:

 

第一種方式:在退出程序的時候采用真正意義上的退出,比如調用System.exit(0)方法,這時候進程被殺了,加載到內存的so也就被釋放了,那麼下次賦值新的類加載就在此加載so到內存了。

第二種方式:就是全局定義一個static類型的類加載DexClassLoader也是可以的,因為static類型是保存在當前進程中,如果進程沒有被殺就一直存在這個對象,下次進入程序的時候判斷當前類加載器是否為null,如果不為null就不要賦值了,但是這個方法有一個弊端就是類加載器沒有從新賦值,如果插件這時候更新了,但是還是使用之前的加載器,那麼新插件將不會進行加載。

 

十、技術概要

本文主要介紹了Android中關於so的相關知識,主要包括so編譯多架構問題,so加載流程問題,so釋放問題,so系統兼容問題以及插件中加載so文件的功能解析,看完本文之後,我們需要了解到的知識點:

1、在NDK開發時,可以指定多種架構類型編譯出多種類型的so文件。

2、so的加載流程主要是System類中的兩個加載方法,最終都會調用Runtime中的nativeLoad的native方法,而這個native方法最終會調用dlopen來打開so文件,然後在調用dlsym方法調用so的JNI_OnLoad方法。

3、關於apk文件在安裝的時候釋放so文件到本地目錄中,主要是結合當前設備的abiList信息(這個信息主要是通過系統屬性:ro.product.cpu.abilist值來獲取的)和apk中不同類型架構,來決定最終釋放哪個類型目錄中的so文件,釋放完成之後,還需要設置應用的nativeLib路徑,以及應用的abi信息,因為這個abi信息在後面啟動虛擬機的時候需要用到。

4、因為現在有很多設備已經是64位系統了,但是為了兼容32位的so文件,所以這些64位系統就會在系統啟動的時候創建兩個Zygote進程,一個是64位的,一個是32位的,當一個應用啟動的時候,需要創建虛擬機,那麼這時候就會把應用的架構類型傳遞過去,系統會根據這個類型來交給哪個Zygote進程來處理這個應用啟動事件。這樣就可以做到so調用的兼容問題了。

5、插件中加載so文件現階段主要有兩種方式,一種是先釋放插件中的so文件到本地目錄,然後設置DexClassLoader的nativeLib路徑;還有一種方式是先釋放插件中的so文件,然後調用System.load來加載全局路徑的so文件。

 

十一、問題總結

本文還總結了在使用so文件的時候,會遇到的一些問題,主要是三個問題:

1、so文件找不到問題

這個問題一般是因為我們忘記放了so文件,或者是so文件沒有放置全部,也就是沒有在libs目錄中所有的架構類型目錄中放置。

2、不同位數的虛擬機運行了不同位數的so文件

這個問題一般是因為我們在libs目錄中把so文件放錯目錄了,或者是宿主工程和插件工程中的so文件架構類型目錄沒有保持一致。

3、類加載器加載so文件再次加載

這個問題一般是因為插件開發中使用了不同的DexClassLoader去加載多次相同的so文件導致的。

 

十二、知識延展

我們在開發的過程中有時候想知道系統的位數,那麼這裡網上告知說有好幾種方法,其實那些都是忽悠人的,特別是在使用這個api的時候:android.os.Build.CPU_ABI,我就是在項目中被這個方法坑爹了,這個方法其實不是獲取系統的位數,而是獲取當前應用的架構類型位數,就是我們前面分析的ApplicationInfo中的abi信息,我們可以查看一下源碼:

\

這裡可以看到,這個字段已經被廢棄了,因為他不靠譜呀,這個字段在Build類的static塊中進行賦值的:

\

這裡會通過VMRuntime類的is64Bit方法來判斷當前虛擬機的位數,來獲取這個值

\

這裡還有兩個系統屬性:

ro.product.cpu.abilist32是32位的所有arch架構類型

ro.product.cpu.abilist64是64位的所有arch架構類型

而這兩個字段值的合集就是前面的ro.product.cpu.abilist屬性值。

\

而VMRuntime的is64Bit方法是native方法,實現如下:

\

看到了,這裡得到的是虛擬機的位數,那麼就是上面的Zygote進程的位數了。那麼問題就來了,假如我的設備是64位的,但是我的項目中沒有arm64-v8a類型的so文件,這時候在解析apk進行釋放so文件的時候,就會得知架構類型是armeabi/armeabi-v7a了,因為遍歷apk文件,沒有找到arm64-v8a類型的so文件,這時候應用的abi類型就是armeabi/armeabi-v7a了,這就是32位的了,就會通知32位的Zygote進程創建了一個32位的虛擬機,那麼此時我的項目中通過Build.CPU_ABI得到的系統位數就是32了,那麼完全不是我們想要的了。

 

所以正確的獲取系統位數的方法是:

Android5.0系統之後,可以通過ro.product.cpu.abilist屬性字段值來判斷,如果這個字段值中包含了64的話,那麼就是64位系統了

Android5.0系統之前,需要通過ro.product.cpu.abi屬性字段值來判斷,不過5.0系統之前都是32位的,還沒有出現64位呢。

 

十三、選擇適當架構類型減小包大小

我們上面分析之後可以看到,如果想做到萬無一失即,項目不報錯,而且so運行效率也是非常高的話,就需要把那幾個架構類型的so文件都要在項目中放一遍,那麼這個問題就來了,如果so文件較大的話,apk包最終也是很大的,所以這裡就需要做一次選擇了。

1、我們在開發一個項目的時候因為,整個項目的so文件結構我們可以控制,所以為了防止apk包增大,我們可以考慮只放幾個架構類型的so文件,比如最好的是放armeabi類型的,因為首先現在大部分設備采用cpu型號都是arm的,少數采用x86或者是mips類型的,其次是防止了armeabi類型之後,對於armeabi-v7a和arm64-v8a就可以兼容了,不會存在報錯問題。但是因為系統需要兼容所以就會出現so運行效率的問題了,最好的效率就是指定架構類型的so運行在對應架構類型的設備中。因為現在大部分的設備系統版本都是4.0以上了,所以armeabi-v7a架構類型用的比較多了,所以有時候為了效率問題,項目中只放了這個架構類型的so文件,那麼像老版本的手機armeabi的話就會報錯了,當然這個錯誤是可以接受的即可。

2、有時候像x86和mips等少數類型架構的設備,開發程序的時候會單獨出一個版本比如叫做xxx應用x86版本

3、在開發SDK的時候,因為開發之後的SDK包是給其他app接入的,而對於接入的app,我們不能做太多的限制,所以理論上應該把所有架構類型的so都要提供,這樣給需要接入的app進行選擇即可,比如像百度地圖SDK:

\

 

 

十四、總結

本文主要是介紹了Android中關於so的相關知識,而這些知識點都是在使用so文件中會經常用到的,同時一些問題也是我們會遇到的,這裡只是做了一個總結,同時也給出了插件中加載so文件的方案已經遇到的問題解決思路等內容。

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved