Ninja简介-Android10.0编译系统（九）

摘要：Ninja具体干了什么？

阅读本文大约需要花费16分钟。

文章首发微信公众号：IngresGe

专注于Android系统级源码分析，Android的平台设计，欢迎关注我，谢谢！

欢迎关注我的公众号！

[Android取经之路] 的源码都基于Android-Q（10.0）进行分析

[Android取经之路] 系列文章：

《系统启动篇》

Android系统架构
Android是怎么启动的
Android 10.0系统启动之init进程
Android10.0系统启动之Zygote进程
Android 10.0 系统启动之SystemServer进程
Android 10.0 系统服务之ActivityMnagerService
Android10.0系统启动之Launcher(桌面)启动流程
Android10.0应用进程创建过程以及Zygote的fork流程
Android 10.0 PackageManagerService（一）工作原理及启动流程
Android 10.0 PackageManagerService（二）权限扫描
Android 10.0 PackageManagerService（三）APK扫描
Android 10.0 PackageManagerService（四）APK安装流程

《日志系统篇》

Android10.0 日志系统分析(一)-logd、logcat 指令说明、分类和属性
Android10.0 日志系统分析(二)-logd、logcat架构分析及日志系统初始化
Android10.0 日志系统分析(三)-logd、logcat读写日志源码分析
Android10.0 日志系统分析(四)-selinux、kernel日志在logd中的实现

《Binder通信原理》：

Android10.0 Binder通信原理(一)Binder、HwBinder、VndBinder概要
Android10.0 Binder通信原理(二)-Binder入门篇
Android10.0 Binder通信原理(三)-ServiceManager篇
Android10.0 Binder通信原理(四)-Native-C\C++实例分析
Android10.0 Binder通信原理(五)-Binder驱动分析
Android10.0 Binder通信原理(六)-Binder数据如何完成定向打击
Android10.0 Binder通信原理(七)-Framework binder示例
Android10.0 Binder通信原理(八)-Framework层分析
Android10.0 Binder通信原理(九)-AIDL Binder示例
Android10.0 Binder通信原理(十)-AIDL原理分析-Proxy-Stub设计模式
Android10.0 Binder通信原理(十一)-Binder总结

《HwBinder通信原理》

HwBinder入门篇-Android10.0 HwBinder通信原理(一)
HIDL详解-Android10.0 HwBinder通信原理(二)
HIDL示例-C++服务创建Client验证-Android10.0 HwBinder通信原理(三)
HIDL示例-JAVA服务创建-Client验证-Android10.0 HwBinder通信原理(四)
HwServiceManager篇-Android10.0 HwBinder通信原理(五)
Native层HIDL服务的注册原理-Android10.0 HwBinder通信原理(六)
Native层HIDL服务的获取原理-Android10.0 HwBinder通信原理(七)
JAVA层HIDL服务的注册原理-Android10.0 HwBinder通信原理(八)
JAVA层HIDL服务的获取原理-Android10.0 HwBinder通信原理（九）
HwBinder驱动篇-Android10.0 HwBinder通信原理(十)
HwBinder原理总结-Android10.0 HwBinder通信原理(十一)

《编译原理》

编译系统入门篇-Android10.0编译系统（一）
编译环境初始化-Android10.0编译系统（二）
make编译过程-Android10.0编译系统（三）
Image打包流程-Android10.0编译系统（四）
Kati详解-Android10.0编译系统（五）
Blueprint简介-Android10.0编译系统（六）
Blueprint代码详细分析-Android10.0编译系统（七）
Android.bp 语法浅析-Android10.0编译系统（八）

1 概述

在 Android 7.0 之前，Android 编译系统使用 GNU Make 描述和shell来构建编译规则，模块定义都使用Android.mk进行定义，Android.mk的本质就是Makefile，但是随着Android的工程越来越大，模块越来越多，Makefile组织的项目编译时间越来越长。这样下去Google工程师觉得不行，得要优化。

因此，在Android7.0开始，Google采用ninja来代取代之前使用的make，由于之前的Android.mk数据实在巨大，因此Google加入了一个kati工具，用于将Android.mk转换成ninja的构建规则文件buildxxx.ninja,再使用ninja来进行构建工作。

ninja的网址：https://ninja-build.org

编译速度快了一些，但是既然要干，那就干个大的，最终目标要把make都取代，于是从Android8.0开始，Google为了进一步淘汰Makefile，因此引入了Android.bp文件来替换之前的Android.mk。

Android.bp只是一个纯粹的配置文件，不包括分支、循环语句等控制流程，本质上就是一个json配置文件。Android.bp 通过Blueprint+soong转换成ninja的构建规则文件build.ninja，再使用ninja来进行构建工作。

Android10.0上，mk和bp编译的列表可以从 \out\.module_paths中的Android.bp.list、Android.mk.list中看到，Android10.0还有400多个mk文件没有被替换完，Google任重道远。

Android编译演进过程：

1)Android7.0之前使用GNU Make

2)Android7.0 引入ninja、kati、Android.bp和soong构建系统

3)Android8.0 默认打开Android.bp

4)Android9.0 强制使用Android.bp

Google在 Android 7.0之后，引入了Soong构建系统，旨在取代make，它利用 Kati GNU Make 克隆工具和 Ninja 构建系统组件来加速 Android 的构建。

Make 构建系统得到了广泛的支持和使用，但在 Android 层面变得缓慢、容易出错、无法扩展且难以测试。Soong 构建系统正好提供了 Android build 所需的灵活性。

