Android so库兼容问题

一， 现有的CPU架构类型

开发Android应用时，有时候Java层的编码不能满足实现需求，就需要到C/C++实现后生成SO文件，再用System.loadLibrary()加载进行调用，这里成为JNI层的实现。常见的场景如：加解密算法，音视频编解码等。在生成SO文件时，需要考虑适配市面上不同手机CPU架构，而生成支持不同平台的SO文件进行兼容。

目前Android共支持七种不同类型的CPU架构：

• armeabi 第5代 ARM v5TE，使用软件浮点运算，兼容所有ARM设备，通用性强，速度慢（只支持armeabi）。
• armeabi-v7a 第7代 ARM v7，使用硬件浮点运算，具有高级扩展功能（支持 armeabi 和 armeabi-v7a）。
• arm64-v8a 第8代，64位，包含AArch32、AArch64两个执行状态对应32、64bit（支持 armeabi-v7a、armeabi 和 arm64-v8a）
• x86 intel 32位，一般用于平板（支持 armeabi(性能有所损耗) 和 x86）
• x86_64 intel 64位，一般用于平板（支持 x86 和 x86_64）
• mips 基本没见过（支持 mips）
• mips64 基本没见过（支持 mips 和 mips_64）

二， 现有的常用ABI

应用程序二进制接口（Application Binary Interface）定义了其所对应的CPU架构能够执行的二进制文件（特别是.so文件）的格式规范。在Android系统上，不同 Android 手机使用不同的 CPU，因此支持不同的指令集。CPU 与指令集的每种组合都有其自己的应用二进制界面（或 ABI）。 ABI 可以非常精确地定义应用的机器代码在运行时如何与系统交互。 您必须为应用要使用的每个 CPU 架构指定 ABI：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64。

典型的 ABI 包含以下信息：

• 机器代码应使用的 CPU 指令集。
• 运行时内存存储和加载的字节顺序。
• 可执行二进制文件（例如程序和共享库）的格式，以及它们支持的内容类型。
• 用于解析内容与系统之间数据的各种约定。这些约定包括对齐限制，以及系统如何使用堆栈和在调用函数时注册。
• 运行时可用于机器代码的函数符号列表 - 通常来自非常具体的库集。
• 支持一个或多个指令集。

三， SO(CPU)的兼容

每一个CPU架构对应一个ABI，一个cpu属于某一种架构，多核cpu需要属于相同架构才能一起工作,很多设备仅支持一种的CPU架构。如果你要完美兼容所有类型的手机，理论上是要在的libs目录下放置各个架构平台的SO文件。

这样一写，虽然可以兼容所有机型，但你的项目体积也会变得非常庞大。是否一定需要带入这么多SO文件去兼容呢？答案是否定的。对于CPU来说，不同的架构并不意味着一定互不兼容，根据目前Android共支持七种不同类型的CPU架构，其兼容特点可总结如下：

四， SO过滤

对于项目本省的so是可以进行适配的，但是对于第三方提供的框架生成的so怎么办呢，这就需要利用gradle配置，在打包过程中过滤掉不需要适配的机型。

例如： 项目中引入了Fresco框架，地球人都知道这个框架操作的是native层，打包后会生成so。这也就是我们常说的，这个库会让apk增加2MB，其实这部分空间是被so占用了。因此对我司项目只需要保留armeabi-v7a，其他过滤掉。

在实际开发中，应该怎么去适配so，看这篇