armeabiv-v7a: 第7代及以上的 ARM 處理器。2011年15月以后的生產(chǎn)的大部分Android設(shè)備都使用它.

arm64-v8a: 第8代、64位ARM處理器，很少設(shè)備，三星 Galaxy S6是其中之一。

armeabi: 第5代、第6代的ARM處理器，早期的手機(jī)用的比較多。

x86: 平板、模擬器用得比較多。

x86_64: 64位的平板。

問題描述

今天測試人員測試集成版本時除了一個bug：關(guān)于華為 Mate 8手機(jī)Android?6.0系統(tǒng)運(yùn)行剛剛提測的版本時，出現(xiàn)閃退的bug，而小米 4 手機(jī)Android 6.0系統(tǒng)卻沒有出現(xiàn)任何bug，運(yùn)行良好。后來查看本人相關(guān)模塊的代碼，發(fā)現(xiàn)本人集成版本相關(guān)模塊的代碼和分支版本相關(guān)模塊的代碼是一模一樣的，那就是說本人把分支代碼合并到主干代碼是沒有問題的，所以去查看主干代碼的問題。

經(jīng)過一番查看提交日志，發(fā)現(xiàn)有位同事再我合并代碼之前，提交了一個關(guān)于友盟推送的so文件的記錄，原來他加入了一個arm64-v8a文件夾，里面有友盟推送的arm64-v8a的so庫文件。而其他的so庫文本卻沒有arm64-v8a對應(yīng)的版本。

通過百度查到知乎有一段關(guān)于arm64-v8a的解釋：

arm64-v8a是可以向下兼容的，但前提是你的項目里面沒有arm64-v8a的文件夾，如果你有兩個文件夾armeabi和arm64-v8a，兩個文件夾，armeabi里面有a.so 和 b.so,arm64-v8a里面只有a.so，那么arm64-v8a的手機(jī)在用到b的時候發(fā)現(xiàn)有arm64-v8a的文件夾，發(fā)現(xiàn)里面沒有b.so，就報錯了，所以這個時候刪掉arm64-v8a文件夾，這個時候手機(jī)發(fā)現(xiàn)沒有適配arm64-v8a，就會直接去找armeabi的so庫，所以要么你別加arm64-v8a,要么armeabi里面有的so庫，arm64-v8a里面也必須有

作者：green jim?
鏈接：微信的安裝包在只編譯了armeabi，沒有x86，arm64-v8a是如何運(yùn)行在各種處理器的手機(jī)上的？ - green jim 的回答
來源：知乎?
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。

發(fā)現(xiàn)原來華為 Mate 8手機(jī)是64位的操作系統(tǒng)，而小米 4 手機(jī)是32位的操作系統(tǒng)，所以小米 4 手機(jī)手機(jī)運(yùn)行APP沒bug,而華為 Mate 8手機(jī)運(yùn)行APP出現(xiàn)閃退bug。

解決方法

1、解決之前的截圖：

從截圖可以看出來，第一個項目中有?arm64-v8a，而沒有x86目錄，第二個項目中沒有arm64-v8a，而有x86目錄。第一個項目是作為項目引用導(dǎo)入到第二個項目中的。

2、解決后的截圖：

從截圖可以看出來，第一個項目中和第二個項目中沒有的libs目錄下，都是armeabi-v7a、armeabi、x86三個目錄，保持一致。第一個項目是作為項目引用導(dǎo)入到第二個項目中的。

3、解決方法：

解決方法是：從友盟官方中去下載x86的相關(guān)so文件，放在x86目錄下，把a(bǔ)rm64-v8a目錄刪除。將所有關(guān)于so文件的都要保持一致，即：如果你要添加一個armeabi-v8a目錄，下面放第三方的armeabi-v8a相關(guān)的so文件，那么你其他的so文件都要有相應(yīng)想armeabi-v8a版本，不然就會報錯。

4、建議

來自于博客：《與 .so 有關(guān)的一個長年大坑 》給的建議是：

• 為了減小 apk 體積，只保留 armeabi 和 armeabi-v7a 兩個文件夾，并保證這兩個文件夾中 .so 數(shù)量一致
• 對只提供 armeabi 版本的第三方 .so，原樣復(fù)制一份到 armeabi-v7a 文件夾

下面文章轉(zhuǎn)載于asce1885（簡書作者）：關(guān)于Android的.so文件你所需要知道的
（原文鏈接：關(guān)于Android的.so文件你所需要知道的）?
著作權(quán)歸作者所有，轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，并標(biāo)注“簡書作者”。

早期的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)著一個相應(yīng)的ABI。

應(yīng)用程序二進(jìn)制接口（Application Binary Interface）定義了二進(jìn)制文件（尤其是.so文件）如何運(yùn)行在相應(yīng)的系統(tǒng)平臺上，從使用的指令集，內(nèi)存對齊到可用的系統(tǒng)函數(shù)庫。在Android系統(tǒng)上，每一個CPU架構(gòu)對應(yīng)一個ABI：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。

