与 so 有关的一个长年大坑

关注

转载最新推荐文章于 2026-08-24 19:04:42 发布 1k 阅读 AI 写同款· GEO 优化 ›

AlphaPose复现配置教程 AlphaPose是一种准确的多人姿态估计器，这是第一个在COCO数据集上达到70+ mAP (75 mAP)和在MPII数据集上达到80+ mAP (82.1 mAP)的开源系统。为了匹配跨帧的同一人的姿态，我们还提供了一种高效的在线姿态跟踪器，称为Pose Flow。这是第一个在PoseTrack挑战数据集上达到60+ mAP (66.5 mAP)和50+ MOTA (58.3 MOTA)的开源在线姿态跟踪器。AlphaPose支持Linux和Windows操作系统！指路👉。阅读详情

Android 应用开发中不可避免的会引入第三方的代码。如果是开源项目风险相对可控，如果引入商用的 SDK 那就要谨慎了，难免会有这样或那样的问题。比如我们今天要说的这一个。

对集成过第三方 SDK 的同学，上图中的目录结构应该不陌生。正常情况下我们只需要将不同版本的 so 文件分别放置。但如果我们要集成的这个第三方 SDK 偏偏没有 arm-v7a 的版本呢？是删除 armeabi-v7a 目录只保留 armeabi ？还是说两个目录下 .so 文件数不同也没有关系？系统会加载哪个 .so 呢？

如果只对结论感兴趣可以直接跳到最后

为了方便说明我们先引入 FAT Binary 的概念。我们知道不同的 CPU 支持的指令集也不一样，那么如果我们需要让 App 尽可能不同的 CPU 上都可以正常运行该怎么做呢？简单，只需要将不同版本的 Binary 放在一个文件里，运行时按需取用就可以了。这就是 FAT Binary 的典型实现。Android 实现 FAT 的方式有些不同，就是上边提到的将 .so 文件放置在相应文件夹中。在 Android 系统中 ndk 默认会生成如下 7 种 so。

在 apk 文件中带这么多版本的 .so 是一种很不经济的做法：

mips / mips64: 极少用于手机可以忽略
x86 / x86_64: x86 架构的手机都会包含由 Intel 提供的称为 Houdini 的指令集动态转码工具，实现对 arm .so 的兼容，再考虑 x86 1% 以下的市场占有率，x86 相关的两个 .so 也是可以忽略的
armeabi: ARM v5 这是相当老旧的一个版本，缺少对浮点数计算的硬件支持，在需要大量计算时有性能瓶颈
armeabi-v7a: ARM v7 目前主流版本
arm64-v8a: 64位支持

这样我们就可以明确 mips, mips64, x86, x86_64 这 4 个 .so 我们是不需要的。

我们回到开头提到的问题：

假定我们现在的情况是这样的（b.so 就是那个只有 armeabi 版本的第三方 so）：

如果这样放置的话，在 ARM / ARM v7 两种设备上运行 apk 时会分别执行哪个 so 呢？

答案是：不确定……

这么坑爹的答案是怎么来的呢？

由于 Android 上 FAT binrary 的设计如此阳春，在 apk 安装时就需要根据 CPU 情况执行对应版本 so 的拷贝。对上边的情况最合理的一种做法应该是使用 armeabi-v7a/a.so 和 armeabi/b.so 这两个文件。Google 最初也是这么想的，然后就引入了 Bug…

Native library copy issue when install apk with different abi native libraries on device