我们在编写JNI代码时有一个可选的文件Application.mk ,这个文件你可以不创建,但是有时候是有必要写一个这样的文件的。
Application.mk文件用于描述应用程序本身的一些属性信息,如应用程序依赖哪些库,应用程序的根目录,应用程序运行在哪些类型指令集的CPU下,还有一些编译选项,
在此文件中定义的东西会应用于整个应用程序包括android.mk也会用到这里面的选项。
如果你不写此文件,会默认编出所有android.mk中写的libs / modules APP_ABI会默认指定为armeabi
下面我们主要介绍APP_ABI的用途。
首先市面上的android智能设备很多也很杂,各种类型各个厂家的芯片,但都是基于某种指令集来开发出来的,这里的ABI(Application Binary Interface)实际就是指应用程序基于哪种指令集来进行编译,官方文档说其实是以下几点不同:
- the CPU instruction set that the machine code should use - the endianness of memory stores and loads at runtime - the format of executable binaries (shared libraries, programs, etc...) and what type of content is allowed/supported in them. - various conventions used to pass data between your code and the system (e.g. how registers and/or the stack are used when functions are called, alignment constraints, etc...) - alignment and size constraints for enum types, structure fields and arrays. - the list of function symbols available to your machine code at runtime, generally from a very specific selected set of libraries.
我们能用到的ABI 也就四种 armeabi armeabi-v7a x86 和mips 前两者最常用到。
在编译的时候你可以指定其中的一种或者几种,如果指定了几种,这时候打包到APK后这个APK被称为“胖二进制”,也就是它包含了几种ABI类型的lib
当APK被安装到设备上的时候,android系统有这样一个机制:
系统支持哪些ABI类型它自己是知道的,它们会将最适合机器性能发挥的ABI类型标记位'primary' 把剩下的也支持的标记为‘secondary’
例如
CPU 工艺为 ARMv5TE-based 的CPU只有'primary' 为armeabi 没有'secondary'
而类型为ARMv7-based的CPU 'primary' 为armeabi-v7a 'secondary'为armeabi
应用程序安装的时候系统首先检查lib/<primary-abi>/libxx.so 如果有的话就将此处的lib随应用程序copy到/data/app/下面这个大家应该知道第三方应用的安装目录
如果没有的话,而机器有secondary ,就检查lib/<secondary-abi>/libxx.so
所以这就是为什么我们不用写application.mk 而应用程序能在amrv7 的机器上面跑得好好的,但是这有可能没有发挥到amrv7的最有效的性能。
所以如果是我写应用程序我会指定两个或更多(当然这可能造成APK体积增大,这个要自己取舍)
另外推荐一个工具查看android系统的硬件信息 z-devicetest ,可以看到CPU型号等具体信息。