Android的.so檔案、ABI和CPU的關係
關於ABI的知識,我整理這兩篇部落格,相信會對你有幫助
早期的Android系統幾乎只支援ARMv5的CPU架構,你知道現在它支援多少種嗎?
Android系統目前支援以下七種不同的CPU架構:ARMv5,ARMv7 (從2010年起),x86 (從2011年起),MIPS (從2012年起),ARMv8,MIPS64和x86_64 (從2014年起),每一種都關聯著一個相應的ABI。
應用程式二進位制介面ABI(Application Binary Interface)定義了二進位制檔案(尤其是.so檔案)如何執行在相應的系統平臺上,從使用的指令集,記憶體對齊到可用的系統函式庫。
為什麼你需要重點關注.so檔案
專案中使用到了NDK,它將會生成.so檔案。
如果只使用Java語言進行編碼,你可能在想不需要關注.so檔案了吧,因為Java是跨平臺的。但你可能並沒有意識到專案中依賴的函式庫或者引擎庫裡面已經嵌入了.so檔案,並依賴於不同的ABI。
Android應用支援的ABI取決於APK中位於lib/ABI目錄中的.so檔案,其中ABI可能是上面說過的七種ABI中的一種。
本地庫監視器
Native Libs Monitor這個應用可以幫助我們理解手機上安裝的APK用到了哪些.so檔案,以及.so檔案來源於哪些函式庫或者框架。
ABI和CPU的關係
- 很多裝置都支援多於一種的ABI。
- 當一個應用安裝在裝置上,只有該裝置支援的CPU架構對應的.so檔案會被安裝。
但最好是針對特定平臺提供相應平臺的二進位制包,這種情況下執行時就少了一個模擬層(例如x86裝置上模擬arm的虛擬層),從而得到更好的效能(歸功於最近的架構更新,例如硬體fpu,更多的暫存器,更好的向量化等)。
我們可以通過Build.SUPPORTED_ABIS得到根據偏好排序的裝置支援的ABI列表。但你不應該從你的應用程式中讀取它,因為Android包管理器安裝APK時,會自動選擇APK包中為對應系統ABI預編譯好的.so檔案,
ABI(橫向)和cpu(縱向) | armeabi | armeabi-v7a | arm64-v8a | mips | mips64 | x86 | x86_64 |
---|---|---|---|---|---|---|---|
ARMv5 | 支援 | ||||||
ARMv7 | 支援 | 支援 | |||||
ARMv8 | 支援 | 支援 | 支援 | ||||
MIPS | 支援 | ||||||
MIPS64 | 支援 | 支援 | |||||
x86 | 支援(3) | 支援(2) | 支援(1) | ||||
x86_64 | 支援 | 支援 | 支援 |
不同的ABI,針對不同的cpu架構有不同的優先權
例如: x86裝置上,libs/x86目錄中如果存在.so檔案的話,會被安裝,如果不存在,則會選擇armeabi-v7a中的.so檔案,如果也不存在,則選擇armeabi目錄中的.so檔案。
x86裝置能夠很好的執行ARM型別函式庫,但並不保證100%不發生crash,特別是對舊裝置。
64位裝置(arm64-v8a, x86_64, mips64)能夠執行32位的函式庫,但是以32位模式執行,在64位平臺上執行32位版本的ART和Android元件,將丟失專為64位優化過的效能(ART,webview,media等等)。
.so檔案重要法則
處理.so檔案時有一條簡單卻並不知名的重要法則。
你應該儘可能的提供專為每個ABI優化過的.so檔案,你不應該混合著使用(不能就裝對不同cpu架構的so檔案,放在同一個ABI目錄下)。你應該為每個ABI目錄提供對應的.so檔案。
NDK相容性
使用NDK時,你可能會傾向於使用最新的編譯平臺,但事實上這是錯誤的,因為NDK平臺不是後向相容(相容過去的版本)的,而是前向相容(相容將來的版本)的。推薦使用app的minSdkVersion對應的編譯平臺。
這也意味著當你引入一個預編譯好的.so檔案時,你需要檢查它被編譯所用的平臺版本。
混合使用不同C++執行時編譯的.so檔案
.so檔案可以依賴於不同的C++執行時,靜態編譯或者動態載入。
混合使用不同版本的C++執行時可能導致很多奇怪的crash,是應該避免的。
一個經驗法則
- 當只有一個.so檔案時,靜態編譯C++執行時是沒問題的,
- 當存在多個.so檔案時,應該讓所有的.so檔案都動態連結相同的C++執行時。
- 這意味著當引入一個新的預編譯.so檔案,而且專案中還存在其他的.so檔案時,我們需要首先確認新引入的.so檔案使用的C++執行時是否和已經存在的.so檔案一致。
。
關於.so檔案的錯誤示例
問題:
你的app目前只支援armeabi-v7a和x86架構,你想讓app支援更多的cpu型別,新增了一個函式庫依賴,這個函式庫包含.so檔案並支援更多的CPU架構。
釋出我們的app後,會發現它在某些裝置上會發生Crash,例如Galaxy S6,最終可以發現只有64位目錄下的.so檔案被安裝進手機。
解決方案:
重新編譯我們的.so檔案使其支援缺失的ABIs
也可以設定ndk.abiFilters
顯示指定支援的ABIs
.so檔案的路徑
在IDE中的路徑
- Android Studio工程放在jniLibs/ABI目錄中(當然也可以通過在build.gradle檔案中的設定jniLibs.srcDir屬性自己指定)
- Eclipse工程放在libs/ABI目錄中(這也是ndk-build命令預設生成.so檔案的目錄)
在AAR壓縮包中的路徑
AAR壓縮包中位於jni/ABI目錄中(.so檔案會自動包含到引用AAR壓縮包的APK中)
在APK中的路徑
最終APK檔案中的lib/ABI目錄中
通過PackageManager安裝後,.so檔案路徑
通過PackageManager安裝後,在小於Android 5.0的系統中,.so檔案位於app的nativeLibraryPath目錄中;在大於等於Android 5.0的系統中,.so檔案位於app的nativeLibraryRootDir/CPU_ARCH目錄中。
生成不同ABI版本的APK
以減少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
}
}
}
關注我的公眾號,輕鬆瞭解和學習更多技術