插件框架篇一之插件so库的加载

问题：插件中的so无法通过System.loadLibrary加载。

问题分析：
在System.loadLibrary函数中通过Runtime.getRuntime().loadLibrary(libName, VMStack.getCallingClassLoader())加载so库，其中VMStack.getCallingClassLoader()获取的是加载当前插件类的ClassLoader，而加载插件的ClassLoader是新创建的DexClassLoader实例，相对独立于主工程的ClassLoader。
DexClassLoader dexLoader = new DexClassLoader(String dexPath, String optimizedDirectory, String libraryPath, ClassLoader parentLoader);
其中dexPath是apk/jar的路径；
optimizedDirectory是解压后dex的存放路径；
libraryPath是library的存放路径；
parentLoader是父ClassLoader;

结合《System.loadLibrary() 加载so原理分析》篇，我们可以看出在加载so库之前需要通过ClassLoader的findLibrary函数生成so库的path，而ClassLoader根据libraryPath来生成path，并通过nativeLoad()加载so库。

解决方案：
由以上分析可以得出插件apk中so库无法加载，所以可以通过以下两种方式解决问题：
1、解压apk中so库到其他存储文件中，并通过System.load(String path)进行全路径加载；
2、将插件so库分离到主工程libs中，并设置加载插件的DexClassLoader的libraryPath为主工程的安装路径中native库位置：
DexClassLoader dexLoader = new DexClassLoader(String dexPath, String optimizedDirectory, String context.getApplicationInfo().nativeLibraryDir, ClassLoader parentLoader);

比较以上两种方案，各有优缺点，但第二种相对简单，并且适合无法修改源码的第三方库的插件化。