前言

首先要知道，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）

后面调用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发现有两个需要注意的地方：

动态加载的目录并不是data/data/packageName/lib/，这个目录只读不可写，而是这个目录：

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

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

现在有很多主流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/