承接上一篇《代码混淆与 R8：压缩优化的坑》讲完的代码线，这一篇补上第三条线：原生库。so 库是包体积里最"硬"的一块——它不能像代码那样被 R8 收缩，也不能像资源那样被shrinkResources剔除，只能靠分发侧裁剪与构建侧裁剪两条路减少。更棘手的是：so 出了问题是运行时的UnsatisfiedLinkError或dlopen failed，往往要到特定机型、特定系统版本才暴露。
结论先行：AAB 时代的第一步是把"多 ABI 全打"改成"按设备下发"；第二步才是找 SDK 厂商要定制包或用裁剪工具处理用不到的编解码变体。顺序反了就是白干。
so 库的四类来源
先归因。App 里的 so 通常来自四个地方：
| 来源 | 典型体积（单架构） | 裁剪难度 | 说明 |
|---|---|---|---|
| 自研 JNI 模块 | 数百 KB~数 MB | 低 | 自主可控 |
| 图像/编解码库 | 2~8 MB | 中 | 裁剪编码格式可省很多 |