Android系统优化Ninja加快编译

目录
  • 背景
  • 环境
  • 关键编译阶段和耗时分析
    • 阶段一:Soong bootstrap
    • 阶段二:Kati遍历、mk搜集与ninja生成
    • 阶段三:Ninja编译
  • 编译优化
  • 对比汇总

背景

Android系统模块代码的编译实在是太耗时了,即使寥寥几行代码的修改,也能让一台具有足够性能的编译服务器工作十几分钟以上(模块单编),只为编出一些几兆大小的jar和dex。

这里探究的是系统完成过一次整编后进行的模块单编,即m、mm、mmm等命令。

除此之外,一些不会更新源码、编译配置等文件的内容的操作,如touch、git操作等,会被Android系统编译工具识别为有差异,从而在编译时重新生成编译配置,重新编译并没有更新的源码、重新生成没有差异的中间文件等一系列严重耗时操作。

本文介绍关于编译过程中的几个阶段,以及这些阶段的耗时点/耗时原因,并最后给出一个覆盖一定应用场景的基于ninja的加快编译的方法(实际上是裁剪掉冗余的编译工作)。

环境

编译服务器硬件及Android信息:

  • Ubuntu 18.04.4 LTS
  • Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (28核56超线程)
  • MemTotal: 65856428 kB (62.8GiB)
  • AOSP Android 10.0
  • 仅修改某个Java文件内部的boolean初始化值(true改false)
  • 不修改其他任何内容,包括源码、mk、bp的情况下,使用m单编模块(在清理后,使用对比的ninja进行单编)
  • 使用time计时
  • 此前整个系统已经整编过一次
  • 编译时不修改任何编译配置文件如Android.mk

之所以做一个代码修改量微乎其微的case,是因为要分析编译性能瓶颈,代码变更量越小的情况下,瓶颈就越明显,越有利于分析。

关键编译阶段和耗时分析

由于Makefile结构复杂、不易调试、难以扩展,因此Android决定将它替换掉。Android在7.0时引入了Soong,它将Android从Makefile的编译架构带入到了ninja的时代。

Soong包含两大模块,其中Kati负责解析Makefile并转换为.ninja,第二个模块Ninja则基于生成的.ninja完成编译。

Kati是对GNU Make的clone,并将编译后端实现切换到ninja。Kati本身不进行编译,仅生成.ninja文件提供给Ninja进行编译。

Makefile/Android.mk -> Kati -> Ninja
Android.bp -> Blueprint -> Soong -> Ninja

因此在执行编译之前(即Ninja真正开动时),还有一些生成.ninja的步骤。关键编译阶段如下:

Soong的自举(Bootstrap),将Soong本身编译出来

系统代码首次编译会比较耗时,其中一个原因是Soong要全新编译它自己

遍历源码树,收集所有编译配置文件(Makefile/Android.mk/Android.bp)

  • 遍历、验证非常耗时,多么强劲配置的机器都将受限于单线程效率和磁盘IO效率
  • 由于Android系统各模块之间的依赖、引入,因此即使是单编模块,Soong(Kati)也不得不确认目标模块以外的路径是否需要重新跟随编译。

验证编译配置文件的合法性、有效性、时效性、是否应该加入编译,生成.ninja

  • 如果没有任何更改,.ninja不需要重新生成
  • 最终生成的.ninja文件很大(In my case,1GB以上),有很明显的IO性能效率问题,显然在查询效率方面也很低下

最后一步,真正执行编译,调用ninja进入多线程编译

  • 由于Android加入了大量的代码编译期工作,如API权限控制检查、API列表生成等工作(比如,生成系统API保护名单、插桩工作等等),因此编译过程实际上不是完全投入到编译中
  • 编译过程穿插“泛打包工作”,如生成odex、art、res资源打包。虽然不同的“泛打包”可以多线程并行进行,但是每个打包本身只能单线程进行

下面将基于模块单编(因开发环境系统全新编译场景频率较低,不予考虑),对这四个关键阶段进行性能分析。

阶段一:Soong bootstrap

在系统已经整编过一次的情况下,Soong已经完成了编译,因此其预热过程占整个编译时间的比例会比较小。

在“环境”下,修改一行Framework代码触发差异进行编译。并且使用下面的命令进行编译。

time m services framework -j57

