附上官網權威說明：https://developer.android.com/ndk/guides/abis?hl=zh-cn

現有的CPU架構類型

開發Android應用時，有時候Java層的編碼不能滿足實現需求，就需要到C/C++實現后生成SO文件，再用System.loadLibrary()加載進行調用，這里成為JNI層的實現。常見的場景如：加解密算法，音視頻編解碼等。在生成SO文件時，需要考慮適配市面上不同手機CPU架構，而生成支持不同平臺的SO文件進行兼容。目前Android共支持七種不同類型的CPU架構，分別是：ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，MIPS (從2012年起)，ARMv8，MIPS64和x86_64 (從2014年起)。

現有的常用ABI

應用程序二進制接口（Application Binary Interface）定義了其所對應的CPU架構能夠執行的二進制文件（特別是.so文件）的格式規范。在Android系統上，不同 Android 手機使用不同的 CPU，因此支持不同的指令集。CPU 與指令集的每種組合都有其自己的應用二進制界面（或 ABI）。 ABI 可以非常精確地定義應用的機器代碼在運行時如何與系統交互。 您必須為應用要使用的每個 CPU 架構指定 ABI：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64【1】。

典型的 ABI 包含以下信息：

• 機器代碼應使用的 CPU 指令集。
• 運行時內存存儲和加載的字節順序。
• 可執行二進制文件（例如程序和共享庫）的格式，以及它們支持的內容類型。
• 用于解析內容與系統之間數據的各種約定。這些約定包括對齊限制，以及系統如何使用堆棧和在調用函數時注冊。
• 運行時可用于機器代碼的函數符號列表 - 通常來自非常具體的庫集。
• 支持一個或多個指令集。

SO（CPU）的兼容

每一個CPU架構對應一個ABI，一個cpu屬于某一種架構，多核cpu需要屬于相同架構才能一起工作,很多設備僅支持一種的CPU架構。

如果你要完美兼容所有類型的手機，理論上是要在的libs目錄下放置各個架構平臺的SO文件。

1.png

這樣一寫，雖然可以兼容所有機型，但你的項目體積也會變得非常龐大。是否一定需要帶入這么多SO文件去兼容呢？答案是否定的。

對于CPU來說，不同的架構并不意味著一定互不兼容，根據目前Android共支持七種不同類型的CPU架構，其兼容特點可總結如下：

armeabi設備只兼容armeabi；
armeabi-v7a設備兼容armeabi-v7a、armeabi；
arm64-v8a設備兼容arm64-v8a、armeabi-v7a、armeabi；
X86設備兼容X86、armeabi；
X86_64設備兼容X86_64、X86、armeabi；
mips64設備兼容mips64、mips；
mips只兼容mips；

根據以上的兼容總結，我們還可以得到一些規律：

• armeabi的SO文件基本上可以說是萬金油，它能運行在除了mips和mips64的設備上，但在非armeabi設備上運行性能還是有所損耗；
• 64位的CPU架構總能向下兼容其對應的32位指令集，如：x86_64兼容X86，arm64-v8a兼容armeabi-v7a，mips64兼容mips；

.so文件的相關注意事項

SO的適配

當一個應用安裝在設備上，只有該設備支持的CPU架構對應的.so文件會被安裝。在x86設備上，libs/x86目錄中如果存在.so文件的話，會被安裝，如果不存在，則會選擇armeabi-v7a中的.so文件，如果也不存在，則選擇armeabi目錄中的.so文件（因為x86設備也支持armeabi-v7a和armeabi）。

從目前移動端CPU市場的份額數據看，ARM架構幾乎壟斷，所以，除非你的用戶很特殊，否則幾乎可以不考慮單獨編譯帶入X86、X86_64、mips、mips64架構SO文件。除去這四個架構之后，還要帶入armeabi、armeabi-v7a、arm64-v8a這三個不同類型，這對于一個擁有大量SO文件的應用來說，安裝包的體積將會增大不少。

針對以上情況，我們可以應用的設備分布和市場情況再進行取舍斟酌，如果你的應用仍有不少armeabi類型的設備，可以考慮只保留armeabi目錄下的SO文件（萬金油特性）。但是，盡管armeabi可以兼容多種平臺，仍有些運算在armeabi-v7a、arm64-v8a，去使用armeabi的SO文件時，性能會非常差強人意，所以還是應該用其對應平臺架構的SO文件進行運算。

