android 动态库获取路径问题,一种Android App在Native层动态加载so库的方案

这篇文章通过实战案例，介绍了一种有条理的组织Native层代码层级结构的方法。并且，在良好的代码层级、作用分工的基础上，实现了动态的按需加载、卸载so库。文章的最后，还介绍了实践过程中遇到的困难以及对应的解决方案，能让读者少走弯路。 — 责任编辑 wingyipye

1. 为什么在Native层动态加载so库

随着Android App发展的不断变化，App的性能和系统API框架外的功能拓展显得越来越重要。App从性能方面考虑，需要在Native层使用C/C++实现的方案，Native层再通过JNI的方式提供方案给实现应用基本功能的Java层调用，来拓展一些计算密集型的功能。例如App如果要支持播放手机自身不支持播放的音频格式，就需要在Native层实现App自己的音频解码功能。

随着项目规模的增大，Native层的代码规模也逐渐膨胀起来。为了更清晰的组织代码，Native层之间也会按照模块分别构建成独立的so库。其中为了简化Java层与Native层之间的通信方式，通常会特地使用一个JNI层so库引用其他实现具体功能的功能实现so库。Java层只加载这个JNI层so库，来间接调用功能实现so库。

so库之间通过引用头文件和运行时指定共享库依赖的方式形成了依赖关系。但是这种简单的模块划分方式存在着一些问题：

应用上层的热修复方案需要so库能够支持被动态加载，这样出现问题的so库才能够在应用运行的时候先被替换为修复问题的库文件然后才被加载。对于Java层直接引用的so库，动态加载可以使用Java层的系统API提供的方法System.load()或者System.loadLibrary()方式实现。然而对于功能实现的so库，是通过JNI层so库被Java层间接引用的，自身没有直接与Java层对接的JNI函数。所以对于功能实现so库，无法再使用Java层动态加载的方法。

加载JNI层so库的时候，即使这次JNI调用有些功能实现so库里面的数据结构或函数没有被调用到，只要这个so库被JNI层so库声明为运行时需要依赖的共享库，也需要跟JNI层so库一起被加载，这无形中也增大了Native层的常驻内存。

为了解决这些问题，就不能再使用Java层动态加载so库的方法，而需要在Native层直接动态加载so库，由JNI层so库动态加载功能实现so库。被加载的so库可以声明一些不能轻易增删和