AS中使用.SO库

错误提示部分代码：
java.lang.UnsatisfiedLinkError: Couldn’t load from loader dralvik.system.PathClassLoade[Dex

错误原因分析

可能原因1

自己项目中的.so库分配不全，例如项目中有armeabi，armeabi-v7a存放so文件的文件夹，如果armeabi中有a.so，那么armeabi-v7a也必须有a.so，CPU架构为armeabi-v7a才找得到a.so。

可能原因2

AndroidStudio使用jcenter或者maven关联第三方项目生成的.so时，由于自己项目存放的.so的路径和第三方的不一样，导致冲突。

本篇文章主要讲的是可能原因2

　　AndroidStudio 2.0出来后，在这里吐槽下，有点卵用，那就是2.0的虚拟机。至于Instant Run，由于项目minSDKVersion是9，达不到15，基本用不上； Gradle 2.10编译速度尝试了，跟Gradle2.8没啥鸟差别，要不是自己怀有对以后会出更好的Gradle版本或者Android Gradle插件用在AndroidStudio2.0上，还是会选用AndroidStudio 1.5的，吐槽到此为止。
　　
　　最近在做Eclipse的Android项目迁移到AndroidStudio上的事。起初，项目中的一个主Android应用和3个依赖库项目的项目结构还是保留了ANT的结构。集成完之后，发现主Android应用的项目的libs中的.so库存储和使用jcenter动态加载的.so库不兼容，所以导致编译后，程序找不到对应.so文件的问题。
　　

最后笔者解决问题的办法

　　第一步：将Android项目结构改变成Gradle要求结构，其他依赖库项目可以保留ANT项目结构。然后在src/main下建立jniLibs文件夹，把自己项目原本libs中的.so包括各个cpu结构文件夹（例如：armeabi）拷贝到jniLibs下，如下图所示：
这里写图片描述
　　这时编译项目运行并测试成功。（这一步一定要保证编译.so库测试成功，假如之前你集成了百度推送，关联百度推送库就有.so文件，这时测试推送是否正常）
　　
　　第二步：下载第三方库后（比如github上的master），其项目底下有类似libs的目录，或者其他存储.so文件的目录（你也可以将第三方demo的apk包解压获取里面的.so文件），将得到的.so文件拷贝到我们自己项目jniLibs中各个存储.so文件夹下。
　　
　　经过以上两步，第一种方案已完成。

扩展办法，笔者未尝试

　　第一步：在module的Gradle中添加：

android {
sourceSets {
main {
jniLibs.srcDirs = [‘libs’]
}
}
}
　　第二步：下载第三方库后（比如github上的master），其项目底下有类似libs的目录，或者其他存储.so文件的目录（你也可以将第三方demo的apk包解压获取里面的.so文件），将得到的.so文件拷贝到我们自己项目libs中各个存储.so文件夹下。
　　
　　经过以上两步，第二种方案已完成，这种方案未测试，不过原理和方案1类似，应该行得通。