注意：
這里并不是要帶多一整套SO文件到不同的目錄下，而是將性能差異比較明顯的某個armeabi-v7a、arm64-v8a平臺下的SO文件放到armeabi目錄，然后通過代碼判斷設備的CPU類型，再加載其對應架構的SO文件，很多大廠的應用便是這么做的。你應該盡可能的提供專為每個ABI優化過的.so文件，但要么全部支持，要么都不支持：你不應該混合著使用。你應該為每個ABI目錄提供對應的.so文件。
如微信的lib下雖然只有armeabi一個目錄，但目錄內的文件仍放著v5、v7a架構的SO文件，用于處理兼容帶來的某些性能運算問題。

2.png

總結
就目前市場份額而言，絕大部分的設備都已經是armeabi-v7a、arm64-v8a，你也可以考慮只保留armeabi-v7a架構的SO文件，這樣能獲得更好的性能效果。性能差異比較明顯加入單的的so文件并在代碼中去判斷。

引入.so文件的錯誤

當你引入一個.so文件時，不止影響到CPU架構。從其他開發者那里可以看到一系列常見的錯誤，其中最多的是"UnsatisfiedLinkError"，"dlopen: failed"以及其他類型的crash或者低下的性能：

1. 使用android-21平臺版本編譯的.so文件運行在android-15的設備上

使用NDK時，你可能會傾向于使用最新的編譯平臺，但事實上這是錯誤的，因為NDK平臺不是后向兼容的，而是前向兼容的。推薦使用app的minSdkVersion對應的編譯平臺。

這也意味著當你引入一個預編譯好的.so文件時，你需要檢查它被編譯所用的平臺版本。

2. 混合使用不同C++運行時編譯的.so文件

.so文件可以依賴于不同的C++運行時，靜態編譯或者動態加載。混合使用不同版本的C++運行時可能導致很多奇怪的crash，是應該避免的。作為一個經驗法則，當只有一個.so文件時，靜態編譯C++運行時是沒問題的，否則當存在多個.so文件時，應該讓所有的.so文件都動態鏈接相同的C++運行時。

這意味著當引入一個新的預編譯.so文件，而且項目中還存在其他的.so文件時，我們需要首先確認新引入的.so文件使用的C++運行時是否和已經存在的.so文件一致。

3. 沒有為每個支持的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必將只能少于你提供的。

4. 將.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目錄中。

5. 只提供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
        }
    }
 }

附錄：

【1】

3.png

armeabi
此 ABI 適用于基于 ARM、至少支持 ARMv5TE 指令集的 CPU。 請參閱以下文檔了解詳情：

• ARM 架構參考手冊
• ARM 架構的過程調用標準
• ARM ELF 文件格式
• ARM 架構的應用二進制界面 (ABI)
• ARM 架構的基本平臺 ABI
• ARM 架構的 C 庫 ABI
• ARM 架構的 C++ ABI
• ARM 架構的運行時 ABI
• ELF System V 應用二進制界面
• 通用/Itanium C++ ABI

AAPCS 標準將 EABI 定義為類似但不同 ABI 的系列。 此外，Android 還采用小字節序 ARM GNU/Linux ABI。
此 ABI 不支持硬件輔助的浮點計算。 相反，所有浮點運算都使用編譯器 libgcc.a
靜態庫中的軟件幫助程序函數。
armeabi ABI 支持 ARM 的 Thumb（亦稱 Thumb-1）指令集。NDK 默認生成 Thumb 代碼，除非您在 Android.mk 文件中使用 LOCAL_ARM_MODE變量指定不同的行為。

armeabi-v7a
此 ABI 可擴展 armeabi 以包含多個 CPU 指令集擴展。 此 Android 特定 ABI 支持的指令擴展包括：

• Thumb-2 指令集擴展，其性能堪比 32 位 ARM 指令，簡潔性類似于 Thumb-1。
• VFP 硬件 FPU 指令。更具體一點，包括 VFPv3-D16，它除了 ARM 核心中的 16 個 32 位寄存器之外，還包含 16 個專用 64 位浮點寄存器。

v7-a ARM 規格描述的其他擴展，包括 高級 SIMD（亦稱 NEON）、VFPv3-D32 和 ThumbEE，都是此 ABI 可選的。 由于不能保證它們存在，因此系統在運行時應檢查擴展是否可用。 如果不可用，則必須使用替代代碼路徑。此檢查類似于系統在檢查或使用 MMX、SSE2 及 x86 CPU 上其他專用指令集時所執行的檢查。

