未打包libc++_shared.so时libSNPE.so可运行的原因及验证方法

是的，你的推测大概率是正确的——libSNPE.so在运行时确实可能链接了Android系统路径下的/system/lib64/libc++.so，而非你未打包的libc++_shared.so。

可能的原因 #

高通提供的预编译libSNPE.so在编译阶段，可能被配置为直接依赖系统的libc++.so（而非NDK的libc++_shared.so）。Android系统从API 21开始自带libc++.so作为系统标准C++库，部分厂商预编译的第三方库会选择依赖这个系统库以减少打包体积，或者确保与系统环境的兼容性。

验证方法 #

你可以通过以下几种方式确认具体的依赖情况：

1. 分析静态依赖（电脑端操作）

使用readelf工具查看libSNPE.so的动态依赖项：

readelf -d libSNPE.so | grep NEEDED

如果输出中包含libc++.so，说明该库编译时就指定了依赖系统库；如果是libc++_shared.so，那可能是Android系统中存在该库的全局副本，或者动态加载器做了 fallback 处理。

2. 查看运行时加载的库（Android设备端操作）

• 首先找到你的应用进程PID：

  ps | grep 你的应用包名
  

• 然后查看进程加载的所有库路径：

  cat /proc/<PID>/maps | grep libc++
  

  或者使用pmap工具：

  pmap -x <PID> | grep libc++
  

  输出结果中如果显示路径为/system/lib64/libc++.so，则确认是链接了系统库；如果是应用私有目录下的路径，说明是你打包的库被加载了。

3. 通过Android Studio Profiler验证

打开Android Studio的Profiler工具，连接到你的设备和应用进程：

• 切换到「Memory」标签页，选择「Native Memory」
• 在加载的库列表中找到libc++相关条目，查看其文件路径，即可确认是系统库还是应用自带的库。

注意事项 #

虽然当前程序能正常运行，但依赖系统libc++.so存在兼容性风险：不同Android版本的系统libc++版本差异较大，若libSNPE.so依赖较高版本的C特性，在低版本Android设备上可能出现崩溃或运行异常。建议优先遵循NDK官方文档的要求，打包对应的libc++_shared.so，同时可以查阅高通SNPE的官方文档，确认其推荐的C库依赖方式。

内容的提问来源于stack exchange，提问作者Umar Karim