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裏面也必須有

做者：green jim 
連接：微信的安裝包在只編譯了armeabi，沒有x86，arm64-v8a是如何運行在各類處理器的手機上的？ - green jim 的回答
來源：知乎 
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

發現原來華爲 Mate 8手機是64位的操做系統，而小米 4 手機是32位的操做系統，因此小米 4 手機手機運行APP沒bug,而華爲 Mate 8手機運行APP出現閃退bug。

解決方法

一、解決以前的截圖：

從截圖能夠看出來，第一個項目中有 arm64-v8a，而沒有x86目錄，第二個項目中沒有arm64-v8a，而有x86目錄。第一個項目是做爲項目引用導入到第二個項目中的。

二、解決後的截圖：

從截圖能夠看出來，第一個項目中和第二個項目中沒有的libs目錄下，都是armeabi-v7a、armeabi、x86三個目錄，保持一致。第一個項目是做爲項目引用導入到第二個項目中的。

三、解決方法：

解決方法是：從友盟官方中去下載x86的相關so文件，放在x86目錄下，把arm64-v8a目錄刪除。將全部關於so文件的都要保持一致，即：若是你要添加一個armeabi-v8a目錄，下面放第三方的armeabi-v8a相關的so文件，那麼你其餘的so文件都要有相應想armeabi-v8a版本，否則就會報錯。

四、建議

來自於博客：《與 .so 有關的一個終年大坑 》給的建議是：

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

下面文章轉載於asce1885（簡書做者）：關於Android的.so文件你所須要知道的
（原文連接：關於Android的.so文件你所須要知道的） 
著做權歸做者全部，轉載請聯繫做者得到受權，並標註「簡書做者」。

早期的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函數庫：

發佈咱們的app後，會發現它在某些設備上會發生Crash，例如Galaxy S6，最終能夠發現只有64位目錄下的.so文件被安裝進手機。

解決方案：從新編譯咱們的.so文件使其支持缺失的ABIs，或者設置

顯示指定支持的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中以下配置：