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加快编译的资料请关注我们其它相关文章!

时间: 2022-08-08

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

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

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&nbsp;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 源码编译错误的问题

如下所示: 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

关于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

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项目编译优化

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

用于cocos2d-x引擎(ndk)中为android项目生成编译文件列表

复制代码 代码如下: package com.leeass.generate; import java.io.File;import java.io.FileFilter;import java.io.FileNotFoundException; /** * 用于cocos2d-x引擎中android项目编译文件列表生成 * @author leeassamite * */public class GenerateAndroidMakefile { /** 分隔符 */ private stat

优化Vue项目编译文件大小的方法步骤

与其说是优化 Vue,不如说主要是在 webpack 打包的配置中做些文章,使得 Vue 编译后的文件尽可能的小.以下介绍自己在项目中进行优化的过程,其中的内容也许并不适合于每个项目,但整体思路是差不多的. 定位问题 要想进行优化,首先我们得清楚问题所在.即:是哪些代码/依赖包导致最后的编译文件过大? 这里,我们需要使用 webpack-bundle-analyzer 工具.修改 package.json 文件,添加: "analyze": "NODE_ENV=product

Vue项目打包编译优化方案

1. 不生成.map文件 默认情况下,当我们执行 npm run build 命令打包完一个项目后,会得到一个dist目录,里面有一个js目录,存放了该项目编译后的所有js文件. 我们发现每个js文件都有一个相应的 .map 文件,它们仅是用来调试代码的,可以加快打包速度,但会增大打包体积,线上我们是不需要这个代码的.这里我们需要配置不生成map文件. vue-cli2 config/index.js文件中,找到 productionSourceMap: true 这一行,将 true 改为 f

Jenkins使用Gradle编译Android项目详解

创建项目 在主界面的左侧菜单选 新建 在向导中选择 输入项目名称,类型选择 构建一个自由风格的软件项目 点确定进入项目的配置界面 源码管理 选择git Repository URL输入项目路径 比如 https://git.coding.net/coderstory/Mi-Purify.git Credentials是对应的账户密码 点击add按钮添加github账户密码 Branch Specifier 是选择具体的分支 默认是master 在构建大类中 勾选Invoke Gradle [不知

Android项目基本结构详解

一.简介 第3章虽然通过百度地图应用展示了你可能感兴趣的内容,但是,如果你是一个初学者,一开始就看懂和理解代码可能会非常费劲.为了解决此问题,从这一章开始,本模块将从最基本的内容讲起,带你逐步进入用C#进行Android应用开发的乐园. 二.AndroidApp入口 要用C#开发Android应用程序,首先需要对项目的基本结构有一个感性认识.如下图所示: Android应用程序使用的是单一入口,源程序中并不能一眼看出程序从哪开始运行,当应用程序加载到内存中时,Android操作系统会自动从内部自

用Eclipse搭建Android开发环境并创建第一个Android项目(eclipse+android sdk)

一.搭建Android开发环境 准备工作:下载Eclipse.JDK.Android SDK.ADT插件 1.安装和配置JAVA开发环境:  ①把准备好的Eclipse和JDK安装到本机上(最好安装在全英文路径下),并给JDK配置环境变量,其中JDK的变量值为JDK安装路径的根目录,如我的为:D:\Program Files\Java\jdk1.7.0_02: ②打开命令提示符(cmd),输入java -version命令,显示如下图则说明JAVA环境变量已经配置好了. 2.安装ADT插件: ①

浅析安卓(Android)的性能优化

Android性能的优化主要分为两点 1.布局优化 2.内存优化 布局优化 首先来看一下布局优化,系统在渲染UI的时候会消耗大量的资源,所以,对布局的优化就显得尤为重要 避免Overdraw 也就是避免过度的绘制,过度的绘制会浪费更多的资源,举个例子,Android系统会默认绘制Activity的背景,这时候我们再设置一个背景,这样默认的背景就属于过度绘制了,在『开发者工具』中有一个『调试GPU过度绘制』的选项,我们打开就可以通过颜色来判断过度绘制的次数 如图: 所以说我们尽可能的增大蓝色区域,

解决在eclipse中将android项目生成apk并且给apk签名的实现方法详解

生成apk最懒惰的方法是:只要你运行过android项目,到工作目录的bin文件夹下就能找到与项目同名的apk文件,这种apk默认是已经使用debug用户签名的.如果想要自己给apk签名:1.签名的意义为了保证每个应用程序开发商合法ID,防止部分开放商可能通过使用相同的Package Name来混淆替换已经安装的程序,我们需要对我们发布的APK文件进行唯一签名,保证我们每次发布的版本的一致性(如自动更新不会因为版本不一致而无法安装).2.签名的步骤a.创建keyb.使用步骤a中产生的key对ap

Android APP性能优化分析

本文通过Android APP性能优化的四个方面做了详细分析,并对原理和重点做了详细解释,以下是全部内容: 说到 Android 系统手机,大部分人的印象是用了一段时间就变得有点卡顿,有些程序在运行期间莫名其妙的出现崩溃,打开系统文件夹一看,发现多了很多文件,然后用手机管家 APP 不断地进行清理优化 ,才感觉运行速度稍微提高了点,就算手机在各种性能跑分软件面前分数遥遥领先,还是感觉无论有多大的内存空间都远远不够用.相信每个使用 Android 系统的用户都有过以上类似经历,确实,Android

vue-cli webpack2项目打包优化分享

减小文件搜索范围 配置 resolve.modules Webpack的resolve.modules配置模块库(即 node_modules)所在的位置,在 js 里出现 import 'vue' 这样不是相对.也不是绝对路径的写法时,会去 node_modules 目录下找.但是默认的配置,会采用向上递归搜索的方式去寻找,但通常项目目录里只有一个node_modules,且是在项目根目录,为了减少搜索范围,可以直接写明 node_modules 的全路径:同样,对于别名(`alias)的配置