Android系統優化Ninja加快編譯

2022-08-09 18:02:18

背景

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加快編譯的資料請關注it145.com其它相關文章！