android .so文件详解以及兼容性
生活随笔
收集整理的這篇文章主要介紹了
android .so文件详解以及兼容性
小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
Android 設(shè)備的CPU類型通常稱為ABIs
問題描述
解決方法
1解決之前的截圖
2解決后的截圖
3解決方法
4建議
為什么你需要重點(diǎn)關(guān)注so文件
App中可能出錯(cuò)的地方
其他地方也可能出錯(cuò)
使用android-21平臺(tái)版本編譯的so文件運(yùn)行在android-15的設(shè)備上
混合使用不同C運(yùn)行時(shí)編譯的so文件
沒有為每個(gè)支持的CPU架構(gòu)提供對(duì)應(yīng)的so文件
將so文件放在錯(cuò)誤的地方
只提供armeabi架構(gòu)的so文件而忽略其他ABIs的
更多參考
Android 設(shè)備的CPU類型(通常稱為”ABIs”)
armeabiv-v7a: 第7代及以上的 ARM 處理器。2011年15月以后的生產(chǎn)的大部分Android設(shè)備都使用它.
arm64-v8a: 第8代、64位ARM處理器,很少設(shè)備,三星 Galaxy S6是其中之一。
armeabi: 第5代、第6代的ARM處理器,早期的手機(jī)用的比較多。
x86: 平板、模擬器用得比較多。
x86_64: 64位的平板。
問題描述
今天測(cè)試人員測(cè)試集成版本時(shí)除了一個(gè)bug:關(guān)于華為 Mate 8手機(jī)Android 6.0系統(tǒng)運(yùn)行剛剛提測(cè)的版本時(shí),出現(xiàn)閃退的bug,而小米 4 手機(jī)Android 6.0系統(tǒng)卻沒有出現(xiàn)任何bug,運(yùn)行良好。后來查看本人相關(guān)模塊的代碼,發(fā)現(xiàn)本人集成版本相關(guān)模塊的代碼和分支版本相關(guān)模塊的代碼是一模一樣的,那就是說本人把分支代碼合并到主干代碼是沒有問題的,所以去查看主干代碼的問題。
經(jīng)過一番查看提交日志,發(fā)現(xiàn)有位同事再我合并代碼之前,提交了一個(gè)關(guān)于友盟推送的so文件的記錄,原來他加入了一個(gè)arm64-v8a文件夾,里面有友盟推送的arm64-v8a的so庫文件。而其他的so庫文本卻沒有arm64-v8a對(duì)應(yīng)的版本。
通過百度查到知乎有一段關(guān)于arm64-v8a的解釋:
arm64-v8a是可以向下兼容的,但前提是你的項(xiàng)目里面沒有arm64-v8a的文件夾,如果你有兩個(gè)文件夾armeabi和arm64-v8a,兩個(gè)文件夾,armeabi里面有a.so 和 b.so,arm64-v8a里面只有a.so,那么arm64-v8a的手機(jī)在用到b的時(shí)候發(fā)現(xiàn)有arm64-v8a的文件夾,發(fā)現(xiàn)里面沒有b.so,就報(bào)錯(cuò)了,所以這個(gè)時(shí)候刪掉arm64-v8a文件夾,這個(gè)時(shí)候手機(jī)發(fā)現(xiàn)沒有適配arm64-v8a,就會(huì)直接去找armeabi的so庫,所以要么你別加arm64-v8a,要么armeabi里面有的so庫,arm64-v8a里面也必須有
作者:green jim
鏈接:http://www.zhihu.com/question/36893314/answer/78467097
來源:知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán),非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
發(fā)現(xiàn)原來華為 Mate 8手機(jī)是64位的操作系統(tǒng),而小米 4 手機(jī)是32位的操作系統(tǒng),所以小米 4 手機(jī)手機(jī)運(yùn)行APP沒bug,而華為 Mate 8手機(jī)運(yùn)行APP出現(xiàn)閃退bug。
解決方法
1、解決之前的截圖:
這里寫圖片描述
從截圖可以看出來,第一個(gè)項(xiàng)目中有 arm64-v8a,而沒有x86目錄,第二個(gè)項(xiàng)目中沒有 arm64-v8a,而有x86目錄。第一個(gè)項(xiàng)目是作為項(xiàng)目引用導(dǎo)入到第二個(gè)項(xiàng)目中的。
2、解決后的截圖:
這里寫圖片描述
從截圖可以看出來,第一個(gè)項(xiàng)目中和第二個(gè)項(xiàng)目中沒有的libs目錄下,都是armeabi-v7a、armeabi、x86三個(gè)目錄,保持一致。第一個(gè)項(xiàng)目是作為項(xiàng)目引用導(dǎo)入到第二個(gè)項(xiàng)目中的。
3、解決方法:
解決方法是:從友盟官方中去下載x86的相關(guān)so文件,放在x86目錄下,把a(bǔ)rm64-v8a目錄刪除。將所有關(guān)于so文件的都要保持一致,即:如果你要添加一個(gè)armeabi-v8a目錄,下面放第三方的armeabi-v8a相關(guān)的so文件,那么你其他的so文件都要有相應(yīng)想armeabi-v8a版本,不然就會(huì)報(bào)錯(cuò)。
4、建議
來自于博客:《與 .so 有關(guān)的一個(gè)長(zhǎng)年大坑 》給的建議是:
為了減小 apk 體積,只保留 armeabi 和 armeabi-v7a 兩個(gè)文件夾,并保證這兩個(gè)文件夾中 .so 數(shù)量一致
對(duì)只提供 armeabi 版本的第三方 .so,原樣復(fù)制一份到 armeabi-v7a 文件夾
下面文章轉(zhuǎn)載于asce1885(簡(jiǎn)書作者):關(guān)于Android的.so文件你所需要知道的
(原文鏈接:http://www.jianshu.com/p/cb05698a1968)
著作權(quán)歸作者所有,轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán),并標(biāo)注“簡(jiǎn)書作者”。
早期的Android系統(tǒng)幾乎只支持ARMv5的CPU架構(gòu),你知道現(xiàn)在它支持多少種嗎?7種!
Android系統(tǒng)目前支持以下七種不同的CPU架構(gòu):ARMv5,ARMv7 (從2010年起),x86 (從2011年起),MIPS (從2012年起),ARMv8,MIPS64和x86_64 (從2014年起),每一種都關(guān)聯(lián)著一個(gè)相應(yīng)的ABI。
應(yīng)用程序二進(jìn)制接口(Application Binary Interface)定義了二進(jìn)制文件(尤其是.so文件)如何運(yùn)行在相應(yīng)的系統(tǒng)平臺(tái)上,從使用的指令集,內(nèi)存對(duì)齊到可用的系統(tǒng)函數(shù)庫。在Android系統(tǒng)上,每一個(gè)CPU架構(gòu)對(duì)應(yīng)一個(gè)ABI:armeabi,armeabi-v7a,x86,mips,arm64-v8a,mips64,x86_64。
為什么你需要重點(diǎn)關(guān)注.so文件
如果項(xiàng)目中使用到了NDK,它將會(huì)生成.so文件,因此顯然你已經(jīng)在關(guān)注它了。如果只是使用Java語言進(jìn)行編碼,你可能在想不需要關(guān)注.so文件了吧,因?yàn)镴ava是跨平臺(tái)的。但事實(shí)上,即使你在項(xiàng)目中只是使用Java語言,很多情況下,你可能并沒有意識(shí)到項(xiàng)目中依賴的函數(shù)庫或者引擎庫里面已經(jīng)嵌入了.so文件,并依賴于不同的ABI。
例如,項(xiàng)目中使用RenderScript支持庫,OpenCV,Unity,android-gif-drawable,SQLCipher等,你都已經(jīng)在生成的APK文件中包含.so文件了,而你需要關(guān)注.so文件。
Android應(yīng)用支持的ABI取決于APK中位于lib/ABI目錄中的.so文件,其中ABI可能是上面說過的七種ABI中的一種。
這里寫圖片描述
Native Libs Monitor這個(gè)應(yīng)用可以幫助我們理解手機(jī)上安裝的APK用到了哪些.so文件,以及.so文件來源于哪些函數(shù)庫或者框架。
當(dāng)然,我們也可以自己對(duì)app反編譯來獲取這些信息,不過相對(duì)麻煩一些。
很多設(shè)備都支持多于一種的ABI。例如ARM64和x86設(shè)備也可以同時(shí)運(yùn)行armeabi-v7a和armeabi的二進(jìn)制包。但最好是針對(duì)特定平臺(tái)提供相應(yīng)平臺(tái)的二進(jìn)制包,這種情況下運(yùn)行時(shí)就少了一個(gè)模擬層(例如x86設(shè)備上模擬arm的虛擬層),從而得到更好的性能(歸功于最近的架構(gòu)更新,例如硬件fpu,更多的寄存器,更好的向量化等)。
我們可以通過Build.SUPPORTED_ABIS得到根據(jù)偏好排序的設(shè)備支持的ABI列表。但你不應(yīng)該從你的應(yīng)用程序中讀取它,因?yàn)锳ndroid包管理器安裝APK時(shí),會(huì)自動(dòng)選擇APK包中為對(duì)應(yīng)系統(tǒng)ABI預(yù)編譯好的.so文件,如果在對(duì)應(yīng)的lib/ABI目錄中存在.so文件的話。
App中可能出錯(cuò)的地方
處理.so文件時(shí)有一條簡(jiǎn)單卻并不知名的重要法則。
你應(yīng)該盡可能的提供專為每個(gè)ABI優(yōu)化過的.so文件,但要么全部支持,要么都不支持:你不應(yīng)該混合著使用。你應(yīng)該為每個(gè)ABI目錄提供對(duì)應(yīng)的.so文件。
當(dāng)一個(gè)應(yīng)用安裝在設(shè)備上,只有該設(shè)備支持的CPU架構(gòu)對(duì)應(yīng)的.so文件會(huì)被安裝。在x86設(shè)備上,libs/x86目錄中如果存在.so文件的話,會(huì)被安裝,如果不存在,則會(huì)選擇armeabi-v7a中的.so文件,如果也不存在,則選擇armeabi目錄中的.so文件(因?yàn)閤86設(shè)備也支持armeabi-v7a和armeabi)。
其他地方也可能出錯(cuò)
當(dāng)你引入一個(gè).so文件時(shí),不止影響到CPU架構(gòu)。我從其他開發(fā)者那里可以看到一系列常見的錯(cuò)誤,其中最多的是”UnsatisfiedLinkError”,”dlopen: failed”以及其他類型的crash或者低下的性能:
使用android-21平臺(tái)版本編譯的.so文件運(yùn)行在android-15的設(shè)備上
使用NDK時(shí),你可能會(huì)傾向于使用最新的編譯平臺(tái),但事實(shí)上這是錯(cuò)誤的,因?yàn)镹DK平臺(tái)不是后向兼容的,而是前向兼容的。推薦使用app的minSdkVersion對(duì)應(yīng)的編譯平臺(tái)。
這也意味著當(dāng)你引入一個(gè)預(yù)編譯好的.so文件時(shí),你需要檢查它被編譯所用的平臺(tái)版本。
混合使用不同C++運(yùn)行時(shí)編譯的.so文件
.so文件可以依賴于不同的C++運(yùn)行時(shí),靜態(tài)編譯或者動(dòng)態(tài)加載。混合使用不同版本的C++運(yùn)行時(shí)可能導(dǎo)致很多奇怪的crash,是應(yīng)該避免的。作為一個(gè)經(jīng)驗(yàn)法則,當(dāng)只有一個(gè).so文件時(shí),靜態(tài)編譯C++運(yùn)行時(shí)是沒問題的,否則當(dāng)存在多個(gè).so文件時(shí),應(yīng)該讓所有的.so文件都動(dòng)態(tài)鏈接相同的C++運(yùn)行時(shí)。
這意味著當(dāng)引入一個(gè)新的預(yù)編譯.so文件,而且項(xiàng)目中還存在其他的.so文件時(shí),我們需要首先確認(rèn)新引入的.so文件使用的C++運(yùn)行時(shí)是否和已經(jīng)存在的.so文件一致。
沒有為每個(gè)支持的CPU架構(gòu)提供對(duì)應(yīng)的.so文件
這一點(diǎn)在前文已經(jīng)說到了,但你應(yīng)該真的特別注意它,因?yàn)樗赡馨l(fā)生在根本沒有意識(shí)到的情況下。
例如:你的app支持armeabi-v7a和x86架構(gòu),然后使用Android Studio新增了一個(gè)函數(shù)庫依賴,這個(gè)函數(shù)庫包含.so文件并支持更多的CPU架構(gòu),例如新增android-gif-drawable函數(shù)庫:
compile ‘pl.droidsonroids.gif:android-gif-drawable:1.1.+’
1
1
發(fā)布我們的app后,會(huì)發(fā)現(xiàn)它在某些設(shè)備上會(huì)發(fā)生Crash,例如Galaxy S6,最終可以發(fā)現(xiàn)只有64位目錄下的.so文件被安裝進(jìn)手機(jī)。
解決方案:重新編譯我們的.so文件使其支持缺失的ABIs,或者設(shè)置
ndk.abiFilters
1
1
顯示指定支持的ABIs。
最后一點(diǎn):如果你是一個(gè)SDK提供者,但提供的函數(shù)庫不支持所有的ABIs,那你將會(huì)搞砸你的用戶,因?yàn)樗麄兡苤С值腁BIs必將只能少于你提供的。
將.so文件放在錯(cuò)誤的地方
我們往往很容易對(duì).so文件應(yīng)該放在或者生成到哪里感到困惑,下面是一個(gè)總結(jié):
Android Studio工程放在jniLibs/ABI目錄中(當(dāng)然也可以通過在build.gradle文件中的設(shè)置jniLibs.srcDir屬性自己指定)
Eclipse工程放在libs/ABI目錄中(這也是ndk-build命令默認(rèn)生成.so文件的目錄)
AAR壓縮包中位于jni/ABI目錄中(.so文件會(huì)自動(dòng)包含到引用AAR壓縮包的APK中)
最終APK文件中的lib/ABI目錄中
通過PackageManager安裝后,在小于Android 5.0的系統(tǒng)中,.so文件位于app的nativeLibraryPath目錄中;在大于等于Android 5.0的系統(tǒng)中,.so文件位于app的nativeLibraryRootDir/CPU_ARCH目錄中。
只提供armeabi架構(gòu)的.so文件而忽略其他ABIs的
所有的x86/x86_64/armeabi-v7a/arm64-v8a設(shè)備都支持armeabi架構(gòu)的.so文件,因此似乎移除其他ABIs的.so文件是一個(gè)減少APK大小的好技巧。但事實(shí)上并不是:這不只影響到函數(shù)庫的性能和兼容性。
x86設(shè)備能夠很好的運(yùn)行ARM類型函數(shù)庫,但并不保證100%不發(fā)生crash,特別是對(duì)舊設(shè)備。64位設(shè)備(arm64-v8a, x86_64, mips64)能夠運(yùn)行32位的函數(shù)庫,但是以32位模式運(yùn)行,在64位平臺(tái)上運(yùn)行32位版本的ART和Android組件,將丟失專為64位優(yōu)化過的性能(ART,webview,media等等)。
以減少APK包大小為由是一個(gè)錯(cuò)誤的借口,因?yàn)槟阋部梢赃x擇在應(yīng)用市場(chǎng)上傳指定ABI版本的APK,生成不同ABI版本的APK可以在build.gradle中如下配置:
android {
??? ...
??? splits {
??????? abi {
??????????? enable true
??????????? reset()
??????????? include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //select ABIs to build APKs for
??????????? universalApk true //generate an additional APK that contains all the ABIs
??????? }
??? }
??? // map for the version code
??? project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9]
??? android.applicationVariants.all { variant ->
??????? // assign different version code for each output
??????? variant.outputs.each { output ->
??????????? output.versionCodeOverride =
??????????????????? project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode
??????? }
??? }
?}
問題描述
解決方法
1解決之前的截圖
2解決后的截圖
3解決方法
4建議
為什么你需要重點(diǎn)關(guān)注so文件
App中可能出錯(cuò)的地方
其他地方也可能出錯(cuò)
使用android-21平臺(tái)版本編譯的so文件運(yùn)行在android-15的設(shè)備上
混合使用不同C運(yùn)行時(shí)編譯的so文件
沒有為每個(gè)支持的CPU架構(gòu)提供對(duì)應(yīng)的so文件
將so文件放在錯(cuò)誤的地方
只提供armeabi架構(gòu)的so文件而忽略其他ABIs的
更多參考
Android 設(shè)備的CPU類型(通常稱為”ABIs”)
armeabiv-v7a: 第7代及以上的 ARM 處理器。2011年15月以后的生產(chǎn)的大部分Android設(shè)備都使用它.
arm64-v8a: 第8代、64位ARM處理器,很少設(shè)備,三星 Galaxy S6是其中之一。
armeabi: 第5代、第6代的ARM處理器,早期的手機(jī)用的比較多。
x86: 平板、模擬器用得比較多。
x86_64: 64位的平板。
問題描述
今天測(cè)試人員測(cè)試集成版本時(shí)除了一個(gè)bug:關(guān)于華為 Mate 8手機(jī)Android 6.0系統(tǒng)運(yùn)行剛剛提測(cè)的版本時(shí),出現(xiàn)閃退的bug,而小米 4 手機(jī)Android 6.0系統(tǒng)卻沒有出現(xiàn)任何bug,運(yùn)行良好。后來查看本人相關(guān)模塊的代碼,發(fā)現(xiàn)本人集成版本相關(guān)模塊的代碼和分支版本相關(guān)模塊的代碼是一模一樣的,那就是說本人把分支代碼合并到主干代碼是沒有問題的,所以去查看主干代碼的問題。
經(jīng)過一番查看提交日志,發(fā)現(xiàn)有位同事再我合并代碼之前,提交了一個(gè)關(guān)于友盟推送的so文件的記錄,原來他加入了一個(gè)arm64-v8a文件夾,里面有友盟推送的arm64-v8a的so庫文件。而其他的so庫文本卻沒有arm64-v8a對(duì)應(yīng)的版本。
通過百度查到知乎有一段關(guān)于arm64-v8a的解釋:
arm64-v8a是可以向下兼容的,但前提是你的項(xiàng)目里面沒有arm64-v8a的文件夾,如果你有兩個(gè)文件夾armeabi和arm64-v8a,兩個(gè)文件夾,armeabi里面有a.so 和 b.so,arm64-v8a里面只有a.so,那么arm64-v8a的手機(jī)在用到b的時(shí)候發(fā)現(xiàn)有arm64-v8a的文件夾,發(fā)現(xiàn)里面沒有b.so,就報(bào)錯(cuò)了,所以這個(gè)時(shí)候刪掉arm64-v8a文件夾,這個(gè)時(shí)候手機(jī)發(fā)現(xiàn)沒有適配arm64-v8a,就會(huì)直接去找armeabi的so庫,所以要么你別加arm64-v8a,要么armeabi里面有的so庫,arm64-v8a里面也必須有
作者:green jim
鏈接:http://www.zhihu.com/question/36893314/answer/78467097
來源:知乎
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán),非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。
發(fā)現(xiàn)原來華為 Mate 8手機(jī)是64位的操作系統(tǒng),而小米 4 手機(jī)是32位的操作系統(tǒng),所以小米 4 手機(jī)手機(jī)運(yùn)行APP沒bug,而華為 Mate 8手機(jī)運(yùn)行APP出現(xiàn)閃退bug。
解決方法
1、解決之前的截圖:
這里寫圖片描述
從截圖可以看出來,第一個(gè)項(xiàng)目中有 arm64-v8a,而沒有x86目錄,第二個(gè)項(xiàng)目中沒有 arm64-v8a,而有x86目錄。第一個(gè)項(xiàng)目是作為項(xiàng)目引用導(dǎo)入到第二個(gè)項(xiàng)目中的。
2、解決后的截圖:
這里寫圖片描述
從截圖可以看出來,第一個(gè)項(xiàng)目中和第二個(gè)項(xiàng)目中沒有的libs目錄下,都是armeabi-v7a、armeabi、x86三個(gè)目錄,保持一致。第一個(gè)項(xiàng)目是作為項(xiàng)目引用導(dǎo)入到第二個(gè)項(xiàng)目中的。
3、解決方法:
解決方法是:從友盟官方中去下載x86的相關(guān)so文件,放在x86目錄下,把a(bǔ)rm64-v8a目錄刪除。將所有關(guān)于so文件的都要保持一致,即:如果你要添加一個(gè)armeabi-v8a目錄,下面放第三方的armeabi-v8a相關(guān)的so文件,那么你其他的so文件都要有相應(yīng)想armeabi-v8a版本,不然就會(huì)報(bào)錯(cuò)。
4、建議
來自于博客:《與 .so 有關(guān)的一個(gè)長(zhǎng)年大坑 》給的建議是:
為了減小 apk 體積,只保留 armeabi 和 armeabi-v7a 兩個(gè)文件夾,并保證這兩個(gè)文件夾中 .so 數(shù)量一致
對(duì)只提供 armeabi 版本的第三方 .so,原樣復(fù)制一份到 armeabi-v7a 文件夾
下面文章轉(zhuǎn)載于asce1885(簡(jiǎn)書作者):關(guān)于Android的.so文件你所需要知道的
(原文鏈接:http://www.jianshu.com/p/cb05698a1968)
著作權(quán)歸作者所有,轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán),并標(biāo)注“簡(jiǎn)書作者”。
早期的Android系統(tǒng)幾乎只支持ARMv5的CPU架構(gòu),你知道現(xiàn)在它支持多少種嗎?7種!
Android系統(tǒng)目前支持以下七種不同的CPU架構(gòu):ARMv5,ARMv7 (從2010年起),x86 (從2011年起),MIPS (從2012年起),ARMv8,MIPS64和x86_64 (從2014年起),每一種都關(guān)聯(lián)著一個(gè)相應(yīng)的ABI。
應(yīng)用程序二進(jìn)制接口(Application Binary Interface)定義了二進(jìn)制文件(尤其是.so文件)如何運(yùn)行在相應(yīng)的系統(tǒng)平臺(tái)上,從使用的指令集,內(nèi)存對(duì)齊到可用的系統(tǒng)函數(shù)庫。在Android系統(tǒng)上,每一個(gè)CPU架構(gòu)對(duì)應(yīng)一個(gè)ABI:armeabi,armeabi-v7a,x86,mips,arm64-v8a,mips64,x86_64。
為什么你需要重點(diǎn)關(guān)注.so文件
如果項(xiàng)目中使用到了NDK,它將會(huì)生成.so文件,因此顯然你已經(jīng)在關(guān)注它了。如果只是使用Java語言進(jìn)行編碼,你可能在想不需要關(guān)注.so文件了吧,因?yàn)镴ava是跨平臺(tái)的。但事實(shí)上,即使你在項(xiàng)目中只是使用Java語言,很多情況下,你可能并沒有意識(shí)到項(xiàng)目中依賴的函數(shù)庫或者引擎庫里面已經(jīng)嵌入了.so文件,并依賴于不同的ABI。
例如,項(xiàng)目中使用RenderScript支持庫,OpenCV,Unity,android-gif-drawable,SQLCipher等,你都已經(jīng)在生成的APK文件中包含.so文件了,而你需要關(guān)注.so文件。
Android應(yīng)用支持的ABI取決于APK中位于lib/ABI目錄中的.so文件,其中ABI可能是上面說過的七種ABI中的一種。
這里寫圖片描述
Native Libs Monitor這個(gè)應(yīng)用可以幫助我們理解手機(jī)上安裝的APK用到了哪些.so文件,以及.so文件來源于哪些函數(shù)庫或者框架。
當(dāng)然,我們也可以自己對(duì)app反編譯來獲取這些信息,不過相對(duì)麻煩一些。
很多設(shè)備都支持多于一種的ABI。例如ARM64和x86設(shè)備也可以同時(shí)運(yùn)行armeabi-v7a和armeabi的二進(jìn)制包。但最好是針對(duì)特定平臺(tái)提供相應(yīng)平臺(tái)的二進(jìn)制包,這種情況下運(yùn)行時(shí)就少了一個(gè)模擬層(例如x86設(shè)備上模擬arm的虛擬層),從而得到更好的性能(歸功于最近的架構(gòu)更新,例如硬件fpu,更多的寄存器,更好的向量化等)。
我們可以通過Build.SUPPORTED_ABIS得到根據(jù)偏好排序的設(shè)備支持的ABI列表。但你不應(yīng)該從你的應(yīng)用程序中讀取它,因?yàn)锳ndroid包管理器安裝APK時(shí),會(huì)自動(dòng)選擇APK包中為對(duì)應(yīng)系統(tǒng)ABI預(yù)編譯好的.so文件,如果在對(duì)應(yīng)的lib/ABI目錄中存在.so文件的話。
App中可能出錯(cuò)的地方
處理.so文件時(shí)有一條簡(jiǎn)單卻并不知名的重要法則。
你應(yīng)該盡可能的提供專為每個(gè)ABI優(yōu)化過的.so文件,但要么全部支持,要么都不支持:你不應(yīng)該混合著使用。你應(yīng)該為每個(gè)ABI目錄提供對(duì)應(yīng)的.so文件。
當(dāng)一個(gè)應(yīng)用安裝在設(shè)備上,只有該設(shè)備支持的CPU架構(gòu)對(duì)應(yīng)的.so文件會(huì)被安裝。在x86設(shè)備上,libs/x86目錄中如果存在.so文件的話,會(huì)被安裝,如果不存在,則會(huì)選擇armeabi-v7a中的.so文件,如果也不存在,則選擇armeabi目錄中的.so文件(因?yàn)閤86設(shè)備也支持armeabi-v7a和armeabi)。
其他地方也可能出錯(cuò)
當(dāng)你引入一個(gè).so文件時(shí),不止影響到CPU架構(gòu)。我從其他開發(fā)者那里可以看到一系列常見的錯(cuò)誤,其中最多的是”UnsatisfiedLinkError”,”dlopen: failed”以及其他類型的crash或者低下的性能:
使用android-21平臺(tái)版本編譯的.so文件運(yùn)行在android-15的設(shè)備上
使用NDK時(shí),你可能會(huì)傾向于使用最新的編譯平臺(tái),但事實(shí)上這是錯(cuò)誤的,因?yàn)镹DK平臺(tái)不是后向兼容的,而是前向兼容的。推薦使用app的minSdkVersion對(duì)應(yīng)的編譯平臺(tái)。
這也意味著當(dāng)你引入一個(gè)預(yù)編譯好的.so文件時(shí),你需要檢查它被編譯所用的平臺(tái)版本。
混合使用不同C++運(yùn)行時(shí)編譯的.so文件
.so文件可以依賴于不同的C++運(yùn)行時(shí),靜態(tài)編譯或者動(dòng)態(tài)加載。混合使用不同版本的C++運(yùn)行時(shí)可能導(dǎo)致很多奇怪的crash,是應(yīng)該避免的。作為一個(gè)經(jīng)驗(yàn)法則,當(dāng)只有一個(gè).so文件時(shí),靜態(tài)編譯C++運(yùn)行時(shí)是沒問題的,否則當(dāng)存在多個(gè).so文件時(shí),應(yīng)該讓所有的.so文件都動(dòng)態(tài)鏈接相同的C++運(yùn)行時(shí)。
這意味著當(dāng)引入一個(gè)新的預(yù)編譯.so文件,而且項(xiàng)目中還存在其他的.so文件時(shí),我們需要首先確認(rèn)新引入的.so文件使用的C++運(yùn)行時(shí)是否和已經(jīng)存在的.so文件一致。
沒有為每個(gè)支持的CPU架構(gòu)提供對(duì)應(yīng)的.so文件
這一點(diǎn)在前文已經(jīng)說到了,但你應(yīng)該真的特別注意它,因?yàn)樗赡馨l(fā)生在根本沒有意識(shí)到的情況下。
例如:你的app支持armeabi-v7a和x86架構(gòu),然后使用Android Studio新增了一個(gè)函數(shù)庫依賴,這個(gè)函數(shù)庫包含.so文件并支持更多的CPU架構(gòu),例如新增android-gif-drawable函數(shù)庫:
compile ‘pl.droidsonroids.gif:android-gif-drawable:1.1.+’
1
1
發(fā)布我們的app后,會(huì)發(fā)現(xiàn)它在某些設(shè)備上會(huì)發(fā)生Crash,例如Galaxy S6,最終可以發(fā)現(xiàn)只有64位目錄下的.so文件被安裝進(jìn)手機(jī)。
解決方案:重新編譯我們的.so文件使其支持缺失的ABIs,或者設(shè)置
ndk.abiFilters
1
1
顯示指定支持的ABIs。
最后一點(diǎn):如果你是一個(gè)SDK提供者,但提供的函數(shù)庫不支持所有的ABIs,那你將會(huì)搞砸你的用戶,因?yàn)樗麄兡苤С值腁BIs必將只能少于你提供的。
將.so文件放在錯(cuò)誤的地方
我們往往很容易對(duì).so文件應(yīng)該放在或者生成到哪里感到困惑,下面是一個(gè)總結(jié):
Android Studio工程放在jniLibs/ABI目錄中(當(dāng)然也可以通過在build.gradle文件中的設(shè)置jniLibs.srcDir屬性自己指定)
Eclipse工程放在libs/ABI目錄中(這也是ndk-build命令默認(rèn)生成.so文件的目錄)
AAR壓縮包中位于jni/ABI目錄中(.so文件會(huì)自動(dòng)包含到引用AAR壓縮包的APK中)
最終APK文件中的lib/ABI目錄中
通過PackageManager安裝后,在小于Android 5.0的系統(tǒng)中,.so文件位于app的nativeLibraryPath目錄中;在大于等于Android 5.0的系統(tǒng)中,.so文件位于app的nativeLibraryRootDir/CPU_ARCH目錄中。
只提供armeabi架構(gòu)的.so文件而忽略其他ABIs的
所有的x86/x86_64/armeabi-v7a/arm64-v8a設(shè)備都支持armeabi架構(gòu)的.so文件,因此似乎移除其他ABIs的.so文件是一個(gè)減少APK大小的好技巧。但事實(shí)上并不是:這不只影響到函數(shù)庫的性能和兼容性。
x86設(shè)備能夠很好的運(yùn)行ARM類型函數(shù)庫,但并不保證100%不發(fā)生crash,特別是對(duì)舊設(shè)備。64位設(shè)備(arm64-v8a, x86_64, mips64)能夠運(yùn)行32位的函數(shù)庫,但是以32位模式運(yùn)行,在64位平臺(tái)上運(yùn)行32位版本的ART和Android組件,將丟失專為64位優(yōu)化過的性能(ART,webview,media等等)。
以減少APK包大小為由是一個(gè)錯(cuò)誤的借口,因?yàn)槟阋部梢赃x擇在應(yīng)用市場(chǎng)上傳指定ABI版本的APK,生成不同ABI版本的APK可以在build.gradle中如下配置:
android {
??? ...
??? splits {
??????? abi {
??????????? enable true
??????????? reset()
??????????? include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //select ABIs to build APKs for
??????????? universalApk true //generate an additional APK that contains all the ABIs
??????? }
??? }
??? // map for the version code
??? project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9]
??? android.applicationVariants.all { variant ->
??????? // assign different version code for each output
??????? variant.outputs.each { output ->
??????????? output.versionCodeOverride =
??????????????????? project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode
??????? }
??? }
?}
總結(jié)
以上是生活随笔為你收集整理的android .so文件详解以及兼容性的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Android .so .aar..ja
- 下一篇: iOS开发系列-线程同步dispatch