摘要:如何通过Ninja来提升Android编译速度
阅读本文大约需要花费10分钟。
文章首发微信公众号: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编译系统(八)
- Ninja简介-Android10.0编译系统(九)
1.概述
上一节我们了解了Ninja的作用,虽然ninja相比make来说,提升了编译时间,但是当我们需要增量一个修改时,依旧需要花费不少时间,从log中,经常能看到前期花了很长时间,才走到“Starting ninja”这个字段,在这之前一直在做准备,那么我们要想办法提升一下ninja增量的编译速度。
2.编译分析
从Android O开始,soong已经是google的入口。从soong入口后,会经soong_ui,soong,kati,blueprint几个阶段,把mk,bp转换成ninja文件后,然后执行ninja命令解析ninja文件进行编译。
如下图所示整个编译过程,准备过程非常冗长。
每次编译都要重新收集所有的文件、.mk、.bp的修改,然后重新生成build.ninja,在合并成combined-aosp_arm.ninja。
大部分情况下,研发的工作是不断的修改.c .h .cpp .java 然后增量,此时真正的编译工作是非常少的,这样相对而言,准备工作往往是占大头的,所以我们可以考虑舍弃combined-aosp_arm.ninja之前的准备过程。
这里以增量编译init_system为例,之前我们已经编好了init_system,然后如果我们继续用m命令单编init_system,需要2分钟。
ingresge:~/AP/AOSP_Q$ time m init_system
[100% 6336/6336] Install: out/target/product/generic/fake_packages/init_system-timestamp
#### build completed successfully (02:37 (mm:ss)) ####
real 2m36.672s
user 43m51.510s
sys 2m51.991s
为了对比编译时间,我们直接抛弃了编译的环境和ninja文件生成的逐步过程,我们使用下面的命令直接跑ninja,结果只花了5秒。
命令:
time prebuilts/build-tools/linux-x86/bin/ninja -v -d keepdepfile init_system -f out/combined-aosp_arm.ninja -w dupbuild=err
编译结果:
ingresge:~/AP/AOSP_Q$ time prebuilts/build-tools/linux-x86/bin/ninja -v -d keepdepfile init_system -f out/combined-aosp_arm.ninja -w dupbuild=err
[7/7] /bin/bash -c "(rm -f out/target/product/generic/system/bin/init ) && (cp out/target/product/generic/obj/EXECUTABLES/init_second_stage_intermediates/init out/target/product/generic/system/bin/init )"
real 0m5.351s
user 0m14.752s
sys 0m3.201s
3.qninja提升编译速度
根据上一节分析到,舍弃combined-aosp_arm.ninja的准备过程,直接指向ninja可以提升速率,因此我们可以开发一个快速的编译命令,来提升研发的编译效率。
我们可以在修改build/make/envsetup.sh,新增一个qninja函数。
function qninja()
{
local cmdline="time prebuilts/build-tools/linux-x86/bin/ninja -v -d keepdepfile $@ -f out/combined-aosp_arm.ninja -w dupbuild=warn"
echo $cmdline
$cmdline
}
只是修改了某个模块中的.c .h .cpp .java后,进行增量,编译命令如下:
source build/envsetup.sh
qninja init_system
最终的编译时间仅仅花费了5秒:
real 0m5.351s
user 0m14.752s
sys 0m3.201s
4.总结
其实本节是提高了增量编译的速率,但是如果我们新增了.c .c++或者修改了.mk\.bp 的文件化,需要重新指向kati、soong的过程,用于手机新增文件或者新增编译参数的变化,最终重新生成combined-aosp_arm.ninja来参与编译,这个编译的速率还是会慢一些。需要在开发过程中注意这一点,以免引起qninja编译模块不生效的问题。