编译实际耗时22m37s:

build completed successfully (22:37 (mm:ss)) ####
real    22m37.504s
user    110m25.656s
sys     12m28.056s

对应的分阶段耗时如下图。

  • 可以看到,包括Soong bootstrap流程在内的预热耗时占比非常低,耗时约为11.6s,总耗时约为1357s,预热耗时占比为0.8%

  • Kati和ninja,也就是上述编译关键流程的第2步和第3步,分别占了接近60%(820秒,13分钟半)和约35%(521秒,8分钟半)的耗时,合计占比接近95%的耗时。

注:这个耗时是仅小幅度修改Java代码后测试的耗时。如果修改编译配置文件如Android.mk,会有更大的耗时。

小结:看来在完成一次整编后的模块单编,包括Soong bootstrap、执行编译准备脚本、vendorsetup脚本的耗时占比很低,可以完全排除存在性能瓶颈的可能。

阶段二:Kati遍历、mk搜集与ninja生成

从上图可以看到,Kati耗时占比很大,它的任务是遍历源码树,收集所有的编译配置文件,经过验证和筛选后,将它们解析并转化为.ninja

从性能角度来看,它的主要特点如下:

  • 它要遍历源码树,收集所有mk文件(In my case,有983个mk文件)
  • 解析mk文件(In my case,framework/base/Android.mk耗费了~6800ms)
  • 生成并写入对应的.ninja
  • 单线程

直观展示如下,它是一个单线程的、IO速度敏感、CPU不敏感的过程:

Kati串行地处理文件,此时对CPU利用率很低,对IO的压力也不高。

小结:可以确定它的性能瓶颈来源于IO速度,单纯为编译实例分配更多的CPU资源也无益于提升Kati的速度。

阶段三:Ninja编译

SoongClone了一份GNU Make,并将其改造为Kati。即使我们没有修改任何mk文件,前面Kati仍然会花费数分钟到数十分钟的工作耗时,只为了生成一份能够被Ninja.ninja的生成工具能够识别的文件。接下来是调用Ninja真正开始编译工作。

从性能角度来看,它的主要特点如下:

  • 根据目标target及依赖,读取前面生成的.ninja配置,进行编译
  • 比较独立,不与前面的组件,如blueprint、kati等耦合,只要.ninja文件中能找到target和build rule就能完成编译
  • 多线程

直观展示如下,Ninja将会根据传入的并行任务数参数启动对应数量的线程进行编译。Ninja编译阶段会真正的启动多线程。但做不到一直多线程编译,因为部分阶段如部分编译目标(比如生成一个API文档)、泛打包阶段等本身无法多线程并行执行。

可以看到此时CPU利用率应该是可以明显上升的。但是耗时较大的阶段仅启用了几个线程,后面的阶段和最后的图形很细(时间占比很小)的阶段才用起来更多的线程。

其中,一些阶段(图中时间占比较长的几条记录)没能跑满资源的原因是这些编译目标本身不支持并行,且本次编译命令指定的目标已经全部“安排”了,不需要调动更多资源启动其他编译目标的工作。当编译整个系统时就能够跑满了。

最后一个阶段(图中最后的几列很细的记录)虽然跑满了所有线程资源,但是运行时间很短。这是因为本case进行编译分析的过程中,仅修改了一行代码来触发编译。因编译工作量很小,所以这几列很细。

小结:我们看到,Ninja编译启动比较快,这表明Ninja.ninja文件的读取解析并不敏感。整个过程也没有看到显著的耗时点。且最后面编译量很小,表明Ninja能够确保增量编译、未更新不编译。

编译优化

本节完成点题——Android系统编译优化:使用Ninja加快编译。

根据前面分析的小结,可以总结性能瓶颈:

  • Kati遍历、生成太慢,受限于IO速率
  • Kati吞吐量太低,单线程
  • 不论有无更新均重新解析Makefile

利用Ninja进行编译优化的思路是,大多数场景,可以舍弃Kati的工作,仅执行Ninja的工作,以节省掉60%以上的时间。其核心思路,也是制约条件,即在不影响编译正确性的前提下,舍弃不必要的Kati编译工作。

  • 使用Ninja直接基于.ninja文件进行编译来改善耗时:

