目錄
0. 前言
前幾天啊，在公衆號發了一篇文章《優化ApK大小之ABI Filters 和 APK split》，評論區收到了一些留言說，文章講得不夠深入，關於系統是如何選擇不同abi下的so庫的？當前APP該如何適配？該去掉哪些該保留哪些？都存在一些疑問。
因此，決定親自更文一篇，系統地講一下關於Android CPU架構方面的一些東西，以及結合大廠APP如微信、支付寶、淘寶等APP的適配情況，分析我們開發APP中該如何適配。本文涉及以下幾個問題：
- 什麼是ABI？
- ABI有何作用？
- 目前大廠APP是如何適配不同的CPU架構的？
- ABI 是如何工作的？
- 我們自己的APP中該如何適配？
- ABI split-性能+兼容全都要
本篇文章中，就一一爲你解答這些疑問。
1. 什麼是ABI?
ABI是英文Application Binary Interface的縮寫，及應用二進制接口。
不同Android設備，使用的CPU架構可能不同，因此支持不同的指令集。 CPU 與指令集的每種組合都有其自己的應用二進制界面（或 ABI）,ABI非常精確地定義了應用程序的機器代碼應如何在運行時與系統交互。您必須爲要與您的應用程序一起使用的每種CPU架構指定一個ABI（Application Binary Interface）。
ABI 包含以下信息：
- 可使用的 CPU 指令集（和擴展指令集）。
- 運行時內存存儲和加載的字節順序。Android 始終是 little-endian。
- 在應用和系統之間傳遞數據的規範（包括對齊限制），以及系統調用函數時如何使用堆棧和寄存器。
- 可執行二進制文件（例如程序和共享庫）的格式，以及它們支持的內容類型。Android 始終使用 ELF。
- 如何重整 C++ 名稱。
Android目前支持以下7種ABIs:
mips, mips64, X86, X86–64, arm64-v8a, armeabi, armeabi-v7a
2. ABI有何作用？
當我們想要在項目中使用 native（C/C++） 類庫,我們必須對要支持的處理器架構提供對應編譯包。每個處理器架構需要我們提供一個或多個包含native代碼的.so文件。
默認情況下，爲了使APP有更好的兼容性，我們使用Android Studio 或者命令打包時，會默認支持所有的架構，但相應的APK size 會瘋狂的增大。對於用戶來說，目標設備只需要其中一個版本，但當用戶下載APK時，會全部下載（對用戶來說相當的不友好）。
怎麼辦呢？abifilters 爲我們提供瞭解決方案,abifilters爲我們提供了選擇適配指定CPU架構的能力，只需要在app下的build.gradle添加如下配置：
android {
defaultConfig {
ndk {
abiFilters 'arm64-v8a', 'x86_64'
}
}
}
你可能看了上面的這些文字，還不能理解abi的作用，那麼我們就用一個簡單的例子來說明一下。
2.1 舉例說明ABI的作用
首先，我們創建一個最簡單的Hello world應用，只有一個Activity和一個啓動圖標。我們看以下打出來的apk:
沒有任何的原生庫使用，大小爲2.1MB，現在我們爲它添加多ABI原生庫支持，我們在項目中集成Realm，然後打包。
看到沒，apk大小從2.1MB猛增加到11.2MB,多了一個原生so庫的文件夾，大小爲8.8MB，我們來看一下它的詳細信息：
如上圖所示，Realm爲5種CPU架構生成了.so庫，分別是mips、x86、x86_64、arm64-v8a、armeabi-v7a。增加了8.8MB包的大小。但是這不是我們想要的，我們只想要適配我們指定的的CPU架構，因此，我們需要在gralde.build中添加abifilters配置來完成我們想要的效果：
android {
compileSdkVersion 28 // 編譯sdk版本
defaultConfig {
applicationId "com.example.zhouwei.helloworld"
minSdkVersion 15
targetSdkVersion 28
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
// 適配指定CPU架構
ndk {
abiFilters 'arm64-v8a', 'x86_64'
}
}
}
效果如下：
可以看到，只生成了我們指定CPU架構的so文件，包的大小也減少了5.3MB。
這時候，你可能會有一個疑問，Android 共支持7種CPU架構，那麼，我們在實際項目中該適配哪些CPU架構能保證最好的兼容，同時又最大限度的減少APK的大小？
在回答這個問題之前，我們不妨看一下這些頂級巨頭公司，他們是是如何適配的。
3. 目前大廠APP是如何適配不同的CPU架構的？
首先，我們下載一些大廠的APK，看一下他們的適配情況，這裏我分析了微信、手機QQ、支付寶和淘寶這4個APP的適配情況：
可以看到，微信適配的是arm64-v8a(微信應該是最近才適配到arm64-v8a,以前是armeabi),支付寶和手Q適配的是armwabi，淘寶適配的是armwabi-v7a。各個APP適配的平臺不太一樣，但是他們有一個共同點，那就是它們只指定了一個平臺。
等等，上面這些APP只適配了一中CPU架構，比如只適配了armwabi-v7a,那如果APP裝在其他架構的手機上，如arm64-v8a上，會蹦嗎？
要弄清楚這個問題，我們得先搞清楚，ABI是如何工作的。
ABI是如何工作的呢？
官方文檔解釋如下：
Android 系統在運行時知道它支持哪些 ABI，因爲版本特定的系統屬性會指示：
- 設備的主要 ABI，與系統映像本身使用的機器代碼對應。
- （可選）與系統映像也支持的其他 ABI 對應的輔助 ABI。
此機制確保系統在安裝時從軟件包提取最佳機器代碼。
爲實現最佳性能，應直接針對主要 ABI 進行編譯。例如，基於 ARMv5TE 的典型設備只會定義主 ABI：armeabi。相反，基於 ARMv7 的典型設備將主 ABI 定義爲 armeabi-v7a，並將輔助 ABI 定義爲 armeabi，因爲它可以運行爲每個 ABI 生成的應用原生二進制文件。
64 位設備也支持其 32 位變體。以 arm64-v8a 設備爲例，該設備也可以運行 armeabi 和 armeabi-v7a 代碼。但請注意，如果應用以 arm64-v8a 爲目標，而非依賴於運行 armeabi-v7a 版應用的設備，則應用在 64 位設備上的性能要好得多。
許多基於 x86 的設備也可運行 armeabi-v7a 和 armeabi NDK 二進制文件。對於這些設備，主 ABI 將是 x86，輔助 ABI 是 armeabi-v7a。
上面這一段是不是有點看蒙了，這裏我來簡單解釋以下。總的來說，就是一個Android設備可以支持多種ABI,設備主ABI和輔助ABI,以arm64-v8a爲主ABI的設備，輔助ABI爲armeabi-v7a和armeabi，以armeabi-v7a爲主ABI的設備，輔助ABI爲armeabi。
另外，x86 架構的手機都會包含由 Intel 提供的稱爲 Houdini 的指令集動態轉碼工具，實現對 arm .so 的兼容，也就是說有適配armeabi平臺的APP是可以跑在x86手機上的。
3.1 主輔助ABI具體適配流程
前面說了ABI的工作原理，一個Android設備支持主輔ABI,那麼他們具體是如何工作的呢？我們以arm64-v8a架構的手機爲例：
對於一個cpu是arm64-v8a架構的手機，它運行app時，進入jnilibs去讀取庫文件時，先看有沒有arm64-v8a文件夾，如果沒有該文件夾，去找armeabi-v7a文件夾，如果沒有，再去找armeabi文件夾，如果連這個文件夾也沒有，就拋出異常；
如果有arm64-v8a文件夾，那麼就去找特定名稱的.so文件，注意：如果沒有找到想要的.so文件，不會再往下（armeabi-v7a文件夾）找了，而是直接拋出異常。
Exception:Java.lang.UnsatisfiedLinkError: dlopen failed: library “/***.so” not found
特別需要注意的情況是在命中了文件夾，而未命中so文件這種情況：
-
比如命中了
arm64-v8a文件夾，沒有找到需要的so文件，就不會再往下（armeabi-v7a文件夾）找了，而是直接拋出異常。 -
如果你的項目用到了第三方依賴，如果只保留一個ABI的時候，建議在Build中加入ndk.abiFilters
-
例如：第三方aar文件，如果這個sdk對abi的支持比較全，可能會包含armeabi、armeabi-v7a、x86、arm64-v8a、x86_64五種abi，而你應用的其它so只支持armeabi、armeabi-v7a、x86三種，直接引用sdk的aar，會自動編譯出支持5種abi的包。但是應用的其它so缺少對其它兩種abi的支持，那麼如果應用運行於arm64-v8a、x86_64爲首選abi的設備上時，就會crash了哦。
因此，我們需要在我們的app中配置 abiFilter 配置，來避免一些未知的錯誤。
defaultConfig {
ndk {
abiFilters "armeabi"// 指定ndk需要兼容的ABI(這樣其他依賴包裏x86,armeabi,arm-v8之類的so會被過濾掉)
}
}
3.2 Android 7種CPU架構在當前市場的佔有率
-
arm64-v8a: 目前主流版本 -
armeabi-v7a: 一些老舊的手機 -
x86 / x86_64: x86 架構的手機都會包含由 Intel 提供的稱爲 Houdini 的指令集動態轉碼工具，實現對 arm .so 的兼容，再考慮 x86 1% 以下的市場佔有率，x86 相關的兩個 .so 也是可以忽略的 -
armeabi/mips / mips64: NDK 以前支持 ARMv5 (armeabi) 以及 32 位和 64 位 MIPS，但 NDK r17 已不再支持，極少用於手機可以忽。
目前手機市場上，x86 / x86_64/armeabi/mips / mips6 的架構，基本可以不不考慮了，它們的佔有量應很少很少了，arm64-v8a作爲最新一代架構，應該是目前的主流，armeabi-v7a只存在少部分老舊手機。
我試着在Google上查找，具體的市場佔有數據，但沒找到，但是從國民級應用微信只適配arm64-v8a就可以看出，arm64-v8a是目前的主流，並且還有一點，Google Play 從2019年8月開始，就強制APP適配arm64-v8a，以慢慢淘汰32位的armeabi-v7a。
4. 我們項目中該如何適配呢？
這裏就可以回答前面的兩個問題了。
Q1： 只適配了armwabi-v7a,那如果APP裝在其他架構的手機上，如arm64-v8a上，會蹦嗎？
A: 不會，但是反過來會。
因爲armwabi-v7a和arm64-v8a會向下兼容：
- 只適配
armeabi的APP可以跑在armeabi,x86,x86_64,armwabi-v7a,arm64-v8上 - 只適配
armwabi-v7a可以運行在armwabi-v7a和arm64-v8a - 只適配
arm64-v8a可以運行在arm64-v8a上
那我們該如何適配呢？給出如下幾個方案：
方案一：只適配armeabi
-
優點:基本上適配了全部CPU架構（除了淘汰的mips和mips_64） -
缺點：性能低，相當於在絕大多數手機上都是需要輔助ABI或動態轉碼來兼容
方案二：只適配 armwabi-v7a
同理方案一，只是又篩掉了一部分老舊設備,在性能和兼容二者中比較平衡
方案三: 只適配 arm64-v8
-
優點:性能最佳 -
缺點：只能運行在arm64-v8上，要放棄部分老舊設備用戶
這三種方案都是可以的，現在的大廠APP適配中，這三種都有，大部分是前2種方案。具體選哪一種就看自己的考量了，以性能換兼容就arm64-v8,以兼容換性能armeabi,二者稍微平衡一點的就armwabi-v7a。
目前來說，大多數的大廠APP用的都是armeabi或armwabi-v7a，只有像微信這種牛逼的APP,爲了追求性能和用戶體驗，放棄了少部分設備，這也說得通吧，畢竟微信也不在乎蒼蠅那點肉。
5.番外篇-性能+兼容能否兼得？
其實到上一小節，本文就該結束了，但總感覺優點意猶未盡，除了適配所有全部CPU架構外，就特麼不能性能和兼容同時兼得嗎？其實Google早有考慮。也是可以實現的那就是 abi split，分包，實現也很簡單，在gradle 中添加如下配置：
android {
...
splits {
// Configures multiple APKs based on ABI.
abi {
// Enables building multiple APKs per ABI.
enable true
// By default all ABIs are included, so use reset() and include to specify that we only
// want APKs for x86 and x86_64.
// Resets the list of ABIs that Gradle should create APKs for to none.
reset()
// Specifies a list of ABIs that Gradle should create APKs for.
include "x86", "x86_64", "arm64-v8a", "armeabi", "armeabi-v7a"
// Specifies that we do not want to also generate a universal APK that includes all ABIs.
universalApk false
}
}
}
然後，就能爲每個CPU架構單獨打一個APK，該apk 中就只包含一個平臺，如下：
這樣，又能保證性能，又能不額外增加APK的大小，同時又又很完美的兼容，因爲可以爲所有架構都單獨打一個包，一舉多得。
同時，Google Play 支持上傳多個APK:
這樣，就能根據不同的CPU架構，下載不同的包啦！
但是，但是，但是，很遺憾，國內的應用商店目前還不支持！
參考文章
- https://www.diycode.cc/topics/691
- https://developer.android.com/ndk/guides/abis
- https://android.jlelse.eu/controlling-apk-size-when-using-native-libraries-45c6c0e5b70a
以上就是本文的全部內容，如有錯誤，歡迎評論區指出。原創不易，如果你喜歡本文，歡迎點贊、轉發、收藏三連一下。
另外歡迎關注我的公衆號「技術最TOP」,每天都有優質技術文章推送。