Android 原生库架构的基础概念
为什么看 .so 文件
LibChecker 最初的功能就是查看应用的 32 位 / 64 位状态。这里的关键是：Java 和 Kotlin 代码跑在 Android Runtime（ART）之上，本身不涉及架构。真正有架构问题的是用 C/C++ 写的原生代码——它们编译后会生成 .so 文件，必须对应到特定的指令集。
所以通常所说"一个 App 是 64 位"，实际意思是它引入的原生库全部或部分支持 64 位架构。完全没有 .so 文件的 App 处于"无原生库"状态，讨论它是 32 位还是 64 位没有意义。
主流 ABI 架构
| ABI | 处理器代际 | 说明 |
|---|---|---|
| armeabi-v7a | ARMv7+ | 2011 年后绝大多数 Android 设备使用 |
| arm64-v8a | ARMv8+ | 近年旗舰机型的主流 |
| arm64-v9a | ARMv9 | 新一代 64 位 ARM |
| armeabi | ARMv5/v6 | 早期手机，已淘汰 |
| x86 | IA-32 | 平板、模拟器 |
| x86_64 | AMD64 | 64 位平板、模拟器 |
CPU 与 ABI 的关系
CPU 通常向前兼容，但选择 .so 时有优先级规则。ARMv8 设备会优先装载 arm64-v8a 目录下的 .so 文件；如果没有 arm64-v8a 才退化到 armeabi-v7a；最后才是 armeabi。
LibChecker 应用列表里的架构标签就是扫描了 APK 里的 lib/ 目录结构后得出的：
- 无原生库：没有任何 .so 文件
- 32 位：只有 armeabi / armeabi-v7a / x86
- 64 位：只有 arm64-v8a / arm64-v9a / x86_64
- 多架构：同时包含 32 位和 64 位目录
32 位兼容的代价
ARMv8+ 设备虽然能运行 32 位 .so 文件，但需要通过兼容层，会带来性能损失和额外的内存开销。Google Play 早在 2019 年就强制要求新上架应用支持 64 位。