结合前面的分析,容易想到,如果目标被构建前,能够确保mk文件没有更新也不需要重新生成一长串的最终编译目标(即.ninja),那么make命令带来的Soong bootstrap、Kati等工作完全是重复的冗余的——这个性质Soong和Kati自己识别不出来,它们会重复工作一次。

既重新生成.ninja是冗余的,那么直接命令编译系统根据指定的.ninja进行编译显然会节省大量的工作耗时。ninja命令is the key:

使用源码中自带的ninja:

./prebuilts/build-tools/linux-x86/bin/ninja --version
1.8.2.git

对比最上面列出的make命令的编译,这里用ninja编译同样的目标:

 time ./prebuilts/build-tools/linux-x86/bin/ninja
 -j 57 -v -f out/combined-full_xxxxxx.ninja services framework

ninja自己识别出来CPU平台后,默认使用-j58。这里为了对比上面的m命令,使用-j57编译

-f参数指定.ninja文件。它是编译配置文件,在Android中由Kati生成。这里文件名用'x'替换修改

编译结果,对比上面的m,有三倍的提升:

real    7m57.835s
user    97m12.564s
sys     8m31.756s

编译耗时为8分半,仅make的三分之一。As we can see,当能够确保编译配置没有更新,变更仅存在于源码范围时,使用Ninja直接编译,跳过Kati可以取得很显著的提升

直接使用ninja:

./prebuilts/build-tools/linux-x86/bin/ninja
-j $MAKE_JOBS -v -f out/combined-*.ninja <targets...>

对比汇总

这里找了一个其他项目的编译Demo,该Demo的特点是本身代码较简单,编译配置也较简单,整体编译工作较少,通过make编译的大部分耗时来自soong、make等工具自身的消耗,而真正执行编译的ninja耗时占比极其低。由于ninja本身跳过了soong,因此可以跳过这一无用的繁琐的耗时。可以看到下面,ninja编译iperf仅花费10秒。这个时间如果给soong来编译,预热都不够。

$ -> f_ninja_msf iperf
Run ninja with out/combined-full_xxxxxx.ninja to build iperf.
====== ====== ======
Ninja: ./prebuilts/build-tools/linux-x86/bin/ninja@1.8.2.git
Ninja: build with out/combined-full_xxxxxx.ninja
Ninja: build targets iperf
Ninja: j72
====== ====== ======
time /usr/bin/time ./prebuilts/build-tools/linux-x86/bin/ninja -j 72 -f out/combined-full_xxxxxx.ninja iperf
[24/24] Install: out/target/product/xxxxxx/system/bin/iperf
53.62user 11.09system 0:10.17elapsed 636%CPU (0avgtext+0avgdata 5696772maxresident)
4793472inputs+5992outputs (4713major+897026minor)pagefaults 0swaps
real    0m10.174s
user    0m53.624s
sys     0m11.096s

下面给出soong编译的恐怖耗时:

$ -> rm out/target/product/xxxxxx/system/bin/iperf
$ -> time m iperf -j72
...
[100% 993/993] Install: out/target/product/xxxxxx/system/bin/iperf
#### build completed successfully (14:45 (mm:ss)) ####
real    14m45.164s
user    23m40.616s
sys     11m46.248s

As we can see,m和ninja一个是10+ minutes,一个是10+ seconds,比例是88.5倍。

以上就是Android系统优化Ninja加快编译的详细内容,更多关于Android Ninja加快编译的资料请关注我们其它相关文章!

(0)

