findlibrary returned null产生的联想，Android(安卓)ndk开发打包时我们应该如何注意平台的兼容（x86,arm,arm-v7a）

很多朋友在开发Android JNI的的时候，会遇到findlibrary returned null的错误，因为某种原因，so没有打包到apk中。下面浅析下引起该错误的原因以及平台兼容性问题。

Android设备加载so如何选择

目前主流的Android设备肯定是armeabi-v7a架构的，然后就是x86和armeabi了。那么Android设备在运行程序时如何选择加载包中的哪个so呢?x86设备肯定优先寻找x86文件夹下的so，armeabi-v7a架构的设备肯定优先选择寻找项目中armeabi-v7a文件夹下的so，那如果项目中没有对应的文件夹和so呢? 我们以x86设备为例，x86设备会在项目中的 libs文件夹寻找是否含有x86文件夹，如果含有x86文件夹，则默认为该项目有x86对应的so可运行的，只有x86文件夹而文件夹下没有so，程序运行也是会出现findlibrary returned null的错误的；如果工程本身不含有x86文件夹，则会寻找armeabi或者armeabi-v7a文件夹，兼容运行。 以armeabi-v7a设备为例（现在大多数设备都是armeabi-v7a架构的），该Android设备当然优先寻找libs目录下的armeabi-v7a文件夹，同样，如果只有armeabi-v7a文件夹而没有 so也是会报错的；如果找不到armeabi-v7a文件夹，则寻找armeabi文件夹，兼容运行该文件夹下的so，但是不能兼容运行x86的so。所以项目中如果只含有x86的so，在armeabi和armeabi-v7a也是无法运行的。 以上就是不同CPU架构运行时加载so的策略。

没有将so打包到apk中的原因。

当你发现到findlibrary returned null的错误时，根本原因是so没有放到对应的文件夹中去，其实最直接的解决办法就是解压apk，看看apk中的x86、armeabi、armeabi-v7a文件夹中是否有对应的so，此时你可能在对应的文件夹下发现少了so，然后再去查原因即可。

一般有两方面的原因:

1.apk中有对应平台的文件夹，但是文件夹里却没有对应的so。

举个例子，apk中lib下面一旦出现x86文件夹，程序运行的时候就会去加载x86对应的库，但是如果此时x86文件夹没有将so放进来，则会遇到报错。

2.第三方对平台的兼容策略与自己不一致。

可能第三方选择了只支持armeabi（假设某支付sdk），但是我们的游戏在Application.mk中配置了APP_ABI := all，如此，我们的游戏打包出 了所有平台的so，但是第三方却只有armeabi文件夹对应的so，造成程序运行异常，这种情况在开发期间最常见，一些小公司由于测试人员不足或者测试设备不足，上线后才发现这个问题也不奇怪。

对于平台的支持，我们应该如何选择。

armeabi-v7a确实是可以兼容armeabi的，而v7a的CPU支持硬件浮点运算，目前绝大对数设备已经是v7a了，所以为了性能上的更优，就不要为了兼容放到armeabi。 x86是可以兼容armeabi平台运行的，无论是armeabi-v7a还是armeabi，同时带来的也是性能上的损耗，另外需要指出的是，打包出的x86的so，总会比armeabi平台的体积更小，对于性能有洁癖的童鞋们，还是建议在打包so的时候支持x86。具体会有怎样的性能损耗，作者还不能说的非常清楚，可以访问下intel官方在csdn的博客。 总结一下在项目中的表现就是:如果项目只包含了armeabi，那么在所有Android设备都可以运行； 如果项目只包含了armeabi-v7a，除armeabi架构的设备外都可以运行；  如果项目只包含了 x86，那么armeabi架构和armeabi-v7a的Android设备是无法运行的； 如果同时包含了armeabi，armeabi-v7a和x86，所有设备都可以运行，程序在运行的时候去加载不同平台对应的so，这是较为完美的一种解决方案，同时也会导致包变大。

Android设备加载so如何选择

没有将so打包到apk中的原因。

1.apk中有对应平台的文件夹，但是文件夹里却没有对应的so。

2.第三方对平台的兼容策略与自己不一致。

对于平台的支持，我们应该如何选择。

更多相关文章

随机推荐