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

一、名词解析

二、32位与64位CPU区别

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

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

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

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

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

五、.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库适配关键注意事项

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

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

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

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

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

实现方式（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包，因此该方案在国内场景下实用性有限。

八、总结与未来趋势

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

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