【音视频】Android NDK 与.so库适配

一、名词解析

名词	全称	核心说明
Android NDK	Native Development Kit	在SDK基础上增加"原生"开发能力，支持使用C/C++编写代码，用于开发需要调用底层能力的模块（如音视频、加密算法等）
.so库	Shared Object	即共享库，由NDK编译生成的动态链接库，是底层功能（如音视频处理、核心算法）的载体，体积通常较大，对APK体积影响显著
ABI	Application Binary Interface	应用二进制接口，是一套规范，定义了二进制文件（如.so库）如何在特定CPU架构和操作系统上运行的规则
EABI	Embedded Application Binary Interface	嵌入式应用二进制接口，是ARM架构对ABI规范的优化实现（2005年推出），PowerPC架构也有对应的EABI实现

二、32位与64位CPU区别

32位和64位的本质是CPU通用寄存器（GPRs）的数据宽度，直接决定了CPU一次能处理的数据量、操作系统能力及软件兼容性，具体区别如下：

对比维度	32位CPU/操作系统	64位CPU/操作系统
寄存器宽度	32bit，一次可处理32位数据	64bit，一次可处理64位数据
设计初衷	面向普通用户，运行日常软件（如QQ、浏览器）	面向高性能需求场景（如机械设计、3D动画、视频编辑），需大量内存和浮点运算
软件兼容性	仅支持32位应用	兼容32位应用（过渡需求），原生支持64位应用
内存控制	实际可识别内存上限约3.5GB	实际可支持内存上限达128GB（甚至更高）

三、Android支持的CPU架构与市场占比

Android系统目前支持7种ABI，但多数架构因市场占比极低已被淘汰（如MIPS系列），实际开发中仅需关注ARM架构系列。

CPU架构	核心描述	市场占比	兼容性说明
arm64-v8a	第8代ARM架构，64位	目前主流（占比最高）	仅支持自身架构；可兼容运行armeabi-v7a、armeabi的32位应用（但会损失性能）
armeabi-v7a	第7代ARM架构，32位	少量老旧设备（2011年起大规模使用）	支持自身架构；可兼容运行armeabi应用（损失性能）；无法在arm64-v8a外的其他架构运行
armeabi	第5代ARM架构，32位	极少（可忽略）	NDK r17版本后不再支持；可在armeabi、x86、x86_64、armeabi-v7a、arm64-v8a架构上运行
x86 / x86_64	Intel架构，32位/64位	1%以下	包含Intel的Houdini指令集转码工具，可兼容ARM架构的.so库；因占比极低，通常无需适配
mips / mips64	MIPS架构，32位/64位	几乎为0（手机端极少使用）	NDK r17版本后不再支持，可完全忽略

四、大厂APP的.so库适配方案参考

主流大厂APP通常仅适配单一架构以平衡体积与兼容性，具体方案如下：

APP名称	适配的CPU架构	核心考量
微信	arm64-v8a	优先保证性能，面向主流设备
支付宝	armeabi	最大化兼容性（覆盖绝大多数老旧设备）
QQ	armeabi	同支付宝，优先兼容老旧设备
手机淘宝	armeabi-v7a	平衡性能与兼容性（淘汰极老旧设备）

五、.so库适配的3种方案

实际开发中需根据产品定位（如是否放弃老旧设备、是否追求性能）选择适配方案，三种方案的优缺点对比如下：

方案一：只适配 armeabi

优点：兼容性最强，可覆盖几乎所有非淘汰架构（除mips/mips64）
缺点：性能最低，绝大多数设备（如arm64-v8a、armeabi-v7a）需通过辅助ABI或动态转码兼容，存在性能损耗
适用场景：面向下沉市场，需覆盖大量老旧设备的应用（如工具类、低性能需求APP）

方案二：只适配 armeabi-v7a

优点：平衡性能与兼容性，淘汰极老旧的armeabi设备，性能优于armeabi方案
缺点：无法覆盖arm64-v8a设备的原生性能，仍需兼容运行
适用场景：对性能有一定要求，但仍需覆盖部分老旧设备的应用（如电商、社交类APP）

方案三：只适配 arm64-v8a

优点：性能最佳，原生支持64位设备，符合Google未来规划
缺点：兼容性最差，仅支持arm64-v8a架构，需放弃所有32位设备（armeabi、armeabi-v7a）用户
适用场景：新启动项目、对性能要求极高的应用（如音视频、游戏类APP）；需符合Google Play强制要求（2019年8月起强制适配arm64-v8a）

六、.so库适配关键注意事项

禁止混合架构使用

要么为所有架构提供对应的.so库，要么只适配单一架构。若同时存在多种架构（如armeabi和arm64-v8a），但某.so库仅存在于其中一个架构目录，会导致该架构设备加载.so库崩溃。
32位架构.so库通用性

armeabi与armeabi-v7a同属32位架构，二者.so库可通用（如项目适配armeabi，但第三方库仅提供armeabi-v7a的.so库，可直接使用）；但arm64-v8a（64位）与32位架构.so库完全不通用。
老旧第三方库的处理

部分无人维护的第三方库可能没有arm64-v8a架构的.so库，此时需二选一：①放弃arm64-v8a适配，选用32位架构方案；②替换为支持arm64-v8a的第三方库。

七、性能与兼容性兼得：ABI Split分包方案

Google提供ABI Split方案，可针对不同CPU架构单独打包APK，每个APK仅包含对应架构的.so库，既保证性能，又不增加APK体积。

实现方式（Gradle配置）

gradle 复制代码

android {
    ...
    splits {
        // 基于ABI配置多APK
        abi {
            // 启用ABI分包
            enable true
            // 重置默认ABI列表，仅保留需要适配的架构
            reset()
            // 指定需要适配的ABI（根据需求选择）
            include "armeabi", "armeabi-v7a", "arm64-v8a"
            // 禁止生成通用APK（仅生成对应架构的APK）
            universalApk false
        }
    }
}

局限性

Google Play支持：可上传多个架构的APK，用户下载时会自动匹配设备架构。
国内应用商店不支持：国内多数应用商店仅允许上传一个APK包，因此该方案在国内场景下实用性有限。

八、总结与未来趋势

趋势判断 ：Google已强制要求Google Play应用适配arm64-v8a，32位架构（armeabi、armeabi-v7a）逐步被淘汰，新项目建议优先适配arm64-v8a。
兼容性权衡：若需覆盖老旧设备，可选择armeabi-v7a方案；若完全面向主流设备，直接选择arm64-v8a方案。
体积控制：避免盲目添加多架构.so库，优先通过单一架构适配或ABI Split（海外场景）控制APK体积。

更多资料：https://github.com/0voice