abiFilters是Gradle中用于显式指定仅打包特定ABI架构so库的配置项，作用于defaultConfig.ndk下，通过剔除未声明ABI目录来减小APK/AAB体积；相比splits.abi生成多APK，它更轻量、可控且兼容AAB上传要求。
直接用 abiFilters 就能精准控制 APK/AAB 里塞哪些 ABI 的 so 库，这是最常用也最有效的手段。
abiFilters 是什么，为什么它比 splits 更适合日常控制
abiFilters 是 Gradle 构建脚本中用于显式声明「只打包指定 ABI 架构的 native 库」的配置项，作用于 android.defaultConfig.ndk 或 android.buildTypes.*.ndk 下。它不生成多个 APK，而是在单个构建产物中剔除未列出的 ABI 目录（如 lib/armeabi-v7a/），从而减小体积。
相比 splits.abi（会拆出多个 APK），abiFilters 更轻量、更可控，适合绝大多数上线场景——尤其当你明确知道目标设备覆盖范围时。
- 只影响最终 APK/AAB 的
lib/目录内容，不影响 Java/Kotlin 代码或资源 - 不会触发多 APK 分发逻辑，兼容 Google Play 的 AAB 上传要求
- 若第三方 SDK 提供了多个 ABI 的 so，但你只留
arm64-v8a，Gradle 会静默跳过其他架构，不报错也不警告 - 注意：
abiFilters不会帮你编译缺失的 ABI，它只是“过滤已有库”；如果工程里根本没生成arm64-v8a的 so，APK 里就真没这个目录
怎么在 build.gradle 中正确配置 abiFilters
必须写在 android.defaultConfig.ndk 块里，否则无效。常见错误是把它放在 defaultConfig 根层级，或误写成 abiFilter（少个 s）。
android {
defaultConfig {
// 其他配置...
ndk {
abiFilters 'arm64-v8a' // ✅ 只打包 arm64-v8a
// abiFilters 'arm64-v8a', 'armeabi-v7a' // ✅ 双架构
// abiFilters 'x86_64' // ⚠️ 模拟器可用，但线上设备基本用不到
}
}
}
- 值必须是字符串字面量，用单引号，不能是变量或表达式（如
'${targetAbi}'会失败） - 支持的值严格匹配 NDK 官方命名：
arm64-v8a、armeabi-v7a、x86_64、x86；armeabi已被 NDK r17+ 移除，设了也无效 - 如果同时用了
splits.abi和abiFilters，后者优先级更高，但二者混用容易引发混淆，不建议
ABI 过滤后常见的崩溃和排查点
加了 abiFilters 却仍出现 UnsatisfiedLinkError，大概率不是配置问题，而是底层依赖没对齐。
- 错误现象：
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader couldn't find "libxxx.so"，但你在 APK 的lib/arm64-v8a/里明明看到了这个文件 → 实际是依赖的某个间接 so（比如某 SDK 的子模块）只提供了armeabi-v7a版本，被abiFilters删掉了 - 检查方法：解压 APK，进
lib/目录看是否真有对应 ABI 子目录；再用file lib/arm64-v8a/libxxx.so确认它是真正的 arm64 二进制（不是空文件或符号链接） - 第三方 SDK 问题：某些老 SDK（如旧版百度地图、极光推送）只提供
armeabi-v7a，你强制只打arm64-v8a就会挂；此时要么升级 SDK，要么放宽abiFilters，或联系厂商要新版 - NDK 编译遗漏：如果你自己写了 C/C++ 代码，
externalNativeBuild配置里没指定APP_ABI := arm64-v8a，那即使abiFilters写了，也没东西可包
arm64-v8a 单架构是否足够？要不要保留 armeabi-v7a
截至 2026 年，纯 arm64-v8a 对绝大多数真实用户已足够，但得看你的数据底线。
- 市场占比：arm64-v8a 设备占 92%，armeabi-v7a 剩余约 7%（集中在低端机型、老年机、部分海外新兴市场）
- Google Play 强制要求：自 2021 年起，新上架应用必须提供 64 位版本；2023 年起，更新也需含 64 位，但未禁止同时带 32 位
- 性能代价：arm64 设备运行 32 位 so 会降频切换模式，实测启动慢 10%~15%，JNI 调用延迟增加
- 决策建议：新项目直接上
arm64-v8a；存量项目若 crashlytics 显示 armeabi-v7a 用户 crash 率
真正容易被忽略的是：ABI 过滤只管 so 文件，不管 Java 层是否做了架构适配判断。比如某段逻辑写了 if (Build.CPU_ABI.startsWith("armeabi"))，过滤掉 armeabi-v7a 后这段代码依然执行，可能触发空指针或路径错误——这类逻辑必须同步清理。
