Android NDK 开发(二)

应用二进制界面(ABI)

ABI 可以非常精确地定义应用的机器代码在运行时如何与系统交互。 NDK 根据这些定义构建.so文件。不同的 ABI 对应不同的架构:NDK 包含对 ARMEABI(默认)、MIPS 和 x86 的 ABI 支持。
不同 Android 手机使用不同的 CPU,因此支持不同的指令集。CPU 与指令集的每种组合都有其自己的应用二进制界面(或 ABI)。ABI 可以非常精确地定义应用的机器代码在运行时如何与系统交互。 您必须为应用要使用的每个 CPU 架构指定 ABI。

armeabi

此 ABI 适用于基于 ARM、至少支持 ARMv5TE 指令集的 CPU。

armeabi-v7a

此 ABI 可扩展 armeabi 以包含多个 CPU 指令集扩展。

arm64-v8a

此 ABI 适用于基于 ARMv8、支持 AArch64 的 CPU。它还包含 NEON 和 VFPv4 指令集。

x86

此 ABI 适用于支持通常称为“x86”或“IA-32”的指令集的 CPU。

x86_64

此 ABI 适用于支持通常称为“x86-64”的指令集的 CPU。

mips

此 ABI 适用于基于 MIPS、至少支持 MIPS32r1 指令集的 CPU。

mips64

此 ABI 适用于 MIPS64 R6。

为特定 ABI 生成代码

默认情况下,NDK 为 armeabi ABI 生成机器代码。但您可以通过向 Application.mk文件添加以下行生成 ARMv7-a 兼容的机器代码。

APP_ABI := armeabi-v7a

要为两个或更多不同的 ABI 构建机器代码,请使用空格作为分隔符。

APP_ABI := armeabi armeabi-v7a

构建多个机器代码版本时,构建系统会将库复制到应用项目路径,并最终将它们封装到 APK 中,从而创建一个胖二进制文件,胖二进制文件大于只包含一个系统的机器代码的二进制文件;在安装时,软件包管理器只解包最适合目标设备的机器代码。

应用包中的原生代码

在 APK 中符合以下模式的文件路径上查找 NDK 生成的库

/lib//lib.so

这里的 是支持的 ABI下面列出的 ABI 名称之一, 是您为 Android.mk文件中的 LOCAL_MODULE变量定义库时使用的库名称。

Android 平台 ABI 支持

Android 系统在运行时知道它支持哪些 ABI,因为版本特定的系统属性会指示:

  • 设备的主要 ABI,与系统映像本身使用的机器代码对应。
  • 可选的辅助 ABI,与系统映像也支持的另一个 ABI 对应。

为实现最佳性能,应直接针对主要 ABI 进行编译。例如,基于 ARMv5TE 的典型设备只会定义主要 ABI:armeabi。 相反,基于 ARMv7 的典型设备将主要 ABI 定义为 armeabi-v7a,而将辅助 ABI 定义为 armeabi,因为它可以运行为每个 ABI 生成的应用原生二进制文件。

许多基于 x86 的设备也可运行 armeabi-v7a 和 armeabi NDK 二进制文件。对于这些设备,主要 ABI 将是 x86,辅助 ABI 是 armeabi-v7a。

基于 MIPS 的典型设备只定义主要 ABI:mips。

安装应用时,软件包管理器服务将扫描 APK,查找以下形式的任何共享库:

lib//lib.so

如果未找到,并且您已定义辅助 ABI,该服务将扫描以下形式的共享库:

lib//lib.so

找到所需的库时,软件包管理器会将它们复制到应用的 data 目录 (data/data//lib/) 下的 /lib/lib.so。

Android.mk

Android.mk 文件用于定义 Application.mk、构建系统和环境变量所未定义的项目范围设置。
Android.mk 的语法用于将源文件分组为模块。 模块是静态库、共享库或独立可执行文件。 可在每个 Android.mk 文件中定义一个或多个模块,也可在多个模块中使用同一个源文件。

基础知识

1)Android.mk 文件必须首先定义 LOCAL_PATH 变量:

LOCAL_PATH := $(call my-dir)

此变量表示源文件在开发树中的位置。在这里,构建系统提供的宏函数 my-dir 将返回当前目录(包含 Android.mk 文件本身的目录)的路径。
2) CLEAR_VARS 变量,其值由构建系统提供。

include $(CLEAR_VARS)

CLEAR_VARS 变量指向特殊 GNU Makefile,可为您清除许多 LOCAL_XXX 变量,例如 LOCAL_MODULE、LOCAL_SRC_FILES 和 LOCAL_STATIC_LIBRARIES。 请注意,它不会清除 LOCAL_PATH。此变量必须保留其值,因为系统在单一 GNU Make 执行环境(其中所有变量都是全局的)中解析所有构建控制文件。 在描述每个模块之前,必须声明(重新声明)此变量。
3)LOCAL_MODULE 变量将存储您要构建的模块的名称。请在应用中每个模块使用一个此变量。

LOCAL_MODULE := hello-jni

每个模块名称必须唯一,且不含任何空格。构建系统在生成最终共享库文件时,会将正确的前缀和后缀自动添加到您分配给 LOCAL_MODULE 的名称。 例如,上述示例会导致生成一个名为 libhello-jni.so 的库。
4)枚举源文件,以空格分隔多个文件:

LOCAL_SRC_FILES := hello-jni.c

LOCAL_SRC_FILES 变量必须包含要构建到模块中的 C 和/或 C++ 源文件列表。
5)帮助系统将所有内容连接到一起

include $(BUILD_SHARED_LIBRARY)

BUILD_SHARED_LIBRARY 变量指向 GNU Makefile 脚本,用于收集您自最近 include 后在 LOCAL_XXX 变量中定义的所有信息。

Application.mk

此文件用于描述应用需要的原生模块。 模块可以是静态库、共享库或可执行文件。

你可能感兴趣的:(Android NDK 开发(二))