本帖子已过去太久远了，不再提供回复功能。6316人阅读
Android之疑难杂症（30）
转自：/a/6078
正好动态加载系列文章谈到了加载SO库的地方，我觉得这里可以顺便谈谈使用SO库时需要注意的一些问题。或许这些问题对于经常和SO库开发打交道的同学来说已经是老生长谈，但是既然要讨论一整个动态加载系列，我想还是有必要说说使用SO库时的一些问题。
在项目里使用SO库非常简单，在&&中也有谈到，只需要把需要用到的SO库拷贝进&jniLibs(或者Eclipse项目里面的libs)&中，然后在JAVA代码中调用&System.loadLibrary(&xxx&)&加载对应的SO库，就可以使用JNI语句调用SO库里面的Native方法了。
但是有同学注意到了，SO库文件可以随便改文件名，却不能任意修改文件夹路径，而是“armeabi”、“armeabi-v7a”、“x86”等文件夹名有着严格的要求，这些文件夹名有什么意义么？
原因很简单，不同CPU架构的设备需要用不同类型SO库（从文件名也可以猜出来个大概嘛 ╮(￣▽￣&)╭）。
记得还在学校的时候，提及ARM处理器时，老师说以后移动设备的CPU基本就是ARM类型的了。老师不曾欺我，早期的Android系统几乎只支持ARM的CPU架构，不过现在至少支持以下七种不同的CPU架构：ARMv5，ARMv7，x86，MIPS，ARMv8，MIPS64和x86_64。每一种CPU类型都对应一种ABI（Application Binary Interface），“armeabi-v7a”文件夹前面的“armeabi”指的就是ARM这种类型的ABI，后面的“v7a”指的是ARMv7。这7种CPU类型对应的SO库的文件夹名是：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。
不同类型的移动设备在运行APP时，需要加载自己支持的类型的SO库，不然就GG了。通过&Build.SUPPORTED_ABIS&我们可以判断当前设备支持的ABI，不过一般情况下，不需要开发者自己去判断ABI，Android系统在安装APK的时候，不会安装APK里面全部的SO库文件，而是会根据当前CPU类型支持的ABI，从APK里面拷贝最合适的SO库，并保存在APP的内部存储路径的&libs&下面。（这里说一般情况，是因为有例外的情况存在，比如我们动态加载外部的SO库的时候，就需要自己判断ABI类型了。）
一种CPU架构　=　一种对应的ABI参数　=　 一种对应类型的SO库
到这里，我们发现使用SO库的逻辑还是比较简单的，但是Android系统加载SO库的逻辑还是给我们留下了一些坑。
SO库其实都是APP运行时加载的，也就是说APP只有在运行的时候才知道SO库文件的存在，这就无法通过静态代码检查或者在编译APP时检查SO库文件是否正常。所以，Android开发对SO库的存放路径有严格的要求。
使用SO库的时候，除了“armeabi-v7a”等文件夹名需要严格按照规定的来自外，SO库要放在项目的哪个文件夹下也要按照套路来，以下是一些总结：
Android Studio 工程放在&jniLibs/xxxabi&目录中（当然也可以通过在build.gradle文件中的设置jniLibs.srcDir属性自己指定）；
Eclipse 工程放在&libs/xxxabi&目录中（这也是使用ndk-build命令生成SO库的默认目录）；
aar 依赖包中位于&jni/ABI&目录中（SO库会自动包含到引用AAR压缩包到APK中）；
最终构建出来的APK文件中，SO库存在&lib/xxxabi&目录中（也就是说无论你用什么方式构建，只要保证APK包里SO库的这个路径没错就没问题）；
通过 PackageManager 安装后，在小于 Android 5.0 的系统中，SO库位于 APP 的&nativeLibraryPath&目录中；在大于等于 Android 5.0 的系统中，SO库位于 APP 的&nativeLibraryRootDir/CPU_ARCH&目录中；
既然扯到了这里，顺便说一下，我在使用 Android Studio 1.5 构建APK的时候，发现 Gradle 插件只会默认打包application类型的module的jniLibs下面的SO库文件，而不会打包aar依赖包的SO库，所以会导致最终构建出来的APK里的SO库文件缺失。暂时的解决方案是把所有的SO库都放在application模块中（这显然不是很好的解决方案），不知道这是不是Studio的BUG，同事的解决方案是通过修改Gradle插件来增加对aar依赖包的SO库的打包支持（GitHub有开源的第三方Gradle插件项目，使用Java和Groovy语言开发）。
当一个应用安装在设备上，只有该设备支持的CPU架构对应的SO库会被安装。但是，有时候，设备支持的SO库类型不止一种，比如大多的X86设备除了支持X86类型的SO库，还兼容ARM类型的SO库（目前应用市场上大部分的APP只适配了ARM类型的SO库，X86类型的设备如果不能兼容ARM类型的SO库的话，大概要嗝屁了吧）。
所以如果你的APK只适配了ARM类型的SO库的话，还是能以兼容的模式在X86类型的设备上运行（比如华硕的平板），但是这不意味着你就不用适配X86类型的SO库了，因为X86的CPU使用兼容模式运行ARM类型的SO库会异常卡顿（试着回想几年前你开始学习Android开发的时候，在PC上使用AVD模拟器的那种感觉）。
除了要注意使用了正确CPU类型的SO库，也要注意SO库的编译版本的问题。虽然现在的Android Studio支持在项目中直接编译SO库，但是更多的时候我们还是选择使用事先编译好的SO库，这时就要注意了，编译APK的时候，我们总是希望使用最新版本的build-tools来编译，因为Android SDK最新版本会帮我们做出最优的向下兼容工作。
但是这对于编译SO库来说就不一样了，因为NDK平台不是向下兼容的，而是向上兼容的。应该使用app的minSdkVersion对应的版本的NDK标本来编译SO库文件，如果使用了太高版本的NDK，可能会导致APP性能低下，或者引发一些SO库相关的运行时异常，比如“UnsatisfiedLinkError”，“dlopen: failed”以及其他类型的Crash。
一般情况下，我们都是使用编译好的SO库文件，所以当你引入一个预编译好的SO库时，你需要检查它被编译所用的平台版本。
比如有时候，因为业务的需求，我们的APP不需要支持AMR64的设备，但这不意味着我们就不用编译ARM64对应的SO库。举个例子，我们的APP只支持armeabi-v7a和x86架构，然后我们的APP使用了一个第三方的Library，而这个Library提供了AMR64等更多类型CPU架构的支持，构建APK的时候，这些ARM64的SO库依然会被打包进APK里面，也就是说我们自己的SO库没有对应的ARM64的SO库，而第三方的Library却有。这时候，某些ARM64的设备安装该APK的时候，发现我们的APK里带有ARM64的SO库，会误以为我们的APP已经做好了AMR64的适配工作，所以只会选择安装APK里面ARM64类型的SO库，这样会导致我们自己项目的SO库没有被正确安装（虽然armeabi-v7a和x86类型的SO库确实存在APK包里面）。
这时正确的做法是，给我们自己的SO库也提供AMR64支持，或者不打包第三方Library项目的ARM64的SO库。使用第二种方案时，可以把APK里面不需要支持的ABI文件夹给删除，然后重新打包，而在Android Studio下，则可以通过以下的构建方式指定需要类型的SO库。
productFlavors {
abiFilters &armeabi-v7a&
abiFilters &x86&
abiFilters &armeabi&
abiFilters &armeabi-v7a&
abiFilters &x86&
abiFilters &armeabi&
abiFilters &arm64-v8a&
abiFilters &x86_64&
需要说明的是，如果我们的项目是SDK项目，我们最好提供全平台类型的SO库支持，因为APP能支持的设备CPU类型的数量，就是项目中所有SO库支持的最少CPU类型的数量（使用我们SDK的APP能支持的CPU类型只能少于等于我们SDK支持的类型）。
确实，所有的x86/x86_64/armeabi-v7a/arm64-v8a设备都支持armeabi架构的SO库，因此似乎移除其他ABIs的SO库是一个减少APK大小的好办法。但事实上并不是，这不只影响到函数库的性能和兼容性。
X86设备能够很好的运行ARM类型函数库，但并不保证100%不发生crash，特别是对旧设备，兼容只是一种保底方案。64位设备（arm64-v8a, x86_64, mips64）能够运行32位的函数库，但是以32位模式运行，在64位平台上运行32位版本的ART和Android组件，将丢失专为64位优化过的性能（ART，webview，media等等）。
过减少其他CPU类型支持的SO库来减少APK的体积不是很明智的做法，如果真的需要通过减少SO库来做APK瘦身，我们也有其他办法。
我们可以构建一个APK，它支持所有的CPU类型。但是反过来，我们可以为每个CPU类型都单独构建一个APK，然后不同CPU类型的设备安装对应的APK即可，当然前提是应用市场得提供用户设备CPU类型设别的支持，就目前来说，至少PLAY市场是支持的。
Gradle可以通过以下配置生成不同ABI支持的APK（引用自别的文章，没实际使用过）：
enable true
include 'x86', 'x86_64', 'armeabi-v7a', 'arm64-v8a' //select ABIs to build APKs for
universalApk true //generate an additional APK that contains all the ABIs
// map for the version code
project.ext.versionCodes = ['armeabi': 1, 'armeabi-v7a': 2, 'arm64-v8a': 3, 'mips': 5, 'mips64': 6, 'x86': 8, 'x86_64': 9]
android.applicationVariants.all { variant -&
// assign different version code for each output
variant.outputs.each { output -&
output.versionCodeOverride =
project.ext.versionCodes.get(output.getFilter(com.android.build.OutputFile.ABI), 0) * 1000000 + android.defaultConfig.versionCode
说到这里，总算回到动态加载的主题了。⊙﹏⊙
使用Android的动态加载技术，可以加载外部的SO库，所以我们可以从网络下载SO库文件并加载了。我们可以下载所有类型的SO库文件，然后加载对应类型的SO库，也可以下载对应类型的SO库然后加载，不过无论哪种方式，我们最好都在加载SO库前，对SO库文件的类型做一下判断。
我个人的方案是，存储在服务器的SO库依然按照APK包的压缩方式打包，也就是，SO库存放在APK包的&libs/xxxabi&路径下面，下载完带有SO库的APK包后，我们可以遍历libs路径下的所有SO库，选择加载对应类型的SO库。
具体实现代码看上去像是：
* 将一个SO库复制到指定路径，会先检查改SO库是否与当前CPU兼容
* sourceDir
SO库所在目录
目标根目录
* nativeLibName 目标SO库目录名
public static boolean copySoLib(File sourceDir, String so, String destDir, String nativeLibName) throws IOException {
boolean isSuccess = false;
LogUtil.d(TAG, &[copySo] 开始处理so文件&);
if (Build.VERSION.SDK_INT &= 21) {
String[] abis = Build.SUPPORTED_ABIS;
if (abis != null) {
for (String abi : abis) {
LogUtil.d(TAG, &[copySo] try supported abi:& + abi);
String name = &lib& + File.separator + abi + File.separator +
File sourceFile = new File(sourceDir, name);
if (sourceFile.exists()) {
LogUtil.i(TAG, &[copySo] copy so: & + sourceFile.getAbsolutePath());
isSuccess = FileUtil.copyFile(sourceFile.getAbsolutePath(), destDir + File.separator + nativeLibName + File.separator + so);
LogUtil.e(TAG, &[copySo] get abis == null&);
LogUtil.d(TAG, &[copySo] supported api:& + Build.CPU_ABI + & & + Build.CPU_ABI2);
String name = &lib& + File.separator + Build.CPU_ABI + File.separator +
File sourceFile = new File(sourceDir, name);
if (!sourceFile.exists() && Build.CPU_ABI2 != null) {
name = &lib& + File.separator + Build.CPU_ABI2 + File.separator +
sourceFile = new File(sourceDir, name);
if (!sourceFile.exists()) {
name = &lib& + File.separator + &armeabi& + File.separator +
sourceFile = new File(sourceDir, name);
if (sourceFile.exists()) {
LogUtil.i(TAG, &[copySo] copy so: & + sourceFile.getAbsolutePath());
isSuccess = FileUtil.copyFile(sourceFile.getAbsolutePath(), destDir + File.separator + nativeLibName + File.separator + so);
if (!isSuccess) {
LogUtil.e(TAG, &[copySo] 安装 & + so + & 失败 : NO_MATCHING_ABIS&);
throw new IOException(&install & + so + & fail : NO_MATCHING_ABIS&);
} catch (IOException e) {
e.printStackTrace();
return true;
一种CPU架构 = 一种ABI = 一种对应的SO库；
加载SO库时，需要加载对应类型的SO库；
尽量提供全平台CPU类型的SO库支持；
题外话，SO库的使用本身就是一种最纯粹的动态加载技术，SO库本身不参与APK的编译过程，使用JNI调用SO库里的Native方法的方式看上去也像是一种“硬编程”，Native方法看上去与一般的Java静态方法没什么区别，但是它的具体实现却是可以随时动态更换的（更换SO库就好），这也可以用来实现热修复的方案，与Java方法一旦加载进内存就无法再次更换不同，Native方法不需要重启APP就可以随意更换。
出于安全和生态控制的原因，Google Play市场不允许APP有加载外部可执行文件的行为，一旦你的APK里被检查出有额外的可执行文件时就不好玩了，所以现在许多APP都偷偷把用于动态加载的可执行文件的后缀名换成“.so”，这样被发现的几率就降低了，因为加载SO库看上去就是官方合法版本的动态加载啊（不然SO库怎么工作），虽然这么做看起来有点掩耳盗铃。
&&相关文章推荐
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：61962次
积分：1469
积分：1469
排名：千里之外
原创：59篇
转载：13篇
评论：35条
Android开发者官网：
Google开发者官网：
文章：21篇
阅读：30089
(window.slotbydup = window.slotbydup || []).push({
id: '4740887',
container: s,
size: '250,250',
display: 'inlay-fix'1.Android设备如何加载.so文件？
不同CPU架构的Android手机加载时会在libs下找自己对应的目录，从对应的目录下寻找需要的.so文件；如果没有对应的目录，就会去armeabi下去寻找，如果已经有对应的目录，但是如果没有找到对应的.so文件，也不会去armeabi下去寻找了。
以x86设备为例，x86设备会在项目中的 libs文件夹寻找是否含有x86文件夹，如果含有x86文件夹，则默认为该项目有x86对应的so可运行文件，只有x86文件夹而文件夹下没有so，程序运行也是会出现find library returned null的错误的；如果工程本身不含有x86文件夹，则会寻找armeabi或者armeabi-v7a文件夹，兼容运行。以armeabi-v7a设备为例，该Android设备当然优先寻找libs目录下的armeabi-v7a文件夹，同样，如果只有armeabi-v7a文件夹而没有 so也是会报错的；如果找不到armeabi-v7a文件夹，则寻找armeabi文件夹，兼容运行该文件夹下的so，但是不能兼容运行x86的so。所以项目中如果只含有x86的so，在armeabi和armeabi-v7a也是无法运行的。以上就是不同CPU架构运行时加载so的策略。
2.对于不同的平台，我们应该怎么去进行适配？
目前主流的Android设备肯定是armeabi-v7a架构的，然后就是x86和armeabi了。如果同时包含了 armeabi， armeabi-v7a和x86，所有设备都可以运行，程序在运行的时候去加载不同平台对应的so，这是较为完美的一种解决方案，但是同时也会导致包变大。
armeabi-v7a是可以兼容armeabi的，而v7a的CPU支持硬件浮点运算，目前绝大对数设备已经是armeabi-v7a了，所以为了性能上的更优，就不要为了兼容放到armeabi下了。x86也是可以兼容armeabi平台运行的，另外需要指出的是，打出包的x86的so，总会比armeabi平台的体积更小，对于性能有洁癖的童鞋们，还是建议在打包so的时候支持x86。
3.如果第三方没有提供对应平台的.so文件怎么办？
有一些第三方的类库只提供了armeabi下的.so文件，如果我们项目里适配了armeabi-v7a和x86，如果不在对应的文件下放对应的.so文件，就可能导致某些Android设备会出一些问题，我们可以复制armeabi下得.so文件到不同的文件夹下。如果第三方提供了不同平台的.so文件，则复制不同平台的.so文件到项目中对应的文件夹下即可。
本文已收录于以下专栏：
相关文章推荐
Android 设备的CPU类型通常称为ABIs
1解决之前的截图
2解决后的截图
为什么你需要重点关注so文件
App中可能出错的地方
其他地方也可能出错
出自：http://blog.csdn.net/u/article/details/
1.Android设备如何加载.so文件？ 
不同CPU架构的And...
armeabi和armeabi-v7a
分类： android app 开发
10:15 11286人阅读 评论(1) 收藏 举报
androidapi扩展手机...
LZ是一名96年Android小生，从14年9月培训出来到现在，差不多俩年多的时间，由于一些原因，没能好好把技术提升一下，实乃不该啊。
了解起因昨天师傅问，你知道这俩个是什么么？有什么作用么？(如下图...
写在前面：请先了解Android的.so文件、ABI和CPU的关系http://blog.csdn.net/xx/article/details/
了解完 arm...
在上一篇文章当中，我们学习了DiskLruCache的概念和基本用法，但仅仅是掌握理论知识显然是不够的，那么本篇文章我们就来继续进阶一下，看一看在实战当中应该怎样合理使用DiskLruCache。还不...
简而言之：armeabi 和 armeabi-v7a是针对不同CPU而建立的文件夹，armeabi是指的该so库用于ARM的通用CPU，而v7a的CPU支持硬件浮点运算。因此armeabi通用性强，但...
转载请注明出处：
在Android日常的开发过程中有的项目需要引入第三方的库，有时候大家可能会在libs文件夹下看到mips、armeabi、armeabi-v7a和x86这四个文件夹。那么...
Android项目中libs库中的armeabi-v7a，armeabi和x86的区别
他的最新文章
讲师：王哲涵
讲师：韦玮
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)