相关推荐

  • 关于AndroidStudio新建与编译项目速度慢解决办法

    android第一次新建项目是,相关依赖包需要下载很久,至少半小时,因为网速问题,还会多次下载失败. 解决办法如下: 1.通过镜像将gradle-5.4.1-all.zip下载到本地:解压到文件夹:D:\software\gradle\gradle-5.4.1作为GRADLE_HOME目录 GRADLE_HOME=D:\software\gradle\gradle-5.4.1 GRADLE_USER_HOME=D:\software\gradle 2.修改gradle文件夹下的gradle-wr

  • Windows配置VSCode+CMake+Ninja+Boost.Test的C++开发环境(教程详解)

    平时习惯了在Linux环境写C++,有时候切换到Windows想继续在同一个项目上工作,重新配置环境总是很麻烦.虽然Windows下用Visual Studio写C++只需要双击个图标,但我还是想折腾一下VS Code的环境配置.原因主要有两点:一是个人习惯上各种语言都在VS Code里面写,利用Git同步代码可以很方便地在不同平台开发同一个项目:二是有些情形下无法使用图形化界面,比如为Git配置CI(持续性集成)时显然不能用Visual Studio这个图形化的IDE来执行Windows环境的

  • 解决Android 源码编译错误的问题

    如下所示: Building with Jack: out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/with-local/classes.dex FAILED: /bin/bash out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/with-local/classes.dex.rsp Out of memory error (version 1.2-a

  • Android Studio编写AIDL文件后如何实现自动编译生成

    在目录src/main 下新建了aidl 文件夹之后,在aidl文件夹中也创建了相同的包路径, 创建AIDL文件 XXX.aidl 如果XXX.aidl引用了一个java下的model例如引用了a.b.c.Model; 则需要在XXX.aidl文件中声明import a.b.c.Model;全路径. 并且创建另一个文件Model.aidl 在Model.aidl文件中声明以下内容 package xxxx包名称; parcelable Model; 如果编译的时候提示AIDL文件引用的包找不到的

  • Android Studio通过Artifactory搭建本地仓库优化编译速度的方法

    Android Studio 编译速度慢,一般来说,原因有下面几个. Gradle下载慢 依赖库下载慢 依赖库使用"+"(使用最新的),每次都需要去查找新的(尽量不适用这种方式) 这里,大部分的库,我们可以通过阿里云代理仓库. 但是,如果有我们自己的私有库或者插件的话.肯定不希望放到阿里云上了. 这个时候,我们就需要建立,我们自己的本地仓库,让私有仓库,依赖阿里云的私有仓库. 依赖关系,如下图 这样,既保证了我们私有库的安全性,又让我们的依赖库也享受到了阿里云代理仓库的便利. 通过Ar

  • 关于android studio通过命令行运行gradle编译命令的问题

    报错:Could not resolve all dependencies for configuration ':classpath'  打开android-studio的terminal,运行命令 gradlew -debug 或者 gradlew -info 发现错误 根据提示(利用gradle.perperties),解决了jdk版本问题 org.gradle.java.home=D\:/android/android-studio/jre/ 到此这篇关于关于android studio

  • 哔哩哔哩Android项目编译优化

    目录 背景 编译优化 工作流程 快编插件 获取工程树结构 version版本 源码orAAR 主动Skip模块 Configuration策略 远端upload R8 class check Faster 云编译 独立的编译单元 展望 结语 背景 哔哩哔哩的安卓项目的工程结构是Monorepo(单仓)变种,也就是所有的代码都在一个工程结构下编译.我们认为Monorepo(单仓)是一个非常适合我们的开发模式,主要是因为其提供的原子提交,可见性,参与度,切片的稳定性等等优点,这些都是我们选择Mono

  • Android系统优化Ninja加快编译

    目录 背景 环境 关键编译阶段和耗时分析 阶段一:Soong bootstrap 阶段二:Kati遍历.mk搜集与ninja生成 阶段三:Ninja编译 编译优化 对比汇总 背景 Android系统模块代码的编译实在是太耗时了,即使寥寥几行代码的修改,也能让一台具有足够性能的编译服务器工作十几分钟以上(模块单编),只为编出一些几兆大小的jar和dex. 这里探究的是系统完成过一次整编后进行的模块单编,即m.mm.mmm等命令. 除此之外,一些不会更新源码.编译配置等文件的内容的操作,如touch

  • XCode 加快编译链接速度的方法

    加快XCode的编译链接速度,XCode编译速度慢的解决方案 最近在开发一个大项目的时候遇到一个很头疼的问题,由于项目代码较多,每次都要编译链接1分钟左右,调试的时候很浪费时间,于是研究了一下如何提高编译链接的速度,在这里分享给大家. 提升编译链接的速度主要有以下三个方式: 1. 提高XCode编译时使用的线程数 defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4 XCode默认使用与CPU核数相同的线程来进行编译,

  • Android 源码如何编译调试

    android提供的工具链和开发工具比较完善,因此它的开发环境的搭建比较简单,相信许多朋友都已经搭建好环境,并编写了HelloActivity入门程序了.这里先看几个问题: 1.android的文件系统结构是怎样的,我们安装的程序放在那里? 编译android源码之后,在out/target/product/generic一些文件: ramdisk.img.system.img.userdata.img. system. data.root 其中, system.img是由 system打包压缩

  • 在Android源码中编译出指定jar包的操作

    今天想把android源码/vendor/letv/frameworks/base/java下的源码编译成 framework-letv.jar供乐乐语音客户端使用,编译完后,发现jar包文件虽然生成了,但包里面并没有相关的源码class文件,无法正常使用. 经过请教加研究发现,Android.mk文件需要添加选项如下: 54 LOCAL_JACK_ENABLED := disabled # important! 55 #include $(BUILD_JAVA_LIBRARY) 56 incl

  • 使用android studio开发工具编译GBK转换三方库iconv的方法

    网上大多教程和资源并没有从头到尾告诉怎么编译过程,这边文章教你一个对ndk编译懂的不多,又需要使用三方库,怎么办,硬着头皮搞,又无从下手,网上一堆资料,有价值的不多,到处是偏分的.本篇提供真实能运行,带的资源经过测试的.过程如下: 编译ICONV 1.1 解压缩 1.解压缩:  tar -xvf  ./libiconv-1.14.tar.gz  -C libiconv-1.14 2.配置:./configure --host=arm-linux-gnueabihf CC=/home/work/r

  • 使用cache加快编译速度的命令详解

    目录 Ubuntu 安装ccache 使用libzmq测试ccache Ubuntu 安装ccache sudo apt-get install ccache 安装完后确认安装执行which ccache $ which ccache /usr/bin/ccache 3.在 ~/.bashrc 或者 ~/.zshrc文件内追加以下内容 # ccache export USE_CCACHE=1 export CCACHE_SLOPPINESS=file_macro,include_file_mti

  • android studio2.3如何编译动态库的过程详解

    前言 最近在工作中需要编译android下的动态库,本以为是一件简单的事,没想到因为工具,以及google本身被墙的原因,折腾了好久. 在windows外的平台搞事情,寿命都得缩短. 过程如下 一种方案是用eclipse+ndk+adt插件,总之是eclipse下适配android ndk的一套东西,我搜了一些文档,看到一大堆冗余的名字,文件,感觉不对味,放弃. 另一种方案是android studio,初看觉得是大公司出品,且针对的是自家系统的IDE,能保持个一贯性,没想到各个版本差别挺大,一

  • Android开发apk反编译和二次打包教程

    作为Android开发者,工作中少不了要反编译别人的apk,当然主要目的还是为了学习到更多,取彼之长,补己之短.今天就来总结一下Android反编译和二次打包的一些知识.首先声明本文的目的是为了通过例子讲解反编译和二次打包的原理和方法,继而作为后续讲解防止二次打包和App安全的依据,并不是鼓励大家去重新打包别人的App,盗取他人劳动成果. 本文首先介绍几种Android反编译工具的使用,然后实现在不需要知道源代码的情况下,仅通过修改反编译得到的smali文件实现修改apk逻辑功能的目的. And

  • Android应用程序的编译流程及使用Ant编译项目的攻略

    Android 工程构建的持续集成,需要搭建一套编译和打包自动化流程,比如建立每日构建系统.自动生成发布文件等等.这些都需要我们对Android工程的编译和打包有一个比较深入的理解,例如知道它的每一步都做了什么,需要什么环境和工具,输入和输出是什么,等等. 首先,假定你的系统(Windows.Linux.Mac OS都行,本文默认使用Linux系统来举例子,但在 Windows中几乎没有什么差别)已经安装了JDK和Android SDK. 我们重点关心的是:     (1)这个过程的输入是什么?

  • android开发实践之ndk编译命令简单示例

    前言 Android提供了NDK工具,用来编译native代码(c/c++),该工具配置好了相关的交叉编译环境和工具链,只需要你简单地编写几个.mk文件即可将你的c/c++代码编译为Android的java工程/Android手机可以识别.加载和运行的库或者应用程序. 默认情况下,使用NDK编译c/c++代码,需要将该代码放置到任一个Android应用工程的jni目录下,然后编写相应的Android.mk文件,并执行ndk-build命令完成编译.其实你也是可以在任意目录下去编译native代码

随机推荐