轉載請標明出處：http://blog.csdn.net/xx326664162/article/details/51167849 文章出自：薛瑄的部落格

你也可以檢視我的其他同類文章，也會讓你有一定的收貨！

關於ABI的知識，我整理這兩篇部落格，相信會對你有幫助：

ABI和CPU關係的疑難雜症 
Android的.so檔案、ABI和CPU的關係

在這裡非常感激騰訊bugly的“Bugly-Android_符號表-Jalen”，對我有很多啟發和幫助

ABI和CPU的重要知識
1、 大部分cpu都支援多於一種的ABI。 
2、 當一個應用安裝在裝置上，只有該裝置支援的CPU架構對應的.so檔案會被安裝。

3、

ABI目錄（橫向）和cpu（縱向）    armeabi    armeabi-v7a    arm64-v8a    mips    mips64    x86    x86_64
ARMv5    支援                        
ARMv7    支援    支援                    
ARMv8    支援    支援    支援                
MIPS                支援            
MIPS64                支援    支援        
x86    支援（3）    支援（2）                支援（1）    
x86_64    支援                    支援    支援
注意：上表格中的空白部分，是我不知道它是否支援，極有可能是不支援

解析： x86裝置上，選擇ABI的優先順序

libs/x86目錄中如果存在.so檔案的話，會被安裝
如果不存在，則會選擇armeabi-v7a中的.so檔案
如果也不存在，則選擇armeabi目錄中的.so檔案
x86裝置能夠很好的執行ARM型別函式庫，但並不保證100%不發生crash，特別是對舊裝置，因為是執行在x86裝置上模擬arm的虛擬層上。

4、 64位裝置（arm64-v8a, x86_64, mips64）能夠執行32位的函式庫，但是以32位模式執行，在64位平臺上執行32位版本的ART和Android元件，將丟失專為64位優化過的效能（ART，webview，media等等）。

5、 最好是針對特定平臺提供相應平臺的二進位制包，這種情況下執行時就少了一個模擬層（例如x86裝置上模擬arm的虛擬層），從而得到更好的效能（歸功於最近的架構更新，例如硬體fpu，更多的暫存器，更好的向量化等）。

6、 會安裝優先順序較高的ABI目錄，則其它優先順序較低的ABI目錄（包括其它module中的ABI目錄），都無法安裝。例如：在cpu是ARMv7架構的手機上，如果檢測到armeabi-v7a，就會選擇安裝armeabi-v7a，則armeabi下的檔案，都無法安裝了。

7、 相應的ABI二進位制檔案，要放進相應的ABI目錄中

8、一般情況下不要簡單得修改架構目錄名

我們可以通過Build.SUPPORTED_ABIS得到根據偏好排序的裝置支援的ABI列表。但你不應該從你的應用程式中讀取它，因為Android包管理器安裝APK時，會自動選擇APK包中為對應系統ABI預編譯好的.so檔案，如果在對應的lib／ABI目錄中存在.so檔案的話。

工具
檢視專案中ABI檔案的架構型別 
騰訊bugly，符號表工具，下載地址：http://bugly.qq.com/whitebook

Native Libs Monitor這個應用可以幫助我們理解手機上安裝的APK用到了哪些.so檔案，以及.so檔案來源於哪些函式庫或者框架。

疑難雜症
雖然規則制定出來了，但總是會出現一些，不合規的現象，導致一些錯誤，難以理解。現在就讓我們來一起把把脈，看看到底是什麼疑難雜症

一、.so檔案，放進了優先順序低的ABI目錄
一、如果你的專案中，有其他優先順序更高的ABI目錄，但是你把ABI檔案放到了優先順序低的目錄，則你的ABI檔案無法被載入

二、如果你的專案中，ABI檔案放在了，專案中優先順序最高的ABI目錄中（這個ABI目錄是手機所支援的在專案中優先順序最高的，但不一定是手機所支援的優先順序最高的），則這個ABI檔案，可以被載入，載入為ABI目錄的所表示的架構型別。

例子：

我的手機cpu架構是ARMv7，ABI檔案是armeabi-v7a，但是放進了armeabi目錄中

在執行的過程中會出現兩種情況：

1、專案中有armeabi-v7a的目錄，armeabi目錄中的檔案，無法被載入，執行後報錯，出現如下log資訊。

Caused by: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/.xx../base.apk"],nativeLibraryDirectories=[/data/app/.xx../lib/arm, /vendor/lib, /system/lib]]] couldn't find "lib..xx...so"
1
2、專案中只有armeabi的目錄，armeabi目錄是該專案優先順序最高的ABI目錄（雖然armeabi目錄在ARMv7所支援的優先順序最高的ABI目錄不是最高），作為armv5，安裝到手機上。

二、ABI二進位制檔案，放進了優先順序高的ABI目錄
可以被載入使用，被載入為ABI檔案所表示的結構型別

例子：

我的手機cpu架構是ARMv7，ABI檔案是armeabi-v5te，但是放進了armeabi-v7a目錄中。

可以被載入，但是載入為ABI檔案所表示的架構型別。這樣就出現了，同一個應用中ABI檔案，出現兩種的情況。

三、兩個第三的SDK中ABI檔案優先順序不一樣
問題：

兩個第三方的SDK中ABI檔案優先順序不一樣，手機載入執行時，會導致優先順序低的庫，無法被載入

例子：

我的手機cpu架構是ARMv7，專案中使用兩個第三方SDK：企業A和企業B

企業A：ABI檔案是armeabi-v7a，放進armeabi-v7a目錄中。 
企業B：ABI檔案是armeabi-v5te，放進armeabi目錄中。

在執行時，會發現執行後crash，出現如下log資訊。

Caused by: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/.xx../base.apk"],nativeLibraryDirectories=[/data/app/.xx../lib/arm, /vendor/lib, /system/lib]]] couldn't find "lib..xx...so"
1
解決辦法：

1、使用同一優先順序的ABI檔案，ABI檔案放入優先順序相同的ABI目錄

企業A：ABI檔案是armeabi-v5te，放進armeabi目錄中。 
企業B：ABI檔案是armeabi-v5te，放進armeabi目錄中。 
或 
企業A：ABI檔案是armeabi-v7a，放進armeabi-v7a目錄中。 
企業B：ABI檔案是armeabi-v7a，放進armeabi-v7a目錄中。

2、使用不同優先順序的ABI檔案，ABI檔案放入優先順序相同的ABI目錄。一般情況不建議這麼做。

企業A：ABI檔案是armeabi-v7a，但是放進armeabi目錄中。 
企業B：ABI檔案是armeabi-v5te，放進armeabi目錄中。 
或 
企業A：ABI檔案是armeabi-v7a，放進armeabi-v7a目錄中。 
企業B：ABI檔案是armeabi-v5te，但是放進armeabi-v7a目錄中。
--------------------- 
作者：薛瑄 
來源：CSDN 
原文：https://blog.csdn.net/xx326664162/article/details/51167849?utm_source=copy 
版權宣告：本文為博主原創文章，轉載請附上博文連結！