直接進(jìn)入正題。AOSP構(gòu)建這話題說實(shí)話每次提起來都讓人又愛又恨。愛的是安卓開源生態(tài)給了我們無限折騰的空間恨的是每次全量編譯動(dòng)不動(dòng)三四十分鐘起步改一行代碼驗(yàn)證一下又得等十分鐘一整天的時(shí)間就這么被切碎在進(jìn)度條里。我在團(tuán)隊(duì)里負(fù)責(zé)系統(tǒng)構(gòu)建維護(hù)接手那陣子最大的感受就是大家都在默默等編譯然后假裝自己很忙實(shí)際上效率黑洞已經(jīng)吃掉了半天工時(shí)。這篇文章我不打算堆概念就把自己實(shí)際壓構(gòu)建時(shí)間、降編譯成本的經(jīng)驗(yàn)拆開講包括怎么定位瓶頸、怎么配環(huán)境、怎么用緩存、怎么處理增量構(gòu)建里那些反直覺的坑以及想上分布式構(gòu)建的話從哪兒入手最穩(wěn)妥。標(biāo)題里說的最新技術(shù)報(bào)告其實(shí)是我整理的一份構(gòu)建性能分析清單和調(diào)優(yōu)參數(shù)對(duì)照表文末我會(huì)把獲取方式放出來免費(fèi)領(lǐng)不需要你轉(zhuǎn)發(fā)集贊純粹覺得這些東西值得擴(kuò)散。1. 先搞清楚時(shí)間都去哪了構(gòu)建鏈路的分段剖析優(yōu)化一件事之前第一步永遠(yuǎn)是量化。很多同學(xué)一上來就調(diào)-j參數(shù)、加ccache其實(shí)是在沒看清瓶頸的情況下盲目使勁。AOSP構(gòu)建看著是一個(gè)大命令實(shí)際上內(nèi)部是串行加并行混合的多階段流水線每個(gè)階段的開銷特征完全不同盲調(diào)只能碰運(yùn)氣。1.1 AOSP構(gòu)建過程到底分幾個(gè)階段整個(gè)構(gòu)建從源頭到產(chǎn)物大致走這么幾段第一步是配置解析。Soong讀取所有Android.bp和Android.mk文件解析模塊定義、依賴關(guān)系生成Ninja構(gòu)建規(guī)則。這個(gè)階段是單線程主吃的是CPU單核性能項(xiàng)目越大解析越慢。第二步是Ninja構(gòu)建圖加載。Soong輸出的build.ninja文件往往有幾百萬行級(jí)別的規(guī)則Ninja啟動(dòng)時(shí)要把這張圖全部加載進(jìn)內(nèi)存這個(gè)階段吃內(nèi)存和大文件IO磁盤速度直接決定啟動(dòng)耗時(shí)。第三步是任務(wù)調(diào)度與執(zhí)行。Ninja根據(jù)依賴圖把幾十萬個(gè)編譯任務(wù)分發(fā)到各并行進(jìn)程這里頭C/C、Rust、Java、資源打包、proto編譯、文檔生成混合在一起各自吃不同的資源。第四步是鏡像打包與簽名。所有模塊編完以后target_files打包、system/vendor/boot各個(gè)分區(qū)鏡像生成、簽名校驗(yàn)、AVB哈希計(jì)算這階段是IO密集型加少量計(jì)算密集型。我最早踩的坑就是拿time只看總耗時(shí)然后對(duì)著總耗時(shí)瞎猜。后來把ninja -t stats打開一跑才發(fā)現(xiàn)配置解析和Ninja圖加載這兩個(gè)階段加起來占了全量構(gòu)建的15%以上而這部分恰恰是加多少核都提速不了的。1.2 用數(shù)據(jù)定位瓶頸而不是靠感覺AOSP內(nèi)置的構(gòu)建統(tǒng)計(jì)工具不多但夠用。我常用的排查鏈路是這樣全量構(gòu)建跑一遍注意記錄總時(shí)間。然后單獨(dú)跑一次m nothing這個(gè)命令不做真實(shí)編譯只重新解析配置并加載Ninja圖它的耗時(shí)就是構(gòu)建圖處理的固定開銷。接著跑ninja -t stats這個(gè)命令會(huì)告訴你整個(gè)執(zhí)行期間各任務(wù)的累計(jì)時(shí)間和數(shù)量分布。舉個(gè)例子我優(yōu)化前跑m nothing耗時(shí)接近兩分半說明光配置解析加圖加載就要150秒。當(dāng)時(shí)我第一反應(yīng)是關(guān)掉不必要的product配置把沒用的模塊從PRODUCT_PACKAGES里摘掉同時(shí)把一些極少用到的Android.bp做條件編譯隔離結(jié)果m nothing直接降到50秒內(nèi)。這一步不動(dòng)任何編譯參數(shù)光靠瘦身就省了兩分鐘。至于執(zhí)行階段ninja -t stats會(huì)按任務(wù)類型給出累計(jì)耗時(shí)。我這里列一個(gè)常見分布方便你對(duì)號(hào)入座任務(wù)類型典型占比資源特征C/C 編譯40%-60%CPU密集多核并行收益大Rust 編譯5%-15%CPU密集增量較快Java/Kotlin 編譯10%-20%內(nèi)存密集容易OOM鏈接5%-10%單線程居多吃內(nèi)存帶寬資源處理/打包5%-10%IO密集走文件系統(tǒng)proto/AIDL生成3%-8%混合任務(wù)量大但單個(gè)快如果你的項(xiàng)目C/C編譯占比過半那優(yōu)化的主戰(zhàn)場(chǎng)就是并行度和緩存。如果Java編譯占比異常高得檢查是不是每次都全量重編了。如果資源處理占比高就該看磁盤IO了。2. 主機(jī)環(huán)境配置的取舍CPU、內(nèi)存、磁盤與系統(tǒng)參數(shù)AOSP構(gòu)建本質(zhì)上是一場(chǎng)資源換時(shí)間的游戲但資源怎么花、花在哪里面有很多門道。我見過有人用128核服務(wù)器編AOSP結(jié)果還沒16核筆記本快的問題幾乎都出在內(nèi)存和磁盤上。2.1 CPU核心數(shù)與內(nèi)存的匹配關(guān)系并行度不是越高越好。AOSP默認(rèn)的-j參數(shù)會(huì)根據(jù)核數(shù)自適應(yīng)但每個(gè)編譯進(jìn)程平均要吃1GB到2GB內(nèi)存。如果你32核卻只有32GB內(nèi)存開滿并行很容易觸發(fā)OOM內(nèi)核開始swap之后整個(gè)構(gòu)建反而比少開幾個(gè)核更慢。我的經(jīng)驗(yàn)值是這樣內(nèi)存GB數(shù)除以1.5再跟CPU核數(shù)取較小值大概就是這臺(tái)機(jī)器比較穩(wěn)的-j上限。比如64GB內(nèi)存配32核穩(wěn)妥的并行數(shù)是min(32, 64/1.5)約等于42但實(shí)際跑的時(shí)候還要留出2GB到4GB給Soong解析和Ninja圖加載所以建議直接設(shè)-j40。另一個(gè)隱藏坑是內(nèi)存頻率和通道數(shù)。鏈接階段尤其是lld鏈接大型可執(zhí)行文件極度依賴內(nèi)存帶寬。雙通道DDR4和四通道DDR5的差距在鏈接階段能差出一倍時(shí)間。如果你有升級(jí)硬件的預(yù)算優(yōu)先保證內(nèi)存通道數(shù)而不是盲目沖CPU核數(shù)。2.2 out目錄放哪SSD、NVMe還是內(nèi)存盤AOSP的out/目錄是IO壓力最集中的地方。編譯產(chǎn)物、中間文件、鏡像生成全在這。用機(jī)械硬盤編AOSP基本是災(zāi)難建議直接排除這個(gè)選項(xiàng)。SATA SSD可用但會(huì)發(fā)現(xiàn)大量小文件讀寫場(chǎng)景下比如資源打包和proto生成依然有瓶頸。NVMe SSD是目前的甜點(diǎn)選擇PCIe 3.0以上型號(hào)能把小文件隨機(jī)讀寫的延遲壓得很低。再往上就是tmpfs把out/掛到內(nèi)存盤上。這個(gè)方案對(duì)構(gòu)建提速效果極猛IO密集任務(wù)幾乎零延遲。但代價(jià)是內(nèi)存被out目錄吃掉了大半而且掉電即失。我試過用/dev/shm掛out目錄跑小型target的增量構(gòu)建速度快得離譜但全量構(gòu)建時(shí)內(nèi)存根本扛不住。所以我的建議是有256GB以上內(nèi)存的機(jī)器可以開一個(gè)128GB的tmpfs掛out/跑增量驗(yàn)證內(nèi)存不足的老老實(shí)實(shí)用NVMe。另外文件系統(tǒng)格式也要注意。ext4是默認(rèn)選擇但開啟inline_data和lazy_itable_init掛載選項(xiàng)后小文件創(chuàng)建效率有明顯提升。如果你用f2fs隨機(jī)寫入表現(xiàn)會(huì)更好。還有個(gè)大坑是不要跨文件系統(tǒng)軟鏈out目錄有些構(gòu)建腳本對(duì)符號(hào)鏈接的解析有毛病容易整出詭異錯(cuò)誤。2.3 值得一提的內(nèi)核參數(shù)和編譯鏡像選擇內(nèi)存壓力大的機(jī)器建議檢查vm.swappiness。默認(rèn)值60意味著系統(tǒng)會(huì)在內(nèi)存還剩很多的時(shí)候就開始換頁對(duì)構(gòu)建這種內(nèi)存瞬時(shí)尖峰高的負(fù)載很不利。我通常設(shè)成10讓內(nèi)核盡量多扛一會(huì)再動(dòng)swap。vm.overcommit_memory也值得關(guān)注。AOSP的Java編譯進(jìn)程會(huì)一次性申請(qǐng)大塊虛擬內(nèi)存如果系統(tǒng)拒絕overcommit可能導(dǎo)致編譯進(jìn)程直接崩。設(shè)成1可以避免這類問題但要留意這會(huì)增加OOM風(fēng)險(xiǎn)最好配合swap分區(qū)分一個(gè)足夠大的回退空間。編譯鏡像選擇上AOSP官方推薦Ubuntu LTS但不是越新越好。我踩過坑新版Ubuntu自帶的GCC版本過高和AOSP預(yù)編譯的工具鏈在某些頭文件解析上有兼容問題。目前我主力環(huán)境還是Ubuntu 22.04配合AOSP官方文檔驗(yàn)證過的JDK版本最省心。別在生產(chǎn)構(gòu)建機(jī)上亂升級(jí)系統(tǒng)構(gòu)建環(huán)境穩(wěn)定比什么都重要。3. ccache配置最便宜也最容易配錯(cuò)的提速手段如果你只能做一項(xiàng)優(yōu)化那就配ccache。它能把C/C編譯的重復(fù)勞動(dòng)直接抹掉尤其是全量構(gòu)建之后的第二次構(gòu)建命中率高的時(shí)候壓縮一半時(shí)間都正常。但ccache不是裝完就完事配置不當(dāng)反而會(huì)引入各種詭異問題。3.1 ccache在AOSP中的正確打開方式AOSP自帶ccache預(yù)編譯版本路徑在prebuilts/ccache/不需要自己安裝。但默認(rèn)不啟用需要手動(dòng)設(shè)置環(huán)境變量export USE_CCACHE1 export CCACHE_DIR/path/to/ccache prebuilts/ccache/ccache -M 50G-M參數(shù)是緩存容量上限。這個(gè)值取決于你常編的模塊規(guī)模。只編單個(gè)模塊20G夠用經(jīng)常全量構(gòu)建建議50G到100G。緩存太小會(huì)導(dǎo)致舊條目頻繁被逐出命中率上不去白忙一場(chǎng)。最好把這幾個(gè)命令寫進(jìn)~/.bashrc或者構(gòu)建腳本里否則每次新開終端都忘了設(shè)。我見過有人配置了半天發(fā)現(xiàn)沒生效就是環(huán)境變量沒持久化。3.2 命中率怎么查以及典型數(shù)值參考構(gòu)建跑完以后執(zhí)行ccache -s能看到命中率、緩存大小、未命中原因統(tǒng)計(jì)。一個(gè)健康的緩存狀態(tài)第二次全量構(gòu)建的命中率應(yīng)該在70%以上增量構(gòu)建命中率能到90%以上。如果命中率異常低優(yōu)先查這幾種情況編譯器路徑變化。如果你手動(dòng)切換了clang版本、或者構(gòu)建腳本動(dòng)態(tài)設(shè)置了CC/CXX變量ccache會(huì)因編譯器二進(jìn)制不同而失配。排查方法是在ccache -s里看Compiler version mismatch計(jì)數(shù)。源碼路徑變化。ccache默認(rèn)把絕對(duì)路徑作為緩存key的一部分。如果你把源碼目錄從/home/aosp挪到/data/build/aosp等于緩存全部失效。這個(gè)看Cant find source file計(jì)數(shù)能確定。預(yù)處理輸出變化。頭文件里的時(shí)間戳、__DATE__這類宏會(huì)讓預(yù)處理結(jié)果每次都不同ccache只能被迫存新條目。項(xiàng)目里如果有第三方庫自帶這種不確定性建議在Android.bp里關(guān)掉相關(guān)宏或者統(tǒng)一時(shí)間戳。3.3 多用戶共享緩存與CI場(chǎng)景的實(shí)戰(zhàn)經(jīng)驗(yàn)團(tuán)隊(duì)開發(fā)場(chǎng)景下每個(gè)開發(fā)者各自維護(hù)一份ccache很浪費(fèi)。讓所有人的緩存指向同一個(gè)NFS目錄效果接近分布式緩存且配置極其簡(jiǎn)單。但共享緩存有幾個(gè)坑得避開。第一是權(quán)限NFS共享目錄要確保所有用戶可寫且umask不能太嚴(yán)格否則緩存文件寫不進(jìn)去ccache會(huì)靜默降級(jí)為不緩存。第二是目錄鎖老版本ccache在并發(fā)寫同一個(gè)緩存目錄時(shí)會(huì)有鎖競(jìng)爭(zhēng)多用戶同時(shí)構(gòu)建時(shí)反而變慢。建議升級(jí)到ccache 4.x以上并發(fā)控制好很多。第三是網(wǎng)絡(luò)穩(wěn)定性NFS抖動(dòng)一次構(gòu)建進(jìn)程可能直接卡死CI環(huán)境里特別致命。我的實(shí)際配置是內(nèi)網(wǎng)一臺(tái)存儲(chǔ)服務(wù)器開NFS緩存目錄設(shè)100GCI節(jié)點(diǎn)和開發(fā)機(jī)構(gòu)掛載到同一個(gè)CCACHE_DIR。實(shí)測(cè)下來一個(gè)團(tuán)隊(duì)五個(gè)人同時(shí)構(gòu)建緩存命中率依舊能維持在60%左右每個(gè)人節(jié)省的編譯時(shí)間非?？捎^。4. 增量構(gòu)建的意外重編級(jí)聯(lián)依賴和隱式全量增量構(gòu)建本該是效率神器但在AOSP里經(jīng)常出現(xiàn)一個(gè)現(xiàn)象明明只改了一個(gè)Java文件結(jié)果重編了上千個(gè)模塊。這背后是依賴圖和構(gòu)建緩存機(jī)制的耦合問題理解了才能有效規(guī)避。4.1 為什么改一行代碼會(huì)觸發(fā)大規(guī)模重編AOSP的構(gòu)建系統(tǒng)是基于Ninja的Ninja只認(rèn)依賴關(guān)系。當(dāng)某個(gè)頭文件被改動(dòng)所有#include了它的源文件都會(huì)被標(biāo)記為過期。問題出在AOSP源碼里大量頭文件層層包含一個(gè)底層頭文件稍微動(dòng)一下上層幾千個(gè)源文件全得重編。典型的例子是修改了system/core底層的某個(gè)通用頭文件整個(gè)framework層的C代碼幾乎都要重編。這個(gè)不算bug是C/C的預(yù)處理器模型決定的但可以通過合理的頭文件隔離來減小爆炸半徑。另一個(gè)容易被忽視的是靜態(tài)庫依賴。AOSP里很多模塊以靜態(tài)庫形式被多個(gè)可執(zhí)行文件依賴。改動(dòng)一個(gè)靜態(tài)庫的接口所有依賴它的可執(zhí)行文件都要重鏈鏈接又是單線程的時(shí)間開銷極大。我在項(xiàng)目里強(qiáng)制要求對(duì)外接口盡量穩(wěn)定改動(dòng)時(shí)優(yōu)先在這些庫內(nèi)部消化實(shí)現(xiàn)避免動(dòng)頭文件。4.2 避免假增量的操作細(xì)節(jié)增量構(gòu)建最大的敵人是clean。make clean會(huì)把out目錄整體清空相當(dāng)于放棄所有緩存。很多解法是能不clean就不clean。但構(gòu)建目錄有時(shí)候會(huì)臟掉Ninja報(bào)錯(cuò)說規(guī)則變了或文件沖突很多人第一反應(yīng)就是clean。我先試一個(gè)溫和方案rm -rf out/soong把Soong的中間狀態(tài)清掉讓構(gòu)建系統(tǒng)重新解析配置多數(shù)依賴規(guī)則損壞的問題都能解決。再不行才考慮rm -rf out。還有一個(gè)細(xì)節(jié)很多人不知道直接執(zhí)行m不帶目標(biāo)名有時(shí)候會(huì)觸發(fā)比預(yù)期更多的構(gòu)建量。原因是構(gòu)建系統(tǒng)會(huì)默認(rèn)編譯當(dāng)前product配置下所有模塊。如果只是想驗(yàn)證某個(gè)模塊用m 模塊名指定目標(biāo)或者更精細(xì)一點(diǎn)進(jìn)到模塊目錄下執(zhí)行m這樣Ninja會(huì)以當(dāng)前目錄作為默認(rèn)目標(biāo)只構(gòu)建相關(guān)模塊。4.3 API變更和文檔生成導(dǎo)致的隱性全量構(gòu)建這可能是最容易被忽略的增量陷阱。AOSP里有一類特殊target比如api-stubs、system-api-stubs、test-api-stubs它們根據(jù)源碼接口自動(dòng)生成API描述文件。每當(dāng)接口變更這些target會(huì)重跑一旦生成的結(jié)果和預(yù)設(shè)的API基線文件不一致構(gòu)建就會(huì)報(bào)錯(cuò)或者聯(lián)動(dòng)重編很多依賴模塊。文檔生成是另一個(gè)隱性全量源。droidcore包含了很多文檔target比如docs-combined-*它們依賴大量模塊的中間產(chǎn)物跑起來極其耗時(shí)。如果構(gòu)建命令里帶了-k或者指定了比較全的target集合很容易把文檔構(gòu)建也捎帶上。我在實(shí)踐中把CI的構(gòu)建命令拆成了兩段日常提交只跑m 模塊只有打Release包時(shí)才跑完整droidcore。這一個(gè)小小的改變讓CI的日常構(gòu)建時(shí)間從45分鐘降到了7分鐘以內(nèi)。5. 分布式構(gòu)建和遠(yuǎn)程緩存的落地路線很多人一聽分布式構(gòu)建就激動(dòng)覺得可以把幾十臺(tái)機(jī)器的CPU擰成一股繩。但AOSP這套構(gòu)建系統(tǒng)對(duì)分布式的支持并不友好盲目折騰大概率是浪費(fèi)時(shí)間。我更建議按遠(yuǎn)程緩存 → 并行調(diào)度 → 真正的分布式執(zhí)行這個(gè)梯度去演進(jìn)。5.1 先上遠(yuǎn)程緩存共享ccache和構(gòu)建產(chǎn)物緩存AOSP構(gòu)建中多個(gè)模塊的編譯產(chǎn)物在規(guī)則不變、輸入不變的前提下是等同的。如果把產(chǎn)物緩存放內(nèi)網(wǎng)共享就相當(dāng)于做了遠(yuǎn)程緩存。這個(gè)方案不需要改構(gòu)建系統(tǒng)實(shí)現(xiàn)成本極低。實(shí)際操作中除了前面提的共享ccache還有一個(gè)更粗粒度的產(chǎn)物緩存思路把整個(gè)out/target/product/device目錄定期同步到內(nèi)網(wǎng)服務(wù)器新機(jī)器或CI節(jié)點(diǎn)首次構(gòu)建時(shí)直接拉取快照跳過全量編譯。這個(gè)方案在分支切換不頻繁的團(tuán)隊(duì)里效果很好我的一個(gè)項(xiàng)目就是用rsync同步產(chǎn)物目錄新同事拉完快照再增量構(gòu)建省掉了第一次全量編譯的40分鐘。5.2 并行調(diào)度把單機(jī)多target拆到多臺(tái)機(jī)器如果多臺(tái)機(jī)器都連著同一個(gè)源碼鏡像和產(chǎn)物共享目錄可以手動(dòng)把構(gòu)建任務(wù)拆開。比如把多臺(tái)機(jī)器的-j參數(shù)降半各自跑不同的模塊集合然后匯總。這個(gè)方案沒有任何構(gòu)建系統(tǒng)層面的支持全靠人肉編排只建議在特定場(chǎng)景用比如需要同時(shí)出多個(gè)product變體每臺(tái)機(jī)器各編一個(gè)最后統(tǒng)一收集。我在實(shí)際中就這么干過一臺(tái)機(jī)器跑user版本另一臺(tái)跑userdebug版本時(shí)間直接減半。但如果你想著手做真正的remote execution也就是把單個(gè)編譯任務(wù)分發(fā)到遠(yuǎn)程執(zhí)行AOSP本身沒有原生的RBE支持需要借助外掛工具鏈復(fù)雜度會(huì)指數(shù)級(jí)上升。5.3 更現(xiàn)實(shí)的方案構(gòu)建集群化和流水線編排對(duì)于中小團(tuán)隊(duì)我并不推薦直接上RBE。我更推薦先把構(gòu)建流程標(biāo)準(zhǔn)化統(tǒng)一構(gòu)建命令、統(tǒng)一環(huán)境鏡像、統(tǒng)一產(chǎn)物輸出位置然后用流水線工具把構(gòu)建任務(wù)編排起來。這樣即便每臺(tái)機(jī)器是單機(jī)構(gòu)建整個(gè)團(tuán)隊(duì)的構(gòu)建吞吐量也能通過并行流水線提上來。比如一個(gè)版本發(fā)布流程包含全量構(gòu)建、單模塊增量構(gòu)建、文檔構(gòu)建、鏡像打包。這四個(gè)任務(wù)互相獨(dú)立完全可以拆成四類流水線任務(wù)分發(fā)到不同節(jié)點(diǎn)。我實(shí)際做下來這套編排比單機(jī)串行節(jié)省了約60%的整體交付時(shí)間而且邊界清晰、出問題好定位。等到團(tuán)隊(duì)規(guī)模大了單機(jī)構(gòu)建時(shí)長真的成了瓶頸再考慮用Bazel遷移加RBE的方案。但這是大工程沒幾個(gè)團(tuán)隊(duì)能承受遷移成本大多數(shù)情況下游刃有余的產(chǎn)物緩存加流水線編排已經(jīng)夠用。6. 構(gòu)建失敗排查的實(shí)戰(zhàn)鏈路從報(bào)錯(cuò)信息到根因定位構(gòu)建優(yōu)化的另一個(gè)側(cè)面是排錯(cuò)效率。構(gòu)建失敗一次少則浪費(fèi)幾分鐘多則卡一下午。我見過太多人對(duì)著終端輸出迷茫或者一遇報(bào)錯(cuò)就clean重來結(jié)果問題依舊。這里分享一套我自己總結(jié)的排查思路專門對(duì)付AOSP這類復(fù)雜構(gòu)建系統(tǒng)。6.1 報(bào)錯(cuò)信息的正確讀取方式AOSP構(gòu)建輸出極其冗長。直接翻終端滾屏是最低效的方式。正確的做法是讓日志落盤再定向檢索。推薦的做法m -j40 21 | tee build.log然后構(gòu)建結(jié)束后用關(guān)鍵詞過濾grep -E error:|FAILED:|ninja: build stopped build.logFAILED:后面的內(nèi)容是定位關(guān)鍵。Ninja會(huì)告訴我們具體哪個(gè)target失敗以及失敗的命令是什么。比這更詳細(xì)的信息在對(duì)應(yīng)模塊的編譯日志里路徑通常在out/soong/.intermediates/下對(duì)應(yīng)模塊的子目錄找到.log后綴文件里面有完整編譯命令和編譯器原話。6.2 編譯錯(cuò)誤、鏈接錯(cuò)誤、資源錯(cuò)誤的分類處理錯(cuò)誤類型不同處理方式天差地別。編譯錯(cuò)誤一般是代碼問題頭文件找不到、語法錯(cuò)誤、依賴缺失。這類問題直接定位到具體文件和行號(hào)修代碼即可。偶爾出現(xiàn)的情況是頭文件被改動(dòng)破壞了引用關(guān)系需要回溯誰動(dòng)了那個(gè)頭文件。鏈接錯(cuò)誤的特征是undefined reference或duplicate symbol。前者通常是缺少依賴庫檢查Android.bp里的shared_libs或static_libs有沒有把需要的庫加進(jìn)去。后者則是兩個(gè)庫導(dǎo)出了同名符號(hào)要么引入命名空間隔離要么在依賴?yán)锾蕹貜?fù)庫。我遇到過最隱蔽的一種不同模塊編譯時(shí)用了不同的宏定義導(dǎo)致同一個(gè)頭文件里符號(hào)在不同編譯單元下簽名不一致鏈接階段才爆炸。資源打包錯(cuò)誤多在AAPT2階段錯(cuò)誤信息會(huì)直接指向資源文件路徑和具體的資源名沖突。常見的坑是新增資源時(shí)命名與其他模塊重疊或者values里的類型定義沖突。AAPT2的緩存偶爾也會(huì)臟掉如果確認(rèn)代碼沒問題清一下out/soong/.intermediates下對(duì)應(yīng)模塊的緩存再重試。6.3 增量構(gòu)建失敗后的安全恢復(fù)姿勢(shì)最忌諱的就是無腦clean。一旦clean之前的構(gòu)建緩存全部作廢下一次構(gòu)建時(shí)間直接回到全量級(jí)別。我的恢復(fù)流程按輕重緩急排列先確認(rèn)是不是偶發(fā)資源競(jìng)爭(zhēng)導(dǎo)致的失敗。檢查上次構(gòu)建是否在內(nèi)存吃緊或磁盤寫滿狀態(tài)下運(yùn)行如果是先清理磁盤釋放空間再重跑一次經(jīng)常就能過。然后試rm -rf out/soong讓構(gòu)建系統(tǒng)重新解析配置。這一步能覆蓋大多數(shù)依賴規(guī)則損壞的場(chǎng)景同時(shí)保留已有編譯產(chǎn)物。再不行定位到失敗模塊單獨(dú)刪除該模塊的中間產(chǎn)物目錄。目錄路徑在out/soong/.intermediates/模塊路徑刪完重跑m 模塊系統(tǒng)會(huì)重建該模塊的過期產(chǎn)物。最后才考慮make clean而且要提前評(píng)估后果。在時(shí)間緊的情況下我會(huì)先把ccache臨時(shí)設(shè)到最大至少讓C/C部分能借緩存回血而不是完全從零開始。6.4 一個(gè)典型的鏈接失敗排查實(shí)例有一次我遇到libart鏈接反復(fù)失敗報(bào)錯(cuò)是undefined reference to art::Thread::Current()。單看這行很多人會(huì)去翻Thread類的定義但我先檢查了Android.bp改動(dòng)記錄發(fā)現(xiàn)同事把libart里的一個(gè)宏定義改名了而依賴libart的另一個(gè)庫還按舊宏名走導(dǎo)致生成的頭文件里Thread::Current()被條件編譯裁掉。整個(gè)排查過程大概20分鐘如果當(dāng)時(shí)直接clean全量編譯至少40分鐘起步還未必能定位根因。這類經(jīng)驗(yàn)告訴我凡是鏈接錯(cuò)誤先查依賴方和被依賴方的宏配置是否對(duì)齊再動(dòng)手重編。7. 構(gòu)建調(diào)優(yōu)方案選型時(shí)我踩過的坑和最終建議這部分算是我個(gè)人經(jīng)驗(yàn)的沉淀。優(yōu)化AOSP構(gòu)建效率的路徑很多但踩過坑以后才知道哪些投入產(chǎn)出比最高哪些是花架子。先說結(jié)論環(huán)境層面NVMe固態(tài)加足夠內(nèi)存是底線ccache必須配增量構(gòu)建的target選擇一定要講規(guī)矩方案層面產(chǎn)物緩存比分布式執(zhí)行性價(jià)比高得多先別碰RBE。我見過最虧的做法是花重金升級(jí)到極高核數(shù)的CPU結(jié)果內(nèi)存和磁盤沒跟上編譯速度不升反降。也見過一遇構(gòu)建失敗就clean把ccache的收益全浪費(fèi)掉的團(tuán)隊(duì)。構(gòu)建調(diào)優(yōu)本質(zhì)上是個(gè)系統(tǒng)性工程每個(gè)環(huán)節(jié)的短板都會(huì)成為瓶頸而補(bǔ)齊短板時(shí)又要注意不引入新的瓶頸。最終我的推薦清單如下磁盤NVMe 1TB以上避免機(jī)械盤和SATA盤內(nèi)存至少64GB128GB更從容內(nèi)存頻率優(yōu)先ccache大小按50G起步多用戶共享增量構(gòu)建明確m 模塊避免無腦全量CI編排日常單模塊增量發(fā)版時(shí)才全量排查流程日志落盤、分級(jí)處理、避免無腦clean產(chǎn)物緩存內(nèi)網(wǎng)共享快照降低新環(huán)境首次構(gòu)建成本這套組合建起來以后我這邊團(tuán)隊(duì)的全量構(gòu)建時(shí)間從40分鐘壓縮到20分鐘左右增量構(gòu)建常規(guī)在3分鐘內(nèi)日常開發(fā)基本不用再盯著進(jìn)度條發(fā)呆。如果需要那份構(gòu)建性能分析報(bào)告和調(diào)優(yōu)參數(shù)對(duì)照表直接內(nèi)網(wǎng)找我拿或者評(píng)論區(qū)留下聯(lián)系方式就行。里面包含了我優(yōu)化過程中的詳細(xì)數(shù)據(jù)和每項(xiàng)調(diào)整的前后對(duì)比對(duì)正在做構(gòu)建效率治理的團(tuán)隊(duì)?wèi)?yīng)該會(huì)很有參考價(jià)值。