原創(chuàng)內(nèi)容彤委,轉(zhuǎn)載請注明出處驹暑,多謝配合。
最近做了dex2oat相關(guān)優(yōu)化矛市,那么簡單總結(jié)下一些相關(guān)流程與知識點芙沥。
這里虛擬機相關(guān)基礎(chǔ)知識這里不贅述了,不清楚的可以移步之前的文章:
熱修復(fù)&插件化(二)-虛擬機
啟動耗時分析(三)-ART編譯分析
我們都知道浊吏,ART虛擬機引入了AOT預(yù)編譯而昨,最終編譯任務(wù)是交由dex2oat來處理的。dex2oat是一個Android系統(tǒng)的二進制可執(zhí)行文件找田,保存在system/bin目錄下歌憨。
相比傳統(tǒng)的JIT編譯來說克胳,dex2oat編譯的二進制文件是持久化的案铺,當前編譯耗費時間更長、存儲空間占用也更大钥星,但是換來的是下次直接執(zhí)行持久化的機器碼漆改,大幅度提升運行效率心铃。
另外,需要注意的是:dex2oat執(zhí)行編譯操作的時候挫剑,會起j參數(shù)后面跟的線程數(shù)去執(zhí)行(常見的-j6)去扣,在大量執(zhí)行dex2oat操作的場景下,CPU占用率會非常高樊破,很大概率會占用大核和超大核影響到用戶前臺操作愉棱,甚至出現(xiàn)卡頓和黑屏。這里優(yōu)化策略我肯定不會寫出來的哲戚,哈哈羽氮,但是呢可以把一些相關(guān)的流程與知識點總結(jié)下。
top -t -m 10
PID TID PR CPU% S VSS RSS PCY UID Thread Proc
23836 23840 4 11% R 1297936K 59156K bg u0_a14 Compiler driver /system/bin/dex2oat
23836 23841 7 11% R 1297936K 59156K bg u0_a14 Compiler driver /system/bin/dex2oat
23836 23843 5 11% R 1297936K 59156K bg u0_a14 Compiler driver /system/bin/dex2oat
23836 23844 6 11% R 1297936K 59156K bg u0_a14 Compiler driver /system/bin/dex2oat
23836 23836 3 11% R 1297936K 59156K bg u0_a14 main /system/bin/dex2oat
23836 23845 7 11% R 1297940K 59156K bg u0_a14 Compiler driver /system/bin/dex2oat
23836 23842 3 11% R 1297936K 59156K bg u0_a14 Compiler driver /system/bin/dex2oat
23836 23839 7 11% R 1297936K 59156K bg u0_a14 Compiler driver /system/bin/dex2oat
本篇文章先對目前觸發(fā)dex2oat操作的通路進行簡單梳理:
一惫恼、觸發(fā)路徑
這里是原生的方式:
路徑 | 描述 | 編譯方式 | 編譯內(nèi)容 |
---|---|---|---|
Install | 應(yīng)用安裝通過installd觸發(fā)的編譯 | speed-profile | 主apk |
OTA升級 | 系統(tǒng)升級通過installd觸發(fā)的編譯 | verify | 主apk |
load dexFile | 動態(tài)加載插件直接通過虛擬機觸發(fā)的編譯 | quicken | 插件 |
postboot | 開機1分鐘后,針對全部安裝的7天內(nèi)未使用且過期的應(yīng)用通過installd觸發(fā)的編譯 | verify | 主apk |
idle | 同時滿足充電澳盐、idle狀態(tài)且24小時內(nèi)只觸發(fā)一次祈纯,主apk通過installd觸發(fā)編譯,插件通過虛擬機觸發(fā)編譯 | speed-profile | 主apk 和 插件 |
二令宿、觸發(fā)條件
dex2oat觸發(fā)之前會先做條件判斷,來決定是否需要做:
- dex文件完全沒有編譯過腕窥。
- 已經(jīng)生成了odex粒没,但是后續(xù)執(zhí)行了更高優(yōu)先級的compile filter,因此需要重新編譯覆蓋簇爆。
- OTA系統(tǒng)升級癞松,boot image發(fā)生了變化。
所謂的過期就是針對后兩點而言的入蛆。
從編譯通路我們可以看到响蓉,觸發(fā)dex2oat編譯的方式主要有兩類:
- 經(jīng)過PMS由installd觸發(fā)。
- 動態(tài)加載插件是直接由虛擬機觸發(fā)哨毁。
這兩類路徑分別由后面篇文章來分析:
Android 9.0 ART編譯分析(二)-Installd觸發(fā)dex2oat編譯流程
Android 9.0 ART編譯分析(三)-虛擬機觸發(fā)dex2oat編譯流程