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

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