你必须知道的ABI和CPU关系

ABI和CPU的重要知识

1、 大部分cpu都支持多于一种的ABI。
2、 当一个应用安装在设备上,只有该设备支持的CPU架构对应的.so文件会被安装。
3、

ABI目录(横向)和cpu(纵向) armeabi armeabi-v7a arm64-v8a mips mips64 x86 x86_64
ARMv5 支持
ARMv7 支持 支持
ARMv8 支持 支持 支持
MIPS 支持
MIPS64 支持 支持
x86 支持 支持 支持
x86_64 支持 支持 支持
  • 注意:上表格中的空白部分,是我不知道它是否支持,极有可能是不支持

  • 解析: x86设备上,选择ABI的优先级

    • libs/x86目录中如果存在.so文件的话,会被安装
    • 如果不存在,则会选择armeabi-v7a中的.so文件
    • 如果也不存在,则选择armeabi目录中的.so文件
  • x86设备能够很好的运行ARM类型函数库,但并不保证100%不发生crash,特别是对旧设备,因为是运行在x86设备上模拟arm的虚拟层上。

4、 64位设备(arm64-v8a, x86_64, mips64)能够运行32位的函数库,但是以32位模式运行,在64位平台上运行32位版本的ART和Android组件,将丢失专为64位优化过的性能(ART,webview,media等等)。

5、 最好是针对特定平台提供相应平台的二进制包,这种情况下运行时就少了一个模拟层(例如x86设备上模拟arm的虚拟层),从而得到更好的性能(归功于最近的架构更新,例如硬件fpu,更多的寄存器,更好的向量化等)。

6、 会安装优先级较高的ABI目录,则其它优先级较低的ABI目录(包括其它module中的ABI目录),都无法安装。例如:在cpu是ARMv7架构的手机上,如果检测到armeabi-v7a,就会选择安装armeabi-v7a,则armeabi下的文件,都无法安装了。

7、 相应的ABI二进制文件,要放进相应的ABI目录中

8、一般情况下不要简单得修改架构目录名

我们可以通过Build.SUPPORTED_ABIS得到根据偏好排序的设备支持的ABI列表。但你不应该从你的应用程序中读取它,因为Android包管理器安装APK时,会自动选择APK包中为对应系统ABI预编译好的.so文件,如果在对应的lib/ABI目录中存在.so文件的话。

###工具
查看项目中ABI文件的架构类型
腾讯bugly,符号表工具,下载地址:http://bugly.qq.com/whitebook

Native Libs Monitor这个应用可以帮助我们理解手机上安装的APK用到了哪些.so文件,以及.so文件来源于哪些函数库或者框架。

###疑难杂症
虽然规则制定出来了,但总是会出现一些,不合规的现象,导致一些错误,难以理解。现在就让我们来一起把把脉,看看到底是什么疑难杂症

####一、.so文件,放进了优先级低的ABI目录

1、如果你的项目中,有其他优先级更高的ABI目录,但是你把ABI文件放到了优先级低的目录,则你的ABI文件无法被加载
2、如果你的项目中,ABI文件放在了,项目中优先级最高的ABI目录中(这个ABI目录是手机所支持的在项目中优先级最高的,但不一定是手机所支持的优先级最高的),则这个ABI文件,可以被加载,加载为ABI目录的所表示的架构类型。

例子:

我的手机cpu架构是ARMv7,ABI文件是armeabi-v7a,但是放进了armeabi目录中

在运行的过程中会出现两种情况:

1、项目中有armeabi-v7a的目录,armeabi目录中的文件,无法被加载,运行后报错,出现如下log信息。

Caused by: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/.xx../base.apk"],nativeLibraryDirectories=[/data/app/.xx../lib/arm, /vendor/lib, /system/lib]]] couldn't find "lib..xx...so"

2、项目中只有armeabi的目录,armeabi目录是该项目优先级最高的ABI目录(虽然armeabi目录在ARMv7所支持的优先级最高的ABI目录不是最高),作为armv5,安装到手机上。

####二、ABI二进制文件,放进了优先级高的ABI目录
可以被加载使用,被加载为ABI文件所表示的结构类型

例子:

我的手机cpu架构是ARMv7,ABI文件是armeabi-v5te,但是放进了armeabi-v7a目录中。

可以被加载,但是加载为ABI文件所表示的架构类型。这样就出现了,同一个应用中ABI文件,出现两种的情况。

####三、两个第三的SDK中ABI文件优先级不一样
问题:

两个第三方的SDK中ABI文件优先级不一样,手机加载运行时,会导致优先级低的库,无法被加载

例子:

我的手机cpu架构是ARMv7,项目中使用两个第三方SDK:企业A和企业B

企业A:ABI文件是armeabi-v7a,放进armeabi-v7a目录中。
企业B:ABI文件是armeabi-v5te,放进armeabi目录中。

在运行时,会发现运行后crash,出现如下log信息。

Caused by: java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/.xx../base.apk"],nativeLibraryDirectories=[/data/app/.xx../lib/arm, /vendor/lib, /system/lib]]] couldn't find "lib..xx...so"

解决办法:

#####1、使用同一优先级的ABI文件,ABI文件放入优先级相同的ABI目录

企业A:ABI文件是armeabi-v5te,放进armeabi目录中。
企业B:ABI文件是armeabi-v5te,放进armeabi目录中。

企业A:ABI文件是armeabi-v7a,放进armeabi-v7a目录中。
企业B:ABI文件是armeabi-v7a,放进armeabi-v7a目录中。

#####2、使用不同优先级的ABI文件,ABI文件放入优先级相同的ABI目录。一般情况不建议这么做。

企业A:ABI文件是armeabi-v7a,但是放进armeabi目录中。
企业B:ABI文件是armeabi-v5te,放进armeabi目录中。

企业A:ABI文件是armeabi-v7a,放进armeabi-v7a目录中。
企业B:ABI文件是armeabi-v5te,但是放进armeabi-v7a目录中。

坚持原创技术分享,您的支持将鼓励我继续创作!