- Android 裝置的CPU類型通常稱為ABIs
- 問題描寫叙述
- 解決方法
- 1解決之前的截圖
- 2解決後的截圖
- 3解決方法
- 4建議
- 為什麼你須要重點關注so檔案
- App中可能出錯的地方
- 其它地方也可能出錯
- 使用android-21平台版本号編譯的so檔案執行在android-15的裝置上
- 混合使用不同C執行時編譯的so檔案
- 沒有為每一個支援的CPU架構提供相應的so檔案
- 将so檔案放在錯誤的地方
- 僅僅提供armeabi架構的so檔案而忽略其它ABIs的
- 很多其它參考
Android 裝置的CPU類型(通常稱為”ABIs”)
-
armeabiv-v7a: 第7代及以上的 ARM 處理器。
2011年15月以後的生産的大部分Android裝置都使用它.
- arm64-v8a: 第8代、64位ARM處理器,非常少裝置,三星 Galaxy S6是當中之中的一個。
- armeabi: 第5代、第6代的ARM處理器,早期的手機用的比較多。
- x86: 平闆、模拟器用得比較多。
- x86_64: 64位的平闆。
今天測試人員測試內建版本号時除了一個bug:關于華為 Mate 8手機Android 6.0系統執行剛剛提測的版本号時,出現閃退的bug。而小米 4 手機Android 6.0系統卻沒有出現不論什麼bug,執行良好。後來檢視本人相關子產品的代碼,發現本人內建版本号相關子產品的代碼和分支版本号相關子產品的代碼是一模一樣的。那就是說本人把分支代碼合并到主幹代碼是沒有問題的,是以去檢視主幹代碼的問題。
經過一番檢視送出日志。發現有位同僚再我合并代碼之前,送出了一個關于友盟推送的so檔案的記錄,原來他加入了一個arm64-v8a檔案夾,裡面有友盟推送的arm64-v8a的so庫檔案。而其它的so庫文本卻沒有arm64-v8a相應的版本号。
通過百度查到知乎有一段關于arm64-v8a的解釋:
arm64-v8a是能夠向下相容的,但前提是你的項目裡面沒有arm64-v8a的檔案夾,假設你有兩個檔案夾armeabi和arm64-v8a,兩個檔案夾,armeabi裡面有a.so 和 b.so,arm64-v8a裡面僅僅有a.so,那麼arm64-v8a的手機在用到b的時候發現有arm64-v8a的檔案夾,發現裡面沒有b.so。就報錯了。是以這個時候删掉arm64-v8a檔案夾,這個時候手機發現沒有适配arm64-v8a,就會直接去找armeabi的so庫,是以要麼你别加arm64-v8a,要麼armeabi裡面有的so庫,arm64-v8a裡面也必須有
作者:green jim
連結:http://www.zhihu.com/question/36893314/answer/78467097
來源:知乎
著作權歸作者全部。商業轉載請聯系作者獲得授權。非商業轉載請注明出處。
發現原來華為 Mate 8手機是64位的作業系統。而小米 4 手機是32位的作業系統,是以小米 4 手機手機執行APP沒bug,而華為 Mate 8手機執行APP出現閃退bug。
1、解決之前的截圖:
從截圖能夠看出來,第一個項目中有 arm64-v8a。而沒有x86檔案夾。第二個項目中沒有 arm64-v8a,而有x86檔案夾。第一個項目是作為項目引用導入到第二個項目中的。
2、解決後的截圖:
從截圖能夠看出來,第一個項目中和第二個項目中沒有的libs檔案夾下,都是armeabi-v7a、armeabi、x86三個檔案夾,保持一緻。
第一個項目是作為項目引用導入到第二個項目中的。
3、解決方法:
解決方法是:從友盟官方中去下載下傳x86的相關so檔案,放在x86檔案夾下,把arm64-v8a檔案夾删除。将全部關于so檔案的都要保持一緻,即:假設你要加入一個armeabi-v8a檔案夾,以下放第三方的armeabi-v8a相關的so檔案,那麼你其它的so檔案都要有相應想armeabi-v8a版本号,不然就會報錯。
4、建議
來自于部落格:《與 .so 有關的一個長年大坑 》給的建議是:
- 為了減小 apk 體積,僅僅保留 armeabi 和 armeabi-v7a 兩個檔案夾,并保證這兩個檔案夾中 .so 數量一緻
- 對僅僅提供 armeabi 版本号的第三方 .so,原樣複制一份到 armeabi-v7a 檔案夾
以下文章轉載于asce1885(簡書作者):關于Android的.so檔案你所須要知道的
(原文連結:http://www.jianshu.com/p/cb05698a1968)
著作權歸作者全部,轉載請聯系作者獲得授權。并标注“簡書作者”。
早期的Android系統差點兒僅僅支援ARMv5的CPU架構,你知道如今它支援多少種嗎?7種!
Android系統眼下支援以下七種不同的CPU架構:ARMv5,ARMv7 (從2010年起),x86 (從2011年起)。MIPS (從2012年起),ARMv8,MIPS64和x86_64 (從2014年起),每一種都關聯着一個相應的ABI。
應用程式二進制接口(Application Binary Interface)定義了二進制檔案(尤其是.so檔案)怎樣執行在相應的系統平台上,從使用的指令集,記憶體對齊到可用的系統函數庫。在Android系統上,每一個CPU架構相應一個ABI:armeabi,armeabi-v7a。x86。mips,arm64-v8a,mips64,x86_64。
為什麼你須要重點關注.so檔案
假設項目中使用到了NDK。它将會生成.so檔案,是以顯然你已經在關注它了。假設僅僅是使用Java語言進行編碼,你可能在想不須要關注.so檔案了吧。由于Java是跨平台的。
但其實,即使你在項目中僅僅是使用Java語言。非常多情況下,你可能并沒有意識到項目中依賴的函數庫或者引擎庫裡面已經嵌入了.so檔案,并依賴于不同的ABI。
比如,項目中使用RenderScript支援庫。OpenCV,Unity,android-gif-drawable。SQLCipher等。你都已經在生成的APK檔案裡包括.so檔案了,而你須要關注.so檔案。
Android應用支援的ABI取決于APK中位于lib/ABI檔案夾中的.so檔案,當中ABI可能是上面說過的七種ABI中的一種。
Native Libs Monitor這個應用能夠幫助我們了解手機上安裝的APK用到了哪些.so檔案。以及.so檔案來源于哪些函數庫或者架構。
當然。我們也能夠自己對app反編譯來擷取這些資訊,隻是相對麻煩一些。
非常多裝置都支援多于一種的ABI。
比如ARM64和x86裝置也能夠同一時候執行armeabi-v7a和armeabi的二進制包。但最好是針對特定平台提供相應平台的二進制包,這樣的情況下執行時就少了一個模拟層(比如x86裝置上模拟arm的虛拟層),進而得到更好的性能(歸功于近期的架構更新,比如硬體fpu,很多其它的寄存器。更好的向量化等)。
我們能夠通過Build.SUPPORTED_ABIS得到依據偏好排序的裝置支援的ABI清單。但你不應該從你的應用程式中讀取它,由于Android包管理器安裝APK時。會自己主動選擇APK包中為相應系統ABI預編譯好的.so檔案。假設在相應的lib/ABI檔案夾中存在.so檔案的話。
處理.so檔案時有一條簡單卻并不知名的重要法則。
你應該盡可能的提供專為每一個ABI優化過的.so檔案,但要麼全部支援,要麼都不支援:你不應該混合着使用。你應該為每一個ABI檔案夾提供相應的.so檔案。
當一個應用安裝在裝置上,僅僅有該裝置支援的CPU架構相應的.so檔案會被安裝。在x86裝置上,libs/x86檔案夾中假設存在.so檔案的話,會被安裝,假設不存在。則會選擇armeabi-v7a中的.so檔案,假設也不存在,則選擇armeabi檔案夾中的.so檔案(由于x86裝置也支援armeabi-v7a和armeabi)。
當你引入一個.so檔案時,不止影響到CPU架構。
我從其它開發人員那裡能夠看到一系列常見的錯誤,當中最多的是”UnsatisfiedLinkError”,”dlopen: failed”以及其它類型的crash或者低下的性能:
使用android-21平台版本号編譯的.so檔案執行在android-15的裝置上
使用NDK時。你可能會傾向于使用最新的編譯平台,但其實這是錯誤的,由于NDK平台不是後向相容的。而是前向相容的。
推薦使用app的minSdkVersion相應的編譯平台。
這也意味着當你引入一個預編譯好的.so檔案時,你須要檢查它被編譯所用的平台版本号。
混合使用不同C++執行時編譯的.so檔案
.so檔案能夠依賴于不同的C++執行時。靜态編譯或者動态載入。混合使用不同版本号的C++執行時可能導緻非常多奇怪的crash,是應該避免的。作為一個經驗法則,當僅僅有一個.so檔案時,靜态編譯C++執行時是沒問題的。否則當存在多個.so檔案時,應該讓全部的.so檔案都動态連結同樣的C++執行時。
這意味着當引入一個新的預編譯.so檔案,并且項目中還存在其它的.so檔案時。我們須要首先确認新引入的.so檔案使用的C++執行時是否和已經存在的.so檔案一緻。
沒有為每一個支援的CPU架構提供相應的.so檔案
這一點在前文已經說到了,但你應該真的特别注意它,由于它可能發生在根本沒有意識到的情況下。
比如:你的app支援armeabi-v7a和x86架構,然後使用Android Studio新增了一個函數庫依賴,這個函數庫包括.so檔案并支援很多其它的CPU架構,比如新增android-gif-drawable函數庫:
compile ‘pl.droidsonroids.gif:android-gif-drawable:1.1.+’
公布我們的app後,會發現它在某些裝置上會發生Crash。比如Galaxy S6,終于能夠發現僅僅有64位檔案夾下的.so檔案被安裝進手機。
解決方式:又一次編譯我們的.so檔案使其支援缺失的ABIs,或者設定
ndk.abiFilters
顯示指定支援的ABIs。
最後一點:假設你是一個SDK提供者,但提供的函數庫不支援全部的ABIs,那你将會搞砸你的使用者,由于他們能支援的ABIs必将僅僅能少于你提供的。
将.so檔案放在錯誤的地方
我們往往非常easy對.so檔案應該放在或者生成到哪裡感到困惑,以下是一個總結:
- Android Studio工程放在jniLibs/ABI檔案夾中(當然也能夠通過在build.gradle檔案裡的設定jniLibs.srcDir屬性自己指定)
- Eclipse工程放在libs/ABI檔案夾中(這也是ndk-build指令預設生成.so檔案的檔案夾)
- AAR壓縮包中位于jni/ABI檔案夾中(.so檔案會自己主動包括到引用AAR壓縮包的APK中)
- 終于APK檔案裡的lib/ABI檔案夾中
- 通過PackageManager安裝後,在小于Android 5.0的系統中,.so檔案位于app的nativeLibraryPath檔案夾中;在大于等于Android 5.0的系統中。.so檔案位于app的nativeLibraryRootDir/CPU_ARCH檔案夾中。
僅僅提供armeabi架構的.so檔案而忽略其它ABIs的
全部的x86/x86_64/armeabi-v7a/arm64-v8a裝置都支援armeabi架構的.so檔案。是以似乎移除其它ABIs的.so檔案是一個降低APK大小的好技巧。但其實并非:這不僅僅影響到函數庫的性能和相容性。
x86裝置能夠非常好的執行ARM類型函數庫。但并不保證100%不發生crash。特别是對舊裝置。64位裝置(arm64-v8a, x86_64, mips64)能夠執行32位的函數庫。可是以32位模式執行,在64位平台上執行32位版本号的ART和Android元件。将丢失專為64位優化過的性能(ART,webview,media等等)。
以降低APK包大小為由是一個錯誤的借口,由于你也能夠選擇在應用市場上傳指定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
}
}
}
-
安卓so庫你應該注意的事
(http://www.voidcn.com/blog/u013278099/article/p-4944290.html)
-
Android開發,不可不知的so檔案知識大全
http://alphayang.community/2015/11/27/so-files-guide/
-
與 .so 有關的一個長年大坑
https://zhuanlan.zhihu.com/p/21359984
-
Android jniLibs下檔案夾具體解釋(.so檔案)
http://www.jianshu.com/p/b758e36ae9b5
-
ARM核心全解析,從ARM7,ARM9到Cortex-A7,A8,A9,A12,A15到Cortex-A53,A57
http://www.myir-tech.com/resource/448.asp
-
ARM architecture
https://en.wikipedia.org/wiki/ARM_architecture
-
android的armeabi和armeabi-v7a
http://gybin.iteye.com/blog/2031565
版權聲明:本文為【歐陽鵬】原創文章。歡迎轉載,轉載請注明出處! 【http://blog.csdn.net/ouyang_peng/article/details/51168072】