Ninja是一个注重速度的小型构建系统。它与其他构建系统在两个主要方面不同：它被设计为使其输入文件由更高级别的构建系统生成，并且被设计为尽可能快地运行构建。

Android系统的编译历程：

2 Make与ninja的对比

在传统的C/C++项目中，通常采用make系统使用Makefile来进行整个项目的编译构建，Makefile指定的编译依赖规则会使编译流程简单，但是make的依赖大而且复杂，在大型项目编译时，使用的模块越来越多，Makefile组织的项目编译时间越来越长，这个对于编译效率来说是一个极大的浪费。

Ninja是由Google员工Evan Martin 开发的小型构建系统。Ninja注重速度，它在两个主要方面与其他构建系统有所不同：Ninja被设计为使其输入文件由更高级别的构建系统生成，并且其被设计为尽可能快地运行构建。

本质上，Ninja旨在替换Make，这在执行增量（或无操作）构建时很慢。这可能会大大降低开发人员在大型项目上的工作速度，例如Google Chrome将40,000个输入文件编译为单个可执行文件。实际上，谷歌浏览器是忍者的主要用户和动机。它也用于构建Android ，并且被大多数从事LLVM的开发人员所使用。

与Make相比，Ninja缺少诸如字符串操作之类的功能，因为Ninja生成文件不是要手工编写的。相反，应使用“生成生成器”生成Ninja生成文件。Gyp，CMake，Meson和gn 是流行的构建管理软件工具，它们支持为Ninja创建构建文件。

Ninja开发时，认为make由以下几点导致编译慢：

隐式规则，make包含很多默认
变量计算，比如编译参与应该如何计算出来
依赖对象计算

ninja相对于make增加了下面这些功能：

如果构建命令发生变化，那么这个构建也会重新执行。
所依赖的目录在构建之前都已经创建了，如果不是这样的话，我们执行命令之前都要去生成目录。
每条构建规则，除了执行命令之外，还允许有一个描述，真正执行打印这个描述而不是实际执行命令。
每条规则的输出都是buffered的，也就是说并行编译，输入内容不会被搅和在一起。

针对这点所以基本上可以认为ninja就是make的最最精简版。

Make编译使用的文件名为Makefile、makefile或者以.make、.mk结尾的文件，Ninja的文件名一般为build.ninja或者以.ninja结尾的文件。

3 ninja的用法

3.1 ninja代码位置

Android自带ninja，ninja路径：

prebuilts/build-tools/darwin-x86/bin/ninja
prebuilts/build-tools/linux-x86/bin/ninja
prebuilts/build-tools/linux-x86/asan/bin/ninja

3.2 命令的用法

执行ninja -h 后，可以得到ninja的使用帮助说明

我们在编译时，常用的是-t参数。我们执行一下ninja -t list会得到相应的指令说明：

例如 ninja -t clean 用来清除编译中间文件，相比make clean减少了研发人员的开发过程。

指令说明：

ninja subtools:browse        # 在浏览器中浏览依赖关系图。（默认会在 8080 端口启动一个基于python的http服务）
clean         # 清除构建生成的文件
commands      # 罗列重新构建制定目标所需的所有命令
deps          # 显示存储在deps日志中的依赖关系
graph         # 为指定目标生成 graphviz dot 文件。#  如 ninja -t graph all |dot -Tpng -ograph.png
query         # 显示一个路径的inputs/outputs
targets       # 通过DAG中rule或depth罗列target
compdb        # dump JSON兼容的数据库到标准输出
recompact     # 重新紧凑化ninja内部数据结构

4 ninja的实践

4.1 下载ninja

下载地址：

git clone https://github.com/ninja-build/ninja.git

4.2 编译ninja

cd ninja
./configure.py --bootstrap #在ninja目录中执行

4.3 安装ninja

编译结束后，会在ninja目录中生成ninja的可执行程序ninja。可以直接将ninja程序拷贝到/usr/bin中。cp ./ninja /usr/bin #在ninja目录中执行

现在就可以在任意位置使用ninja了。

4.4 ninja实践

1)mkdir test

2)vim test/main.c

填入代码内容：

#include <stdio.h>
#include <stdlib.h>
int main() {printf("This is my first Ninja Project!\n");return 0;
}

3)配置build.ninja

vim build.ninja

填入内容：

cc = g++
cflags = -Wallrule cccommand = gcc $cflags -c $in -o $outdescription = compile .ccbuild foo.o: cc foo.c

4)编译：

cd test
ninja

5 ninja编译流程

5.1 AOSP编译过程

5.2.ninja生成过程

在编译过程中，Android.bp会被收集到out/soong/build.ninja.d,blueprint以此为基础，生成out/soong/build.ninja

Android.mk会由kati/ckati生成为out/build-aosp_arm.ninja

两个ninja文件会被整合进入out/combined-aosp_arm.ninja

最终由ninja -t out/combined-aosp_arm.ninja来完成最终的编译

out/combined-aosp_arm.ninja内容如下所示：

builddir = out
pool local_pooldepth = 42
build _kati_always_build_: phony
subninja out/build-aosp_arm.ninja
subninja out/build-aosp_arm-package.ninja
subninja out/soong/build.ninja

6 总结

Ninja的诞生，主要是为了提升编译速度，Ninja中去除了变量的计算，没有默认规则，依赖必须显式声明，从而提升编译速度。基本上可以认为ninja就是make的最最精简版。

参考：

《The Ninja build system》

《Ninja 构建系统》