為什么你需要重點關(guān)注.so文件

如果項目中使用到了NDK，它將會生成.so文件，因此顯然你已經(jīng)在關(guān)注它了。如果只是使用Java語言進(jìn)行編碼，你可能在想不需要關(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應(yīng)用支持的ABI取決于APK中位于lib/ABI目錄中的.so文件，其中ABI可能是上面說過的七種ABI中的一種。?

Native Libs Monitor這個應(yīng)用可以幫助我們理解手機(jī)上安裝的APK用到了哪些.so文件，以及.so文件來源于哪些函數(shù)庫或者框架。

當(dāng)然，我們也可以自己對app反編譯來獲取這些信息，不過相對麻煩一些。

很多設(shè)備都支持多于一種的ABI。例如ARM64和x86設(shè)備也可以同時運(yùn)行armeabi-v7a和armeabi的二進(jìn)制包。但最好是針對特定平臺提供相應(yīng)平臺的二進(jìn)制包，這種情況下運(yùn)行時就少了一個模擬層（例如x86設(shè)備上模擬arm的虛擬層），從而得到更好的性能（歸功于最近的架構(gòu)更新，例如硬件fpu，更多的寄存器，更好的向量化等）。

我們可以通過Build.SUPPORTED_ABIS得到根據(jù)偏好排序的設(shè)備支持的ABI列表。但你不應(yīng)該從你的應(yīng)用程序中讀取它，因為Android包管理器安裝APK時，會自動選擇APK包中為對應(yīng)系統(tǒng)ABI預(yù)編譯好的.so文件，如果在對應(yīng)的lib／ABI目錄中存在.so文件的話。

App中可能出錯的地方

處理.so文件時有一條簡單卻并不知名的重要法則。

你應(yīng)該盡可能的提供專為每個ABI優(yōu)化過的.so文件，但要么全部支持，要么都不支持：你不應(yīng)該混合著使用。你應(yīng)該為每個ABI目錄提供對應(yīng)的.so文件。

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

其他地方也可能出錯

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

使用android-21平臺版本編譯的.so文件運(yùn)行在android-15的設(shè)備上

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

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

混合使用不同C++運(yùn)行時編譯的.so文件

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

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

沒有為每個支持的CPU架構(gòu)提供對應(yīng)的.so文件

這一點在前文已經(jīng)說到了，但你應(yīng)該真的特別注意它，因為它可能發(fā)生在根本沒有意識到的情況下。

例如：你的app支持armeabi-v7a和x86架構(gòu)，然后使用Android Studio新增了一個函數(shù)庫依賴，這個函數(shù)庫包含.so文件并支持更多的CPU架構(gòu)，例如新增android-gif-drawable函數(shù)庫：

發(fā)布我們的app后，會發(fā)現(xiàn)它在某些設(shè)備上會發(fā)生Crash，例如Galaxy S6，最終可以發(fā)現(xiàn)只有64位目錄下的.so文件被安裝進(jìn)手機(jī)。

解決方案：重新編譯我們的.so文件使其支持缺失的ABIs，或者設(shè)置

顯示指定支持的ABIs。

最后一點：如果你是一個SDK提供者，但提供的函數(shù)庫不支持所有的ABIs，那你將會搞砸你的用戶，因為他們能支持的ABIs必將只能少于你提供的。

將.so文件放在錯誤的地方

我們往往很容易對.so文件應(yīng)該放在或者生成到哪里感到困惑，下面是一個總結(jié)：

• Android Studio工程放在jniLibs/ABI目錄中（當(dāng)然也可以通過在build.gradle文件中的設(shè)置jniLibs.srcDir屬性自己指定）
• Eclipse工程放在libs/ABI目錄中（這也是ndk-build命令默認(rèn)生成.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設(shè)備都支持armeabi架構(gòu)的.so文件，因此似乎移除其他ABIs的.so文件是一個減少APK大小的好技巧。但事實上并不是：這不只影響到函數(shù)庫的性能和兼容性。

x86設(shè)備能夠很好的運(yùn)行ARM類型函數(shù)庫，但并不保證100%不發(fā)生crash，特別是對舊設(shè)備。64位設(shè)備（arm64-v8a, x86_64, mips64）能夠運(yùn)行32位的函數(shù)庫，但是以32位模式運(yùn)行，在64位平臺上運(yùn)行32位版本的ART和Android組件，將丟失專為64位優(yōu)化過的性能（ART，webview，media等等）。

以減少APK包大小為由是一個錯誤的借口，因為你也可以選擇在應(yīng)用市場上傳指定ABI版本的APK，生成不同ABI版本的APK可以在build.gradle中如下配置：

轉(zhuǎn)載于:https://www.cnblogs.com/Im-Victor/p/10435989.html

總結(jié)

以上是生活随笔為你收集整理的Android 设备的CPU类型(通常称为”ABIs”)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。