贝壳&掌链64位架构适配实践

Android项目开发的时候经常会使用到so文件，例如使用百度地图，其SDK中就包含了armeabi、armeabi-v7a、arm64-v8a、x86、x86_64等其他文件夹，里面通常放着同样名称、同样数量的so文件。实际使用过程中，目前仅使用了32位库（即armeabi的支持），随着科技发展和硬件指标的提升，对于64位的适配支持也需提上日程。添加 64 位的应用版本不仅可以提升性能、为未来创新创造条件，还能针对仅支持 64 位架构的设备做好准备。

不同Android设备，使用的CPU架构可能不同，因此支持不同的指令集。CPU 与指令集的每种组合都有其自己的应用二进制接口（ABI），ABI非常精确地定义了应用程序的机器代码应如何在运行时与系统交互。因此，必须为每个应用程序一起使用的每种CPU架构指定一个ABI。Android目前支持以下7种ABIs：

手机ARM是一种CPU架构，值得一提的是，ARM公司并不生产芯片，只提供一个芯片设计的Idea。常见的芯片厂商：高通、三星、联发科、麒麟、苹果、Intel、Nvidia。

so（shared object）共享的对象，是机器可以直接运行的二进制代码，是Android上的动态链接库。每一个Android应用所支持的ABI是由其APK提供的.so文件决定的，Android Studio中这些so文件被打包在jniLibs/ABI目录中，如下图所示（百度地图示例代码）。

使用so的目的：

1.so机制让开发者最大化利用现有的C和C ++代码，达到重用的效果，利用软件世界积累了几十年的优秀代码；

2.so是二进制，没有解释编译的开消，用so实现的功能比纯java实现的功能要快；

3.so内存分配无限制Dalivik / ART的单独应用限制，减少了OOM；

4.相对于Java代码，二进制代码的反编译难，一些核心代码可以考虑放在其中。

当我们想要在项目中使用native（c/c++）类库时，我们必须为要支持的处理器架构提供对于的编译包。例如：armeabi-v7a架构的处理器，需要为其准备该架构下能使用的so包。

默认情况下，android studio打包时，会默认支持所有的架构，这样兼容性就会达到最大化，但随之而来的问题是包大小会剧增。为了在包大小和兼容性之间进行取舍，我们需要在app下的build.gradle指定abifilters。一般如下：

android {
    defaultConfig {
        ndk {
            abiFilters 'arm64-v8a', 'armeabi-v7a', // 其他继续添加如：armeabi,x86,x64等...
        }
    }
}

不考虑包大小的情况下，为什么选择armeabi-v7a或者arm64-v8a呢？这个就和你的应用需要发布的主流设备有关了，目前来说，手机设备都是支持armeabi、armeabi-v7a或者arm64-v8a的，极少的有x86、x86x64，若只需要支持主流手机，仅需要armeabi-v7a和arm64-v8a足够了。有同学要问了，那么为什么不直接用armeabi呢？那样的话在所有设备上都能跑。

确实是这样，armeabi的ABIs可以在所有设备上跑，但是对于一些已经支持armeabi-v7a和arm64-v8a设备来说，无疑是一种性能的浪费。

需要在性能和兼容性之间进行一定的取舍。

值得一提的是，自 2019 年 8 月 1 日起，在 Google Play 上发布的应用必须支持 64 位架构。国内的五大移动应用商店（小米应用商店、OPPO 软件商店、vivo 应用商店、腾讯应用宝、百度手机助手）也在近日宣布：2021年12月底，现有和新发布的应用/游戏，需上传包含64位包体的APK包；2022年8月底，硬件支持64位的系统将仅接收含64位版本的APK包；2023年底，硬件仅支持64位APK，32位应用无法在终端上运行。

总结起来，就是：

1.只适配armeabi的APP可以跑在armeabi,x86,x86_64,armeabi-v7a,arm64-v8a所有设备上

2.只适配armeabi-v7a的APP可以运行在armeabi-v7a和arm64-v8a上

3.只适配arm64-v8a 的APP只可以运行在arm64-v8a上

以硬件设备角度来看（向下兼容）：

1.arm64-v8a的设备可以跑适配了armeabi、armeabi-v7a和arm64-v8a的应用

2.armeabi-v7a的设备可以跑适配了armeabi、armeabi-v7a的应用

确定了适配方案，那么就该动手找齐armv8-64a的so包了。先看下现状如下图(仅展示了部分，SO名称有打码处理)，贝壳2.56.0正式版，一共是45个so库，我们需要对所有的so文件找到对应的armv8-64a的so包。

由于历史原因，目前贝壳引入的依赖库多达83个，从这80多个依赖中找齐这45个so包，人工统计无疑是个沉重的体力劳动，为此，解决思路应该是：

1.先自动化的从APK中获取所有的so，并且找到该so的加载位置；

2.由于插件化的原因，有些so的使用方可能在插件中，也需要将插件的代码加入到查找路径；

3.对主工程配置abiFilters属性让其支持armeabi、armeabi-v7a和arm64-v8a三种架构，然后打出相应包，进行解压查看（在armeabi-v7a和arm64-v8a文件夹中补充相对armeabi文件夹缺失的so包，正式使用时删除对armeabi的支持)；

4.通过查找结果，顺利的找到so包对应的第三方库，找到库的维护者，升级该库；

5.重复第3步，直到armeabi、armeabi-v7a和arm64-v8a文件夹里面的so文件一致。

1.对于APK文件，我们通过jadx工具进行反编译即可。

2.由于我们工程是插件化的，主工程解压后，插件以jar形式存放在asset/plugins目录下，这些jar本质上也是apk，所以在对主工程解压后，先对jar重命名为apk，然后对这些apk继续使用jadx进行处理。

这一步相对简单很多，只需要将所有的so列表对每行源码进行加载比对即可。需要注意的是，so在使用的时候，会去掉前缀lib和后缀.so，所以搜索的关键字也需要注意处理下。

通过找到so的使用文件，进而可通过该文件的全路径包名找到对应的第三方库（这个使用配置即可映射即可）。

通过遍历lib文件夹，对比armeabi、armeabi-v7a、arm64-v8a等文件夹内so文件的数量差异，可找到缺少的so名称。通过2.3.4我们已经找到所有so包的归属，所以很顺利就能找到我们需要更新的第三方库。

完成上述的自动化能力后，想要对更多的业务APP方赋能，就必须让能力平台化。

我们将该能力搭载在雪豹平台上，能通过上传Android APK包到雪豹平台，都能对APP进行分析，输出分析报告，帮助寻找缺失的so包。

分析流程示意图如下：

平台界面截图：

app适配64位将是未来趋势，通过平台自动化的找到需要更新的第三方库，能显著提高我们适配64位的效率。

最后，特别感谢卫玉（村支书）、文龙（月风得）、黄卉（对月）、高兴（吉多多）和kemis小组的大力支持，帮助我在技术实现过程中扫清了障碍，为雪豹64位对齐平台功能完善贡献了重要力量。