android ndk混合使用32和64位so库的尝试和总结

96
08_carmelo
0.1 2017.08.07 23:11* 字数 1963

前言

首先要知道,64位的设备是兼容32位so文件的,目前很多主流app都是只在app中放置32位so,目的是减小apk的打包体积,弊端就是在64位设备上运行时不能充分发挥64位cpu的计算能力。

但是我们项目没有这么做,而是在app中同时放了32和64位so,导致apk的体积暴增,原因是app中有3D图形加载比较耗cpu,因此在64位设备上运行为了实际体验使用64位的so,而其他功能如mp3转码,pdf查看也需要用到so文件,直接用32位就够了。那么问题来了,有没有可能在app中只放置加载图形需要的64位so,和其他功能需要的32位so呢?让32和64位so混合使用。

尝试过程

  • 先说结论,如果用64位so的功能没有UI交互(比如视频转码这类),有办法解决。如果这部分功能需要界面交互的,目前无法解决。

  • 查了一些技术文章,是说android不允许混合使用so文件,要么全部使用32位要么全部使用64位,总之在lib目录文件要放全,否则加载的时候找不到对应文件就会崩溃。那我先尝试了多进程方式动态加载,就是在lib目录只放了部分32位so,然后我把需要64位so的图形功能Activity放到新的进程,动态加载64位so文件,还是报错。

  • 接着尝试蒙骗lib文件夹,我直接把64位so放到armeabi目录,企图蒙骗过关,但是加载的时候就报错了,虚拟机发现armeabi里面放的不是32位so。。。

  • 接着尝试,app项目中什么so都不放,先动态加载32位,再动态加载64位so。还是不行

  • 试了一天没办法了,我决定去stackoverflow碰碰运气,这真是神奇的网站啊,这么偏的问题这么蹩脚的英文提问,还是有大神来围观。
    https://stackoverflow.com/questions/45353090/how-to-mix-32-and-64-bit-so-files-in-an-app
    大致意思就是,Android在安装apk的时候就已经决定了,加载32还是64位so只能选其一,但是可以尝试用c++源码编译64位的linux可执行文件,跳过JNI调用直接使用Runtime.exec用android的运行时来命令行调用。这样就可以在app中混合使用32和64位so了,但是这样无法解决有UI交互的功能。

OK,我们项目的图形加载当然是有UI交互的,这个问题目前没有解决,不过学到了两点新姿势:一是Android加载so文件机制,二是如何动态加载so文件。

android加载so文件的机制

apk在安装的过程中,系统就会对apk进行解析根据里面so文件类型,确定这个apk安装是在32 还是 64位的虚拟机上,如果是32位虚拟机那么就不能使用64位so,如果是64位虚拟机也不能使用32位so。而64位设备可以提供32和64位两种虚拟机,根据apk选择开启哪一种,因此说64位设备兼容32的so库。

具体机制,分下面四种情况:
1.假设apk的lib目录放置了32和64位两种so,那么安装时根据当前设备的cpu架构从上到下筛选(X86 > arm64 > arm32),一旦发现lib里面有和设备匹配的so文件,那么直接选定这种架构为标准。比如当前设备是64位并且发现lib有一个64位的so,那么apk会拷贝lib下所有64位的so文件到data/data/packageName/lib/目录(查看此目录需要ROOT)

image.png

后面调用System.loadLibrary其实就是加载这个目录下的so文件,此时如果有某个64位so文件在我们项目的lib中没有提供,就会直接报错程序崩溃。因此这里如果放置部分功能32位so,部分功能放置放置64位so,即使用多进程来加载模型,也会报错崩溃。

2.apk的lib目录只放置32位so,参照上面原理,运行在32位设备是OK的。绝大多数64位设备也是OK的,不过x86的设备肯定会崩溃。假设现在运行在64位设备,然后在代码中动态加载64位so文件,会报错:so is 64-bit instead of 32-bit

3.apk的lib目录只放64位的so,那这个apk只能运行在64位的设备了,同理如果在代码中动态加载32位的so,会报错:so is 32-bit instead of 64-bit

4.apk的lib不放任何so文件,全部动态加载。安装在32位设备就只能加载32位so,安装在64位的设备系统会默认你的apk运行在64位虚拟机,此时动态加载32位so也是不行的。

so的动态加载

先说静态加载:开发阶段把so库放到项目lib目录,安装apk时系统会拷贝这些文件到data/data/packageName/lib/目录,System.loadLibrary()这个方法没有指定so文件的绝对路径,因为系统会直接去这个目录找。这种加载是常用的so文件使用方法,弊端就是可能是apk的体积变得很大。

这种情况可以考虑使用动态加载:apk不放置任何so文件在安装运行后,根据功能需求从服务端下载对应的so文件,拷贝到指定目录然后调用System.load(so的的绝对路径)来加载。

动态加载的弊端就是需要服务端的额外工作量,以及so文件的后期维护,目前我在在项目中没有实际运用。不过我把so放到Asset目录,然后动态拷贝到指定目录是可行的,通过Demo发现有两个需要注意的地方:

  1. 动态加载的目录并不是data/data/packageName/lib/,这个目录只读不可写,而是这个目录:

String libPath = "/data/data/" + getPackageName(); // Your application path

可以先下载so文件到SD卡,然后拷贝so到上面的libPath(不需要特殊权限),接着调用System.load(libPath + "/libmp3lame.so")实现动态加载。

  1. 现在有很多主流app都抛弃64和x86的so文件,只采用32位。如果你也想只使用32位的so并且是动态加载,你可以发现app运行在64位手机上加载so时直接崩溃,原因参照上面so加载机制的第四条。解决办法就是:app的lib目录放置一个32位的so文件(可以放一个体积很小的)

参考文档:

http://www.wjdiankong.cn/android%E4%B8%ADso%E4%BD%BF%E7%94%A8%E7%9F%A5%E8%AF%86%E5%92%8C%E9%97%AE%E9%A2%98%E6%80%BB%E7%BB%93%E4%BB%A5%E5%8F%8A%E6%8F%92%E4%BB%B6%E5%BC%80%E5%8F%91%E8%BF%87%E7%A8%8B%E4%B8%AD%E5%8A%A0%E8%BD%BDso/

Android经验分享
Web note ad 1