如需了解有關如何執行這些運行時檢查的信息，請參閱 cpufeatures
庫。另外，有關 NDK 支持為 NEON 構建機器代碼的信息，請參閱 NEON 支持。

armeabi-v7a ABI 使用 -mfloat-abi=softfp開關強制實施規則，要求編譯器在函數調用時必須傳遞核心寄存器對中的所有雙精度值，而不是專用浮點值。 系統可以使用 FP 寄存器執行所有內部計算。 這樣可極大地加速計算。

arm64-v8a
此 ABI 適用于基于 ARMv8、支持 AArch64 的 CPU。它還包含 NEON 和 VFPv4 指令集。
如需了解詳細信息，請參閱 ARMv8 技術預覽，并聯系 ARM 了解進一步的詳細信息。

x86
此 ABI 適用于支持通常稱為“x86”或“IA-32”的指令集的 CPU。 此 ABI 的特性包括：

• 指令一般由具有編譯器標志的 GCC 生成，如下所示：

-march=i686 -mtune=intel -mssse3 -mfpmath=sse -m32

這些標志指向 Pentium Pro 指令集，伴隨 MMX、SSE、SSE2、SSE3 及 SSSE3 指令集擴展。生成的代碼在頂層 Intel 32 位 CPU 之間進行了均衡優化。
如需了解有關編譯器標志的詳細信息，特別是與性能優化相關的信息，請參閱 GCC x86 性能提示。

• 使用標準 Linux x86 32 位調用約定，與 SVR 使用的約定相反。如需了解詳細信息，請參閱不同 C++ 編譯器和操作系統的調用約定的第 6 節“寄存器的使用”。

ABI 不含任何其他可選的 IA-32 指令集擴展，例如：

• MOVBE
• SSE4 的任何變體。

您仍可使用這些擴展，只要您使用運行時功能探測來啟用它們，并且為不支持它們的設備提供備用方法。
NDK 工具鏈假設在函數調用之前進行 16 位棧對齊。默認工具和選項強制執行此規則。 如果編寫的是匯編代碼，必須確保棧對齊，而且其他編譯器也遵守此規則。
請參閱以下文檔了解詳情：

• GCC 在線文檔： Intel 386 和 AMD x86-64 選項
• 不同 C++ 編譯器和操作系統的調用約定
• Intel IA-32 Intel 架構軟件開發者手冊第 2 卷：指令集參考
• Intel IA-32 Intel 架構軟件開發者手冊第 3 卷：系統編程指南
• System V 應用二進制界面： Intel386 處理器架構補充

x86_64
此 ABI 適用于支持通常稱為“x86-64”的指令集的 CPU。 它支持 GCC 通常使用以下編譯器標志生成的指令：

-march=x86-64 -msse4.2 -mpopcnt -m64 -mtune=intel

這些標志指向 x86-64 指令集（根據 GCC 文檔），伴隨 MMX、SSE、SSE2、SSE3、SSSE3、SSE4.1、SSE4.2 和 POPCNT 指令集擴展。 生成的代碼在頂層 Intel 64 位 CPU 之間進行了均衡優化。
如需了解有關編譯器標志的詳細信息，特別是與性能優化相關的信息，請參閱 GCC x86 性能。
此 ABI 不含任何其他可選的 x86-64 指令集擴展，例如：

• MOVBE
• SHA
• AVX
• AVX2

您仍可使用這些擴展，只要您使用運行時功能探測來啟用它們，并且為不支持它們的設備提供備用方法。
請參閱以下文檔了解詳情：

• 不同 C++ 編譯器和操作系統的調用約定
• Intel64 和 IA-32 架構軟件開發者手冊第 2 卷：指令集參考
• Intel64 和 IA-32 架構軟件開發者手冊第 3 卷：系統編程

mips
此 ABI 適用于基于 MIPS、至少支持 MIPS32r1 指令集的 CPU。它包含以下功能：

• MIPS32 修訂版 1 ISA
• 小字節序
• O32
• 硬浮點
• 無 DSP 應用特定的擴展

如需了解詳細信息，請參閱以下文檔：

• 編程者的架構 ("MIPSARCH")
• ELF System V 應用二進制界面
• Itanium/通用 C++ ABI

如需了解更具體的詳細信息，請參閱 MIPS32 架構。常見問答請參閱 MIPS FAQ。

mips64
此 ABI 適用于 MIPS64 R6。如需了解詳細信息，請參閱 MIPS64 架構。