在使用so库的时候遇到一个问题，背景如下：
项目中有一个录像功能，将录像功能抽取出来变成一个module，这个module引入了一个ffmpeg的so库，将录像功能集成后经测试好用。
后来项目中需要集成定位功能，使用了高德定位，定位功能没有抽取，而是直接写在app中。此时再次点击录像后发生crash，报出如下错误：
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader
既在Load库的时候找不到so文件。
主app中引入so的时候分别放在了 arm64-v8a 和 armeabi 中，录像module引入的so放在armeabi-v7a中。
看下这三个文件夹的作用：
arm64-v8a是可以向下兼容的，其下有armeabi-v7a，armeabi ；armeabi-v7a向下兼容armeabi。对于一个cpu是arm64-v8a架构的手机，它运行app时，进入jnilibs去读取库文件时，先看有没有arm64-v8a文件夹；如果没有该文件夹，去找armeabi-v7a文件夹，如果没有，再去找armeabi文件夹，如果连这个文件夹也没有，就抛出异常
如果有arm64-v8a文件夹，那么就去找特定名称的.so文件，注意：如果没有找到，不会再往下（armeabi-v7a文件夹）找了，而是直接抛出异常。
将生成的apk解压，发现lib下有三个文件夹，分别对应以上三种cpu架构，而我们的录像so只在armeabi-v7a中。也就是说系统只在arm64中寻找录像so，找不到自然就报错了。
然后尝试将录像so放入主app的arm64-v8a中，这样同样会出现个问题：
.依赖Module引入的so库必须存放在该module本身的jnilib目录下，而不能放入app Module的库目录下。否则报错。
既然这样不行拿就在录像Module下建立一个arm64-v8a目录，此时如果你有so支持64位处理器的话没有问题，如果只有32位的so同样不行。
最后的解决方案是把app Module目录下的arm64目录改为armeabi-v7a，录像Module中的结构保持不变，使得系统在加载so库的时候直接到armeabi-v7a中寻找。解决问题。