Android 裝置的CPU型別(通常稱為”ABIs”)

1. armeabiv-v7a: 第7代及以上的 ARM 處理器。2011年15月以後的生產的大部分Android裝置都使用它.
2. arm64-v8a: 第8代、64位ARM處理器，很少裝置，三星 Galaxy S6是其中之一。
3. armeabi: 第5代、第6代的ARM處理器，早期的手機用的比較多。
4. x86: 平板、模擬器用得比較多。
5. 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裡面也必須有 

發現原來華為 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、建議

• 為了減小 apk 體積，只保留 armeabi 和 armeabi-v7a 兩個資料夾，並保證這兩個資料夾中 .so 數量一致
• 對只提供 armeabi 版本的第三方 .so，原樣複製一份到 armeabi-v7a 資料夾

早期的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.+’

• 1

釋出我們的app後，會發現它在某些裝置上會發生Crash，例如Galaxy S6，最終可以發現只有64位目錄下的.so檔案被安裝進手機。

解決方案：重新編譯我們的.so檔案使其支援缺失的ABIs，或者設定

ndk.abiFilters

• 1

顯示指定支援的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等等）。

以減少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
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22

更多參考