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文件的話。
App中可能出錯的地方
處理.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/Android jniLibs下文件夾具體解釋（.so文件）
http://www.jianshu.com/p/b758e36ae9b5ARM內核全解析，從ARM7,ARM9到Cortex-A7,A8,A9,A12,A15到Cortex-A53,A57
http://www.myir-tech.com/resource/448.aspARM architecture
https://en.wikipedia.org/wiki/ARM_architectureandroid的armeabi和armeabi-v7a
http://gybin.iteye.com/blog/2031565
版權聲明：本文為【歐陽鵬】原創文章。歡迎轉載，轉載請注明出處! 【http://blog.csdn.net/ouyang_peng/article/details/51168072】
