獲取當前ABI

var supportsABIs:Array<String>? = null
if(Build.VERSION.SDK_INT >= 21) {supportsABIs = Build.SUPPORTED_ABIS
}
var currentABI = Build.CPU_ABI

? ? 通過Build可以獲取當前手機支持的abi集以及cpu的abi

前言 ? ?

????早期的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。

? ? 可以參考這篇官方文檔https://developer.android.com/ndk/guides/abis.html

? ? 其中armeabi mips 和mips64已經被廢棄，并且在ndk r17中將會被移除。

為什么你需要重點關注.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中的一種。

????很多設備都支持多于一種的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文件放在錯誤的地方

????我們往往很容易對.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等等）。

?