文章首发于公众号「 技术最TOP 」，每天都有干货文章继续更新，能够微信搜寻「 技术最TOP 」第一工夫浏览！

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...
  • https://developer.android.com...
  • https://android.jlelse.eu/con...

以上就是本文的全部内容，如有谬误，欢送评论区指出。原创不易，如果你喜爱本文，欢送点赞、转发、珍藏三连一下。