早期的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)著一個相應的ABI院峡。
應用程序二進制接口（Application Binary Interface）定義了二進制文件（尤其是.so文件）如何運行在相應的系統(tǒng)平臺上兴使，從使用的指令集，內(nèi)存對齊到可用的系統(tǒng)函數(shù)庫照激。在Android系統(tǒng)上发魄，每一個CPU架構(gòu)對應一個ABI：armeabi，armeabi-v7a，x86励幼，mips汰寓，arm64-v8a，mips64苹粟，x86_64有滑。
為什么你需要重點關(guān)注.so文件
如果項目中使用到了NDK，它將會生成.so文件六水，因此顯然你已經(jīng)在關(guān)注它了俺孙。如果只是使用Java語言進行編碼，你可能在想不需要關(guān)注.so文件了吧掷贾，因為Java是跨平臺的睛榄。但事實上，即使你在項目中只是使用Java語言想帅，很多情況下场靴，你可能并沒有意識到項目中依賴的函數(shù)庫或者引擎庫里面已經(jīng)嵌入了.so文件，并依賴于不同的ABI港准。
例如
項目中使用RenderScript支持庫旨剥，OpenCV，Unity浅缸，android-gif-drawable轨帜，SQLCipher等，你都已經(jīng)在生成的APK文件中包含.so文件了衩椒，而你需要關(guān)注.so文件蚌父。
Android應用支持的ABI取決于APK中位于lib/ABI目錄中的.so文件，其中ABI可能是上面說過的七種ABI中的一種毛萌。
Native Libs Monitor這個應用可以幫助我們理解手機上安裝的APK用到了哪些.so文件苟弛，以及.so文件來源于哪些函數(shù)庫或者框架阁将。
當然，我們也可以自己對app反編譯來獲取這些信息做盅，不過相對麻煩一些。
很多設備都支持多于一種的ABI吹榴。例如 ARM64 和 x86 設備也可以同時運行armeabi-v7a 和armeabi 的二進制包僻他。但最好是針對特定平臺提供相應平臺的二進制包，這種情況下運行時就少了一個模擬層（例如x86設備上模擬arm的虛擬層）腊尚，從而得到更好的性能（歸功于最近的架構(gòu)更新，例如硬件fpu劝篷，更多的寄存器哨鸭，更好的向量化等）。
我們可以通過Build.SUPPORTED_ABIS得到根據(jù)偏好排序的設備支持的ABI列表娇妓。但你不應該從你的應用程序中讀取它像鸡，因為Android包管理器安裝APK時哈恰，會自動選擇APK包中為對應系統(tǒng)ABI預編譯好的.so文件，如果在對應的lib／ABI目錄中存在.so文件的話着绷。
App中可能出錯的地方
處理.so文件時有一條簡單卻并不知名的重要法則。
你應該盡可能的提供專為每個ABI優(yōu)化過的.so文件吁脱，但要么全部支持彬向，要么都不支持：你不應該混合著使用兼贡。你應該為每個ABI目錄提供對應的.so文件娃胆。
當一個應用安裝在設備上，只有該設備支持的CPU架構(gòu)對應的.so文件會被安裝凿蒜。
在x86設備上招驴，libs/x86目錄中如果存在.so文件的話枷畏，會被安裝;
如果不存在，則會選擇armeabi-v7a中的.so文件触趴，
如果也不存在渴肉，則選擇armeabi目錄中的.so文件（因為x86設備也支持armeabi-v7a和armeabi）。
其他地方也可能出錯
當你引入一個.so文件時仇祭，不止影響到CPU架構(gòu)。我從其他開發(fā)者那里可以看到一系列常見的錯誤没讲，其中最多的是"UnsatisfiedLinkError"，"dlopen: failed"以及其他類型的crash或者低下的性能：
使用android-21平臺版本編譯的.so文件運行在android-15的設備上
使用NDK時徙缴，你可能會傾向于使用最新的編譯平臺嘁信，但事實上這是錯誤的，因為NDK平臺不是后向兼容的潘靖，而是前向兼容的。推薦使用app的minSdkVersion對應的編譯平臺携御。
這也意味著當你引入一個預編譯好的.so文件時既绕，你需要檢查它被編譯所用的平臺版本。
混合使用不同C++運行時編譯的.so文件
.so文件可以依賴于不同的C++運行時凄贩，靜態(tài)編譯或者動態(tài)加載疲扎。混合使用不同版本的C++運行時可能導致很多奇怪的crash椒丧，是應該避免的。作為一個經(jīng)驗法則句柠，當只有一個.so文件時棒假，靜態(tài)編譯C++運行時是沒問題的，否則當存在多個.so文件時帽哑，應該讓所有的.so文件都動態(tài)鏈接相同的C++運行時妻枕。
這意味著當引入一個新的預編譯.so文件粘驰，而且項目中還存在其他的.so文件時述么，我們需要首先確認新引入的.so文件使用的C++運行時是否和已經(jīng)存在的.so文件一致。
沒有為每個支持的CPU架構(gòu)提供對應的.so文件
這一點在前文已經(jīng)說到了碉输，但你應該真的特別注意它敷钾，因為它可能發(fā)生在根本沒有意識到的情況下。
例如：你的app支持armeabi-v7a和x86架構(gòu)阻荒，然后使用Android Studio新增了一個函數(shù)庫依賴，這個函數(shù)庫包含.so文件并支持更多的CPU架構(gòu)蓖租，例如新增android-gif-drawable函數(shù)庫：
compile ‘pl.droidsonroids.gif:android-gif-drawable:1.1.+’
發(fā)布我們的app后羊壹，會發(fā)現(xiàn)它在某些設備上會發(fā)生Crash，例如Galaxy S6稠茂，最終可以發(fā)現(xiàn)只有64位目錄下的.so文件被安裝進手機情妖。
解決方案：重新編譯我們的.so文件使其支持缺失的ABIs，或者在gradle中設置
multiDexEnabled true
ndk {
abiFilters "armeabi-v7a", "x86"
}
顯示指定支持的ABIs电爹。
最后一點：如果你是一個SDK提供者料睛，但提供的函數(shù)庫不支持所有的ABIs，那你將會搞砸你的用戶秦效，因為他們能支持的ABIs必將只能少于你提供的涎嚼。
將.so文件放在錯誤的地方
我們往往很容易對.so文件應該放在或者生成到哪里感到困惑，下面是一個總結(jié)：
- Android Studio工程放在jniLibs/ABI目錄中苔货，如果放在libs文件夾下，需要在gradle中姻灶，添加如下代碼诈茧，指向文件路徑
sourceSets {
main {
jniLibs.srcDirs = ['libs']
}
}
- Eclipse工程放在libs/ABI目錄中（這也是ndk-build命令默認生成.so文件的目錄）
- AAR壓縮包中位于jni/ABI目錄中（.so文件會自動包含到引用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 設備都支持 armeabi 架構(gòu)的.so文件，因此似乎移除其他ABIs的.so文件是一個減少APK大小的好技巧唯蝶。但事實上并不是：這不只影響到函數(shù)庫的性能和兼容性遗嗽。
x86設備能夠很好的運行ARM類型函數(shù)庫，但并不保證100%不發(fā)生crash涂滴，特別是對舊設備晴音。64位設備（arm64-v8a, x86_64, mips64）能夠運行32位的函數(shù)庫，但是以32位模式運行搁料，在64位平臺上運行32位版本的ART和Android組件系羞，將丟失專為64位優(yōu)化過的性能（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
}
}
}
