在OpenHarmony中使用Bytrace
一、性能問題分析方式
一般來說,我們發現程序卡頓,排除其他程序問題和硬件問題,那一定是自身程序中某個位置運行時,消耗的時間過長導致,要找到耗時的代碼段,才能有針對性的進行優化,那第一個問題就是如何找到耗時的代碼段。
首先我們能想到,在程序中可能存在問題的地方,加入計算時間差的代碼,然后不斷縮小范圍,找到最終耗時的點
這種方式最終也能解決問題,但是會有一些缺點:
1,對于大型項目來說,要經過大量的【編譯,執行驗證,添加代碼】迭代,消耗大量時間。
2,排查到問題后,需要把測試代碼刪除,下次排查時又要重新添加代碼。
3,通過查看文本log方式分析,不直觀。
下面我們看看如何使用bytrace來分析問題。
二、在OpenHarmony中使用Bytrace
1、在BUILD.gn中添加對bytrace的依賴。
2、添加頭文件
3、添加打點代碼
代碼部分完成了,編譯更新到開發板,然后使用下面命令來抓取log:
參數說明:
- -t 10 : 從運行命令行開始,抓取10秒時間(非必要參數,默認5秒)。
- -b 8192 : 使用8192kb(8M)內存來緩存數據(非必要參數,默認2048kb)。
- graphic : 抓取graphic類型的trace,對應上面代碼中的BYTRACE_TAG_GRAPHIC_AGP。
最后把抓取的結果保存到log.ftrace這個文件中(文件后綴名非限定,txt也行),通過文本編輯器打開查看。
到目前為止,看起來跟加入時間差代碼的方式差不多,還是打點看log,接著往下看。
三、優化打點
把bytrace的打點代碼封裝起來,xtrace.h:
xtrace.cpp:
這樣我們用起來就更方便了:
函數開始,創建XTrace對象時,構造函數調用StartTrace。函數結束或離開作用域,棧中的對象會自動釋放,析構函數調用FinishTrace。
當然這種方式也可以用于時間差打點。
四,可視化看log
https://ui.perfetto.dev
這個網站需要科學方法訪問,首次訪問后有了緩存,后續就可以離線訪問了。
我這邊把網頁保存下來了,在本地開web服務,通過127.0.0.1也可以使用,首先點擊左上角Open trace file打開log.ftrace,右邊會顯示出函數調用的火焰圖,點擊其中一個函數,在下方可以看到準確的執行時間,基本操作:
- 鍵盤w,s:時間軸縮放
- 鍵盤a,d:左右移動
可視化看時間軸就非常直觀了,橫條越長,消耗時間越多。
五、OpenHarmony對bytrace的集成
我們在OpenHarmony使用bytrace,除了以上的便利以外,最重要的是OpenHarmony的代碼中已經大量使用了bytrace,下面是我整理的已經集成bytrace的模塊。
tag | define | description |
ability | BYTRACE_TAG_ABILITY_MANAGER | Ability Manager |
ace | BYTRACE_TAG_ACE | ACE development framework |
app | BYTRACE_TAG_APP | APP Module |
ark | BYTRACE_TAG_ARK | ARK Module |
binder | Binder kernel Info | |
disk | Disk I/O | |
distributeddatamgr | BYTRACE_TAG_DISTRIBUTEDDATA | Distributed Data Manager |
dsoftbus | BYTRACE_TAG_DSOFTBUS | Distributed Softbus |
freq | CPU Frequency | |
graphic | BYTRACE_TAG_GRAPHIC_AGP | Graphic Module |
i2c | I2C Events | |
idle | CPU Idle | |
irq | IRQ Events | |
mdfs | BYTRACE_TAG_MDFS | Mobile Distributed File System |
memory | Memory | |
memreclaim | Kernel Memory Reclaim | |
misc | BYTRACE_TAG_MISC | Misc Module |
mmc | eMMC commands | |
msdp | BYTRACE_TAG_MSDP | Multimodal Sensor Data Platform |
multimodalinput | BYTRACE_TAG_MULTIMODALINPUT | Multimodal Input Module |
notification | BYTRACE_TAG_NOTIFICATION | Notification Module |
ohos | BYTRACE_TAG_OHOS | OpenHarmony |
pagecache | Page cache | |
regulators | Voltage and Current Regulators | |
rpc | BYTRACE_TAG_RPC | RPC and IPC |
sched | CPU Scheduling | |
sensors | BYTRACE_TAG_SENSORS | Sensors Module |
sync | Synchronization | |
window | BYTRACE_TAG_WINDOW_MANAGER | Window Manager |
workq | Kernel Workqueues | |
zaudio | BYTRACE_TAG_ZAUDIO | OpenHarmony Audio Module |
zcamera | BYTRACE_TAG_ZCAMERA | OpenHarmony Camera Module |
zimage | BYTRACE_TAG_ZIMAGE | OpenHarmony Image Module |
zmedia | BYTRACE_TAG_ZMEDIA | OpenHarmony Media Module |
對于以上模塊的性能問題,我們就能直接使用對應tag來抓取。
六、其他
對于一個較大的模塊代碼,我們需要理解他的執行流程,函數調用關系,會比較頭疼,所以我編寫了一個腳本,掃描所有的.cpp文件,在所有函數開頭自動添加XTrace xxx(__func__)。
在可視化界面分析log,可以清晰的看到函數執行的,不同的線程,函數的調用棧,能快速的梳理代碼的執行流程。
第四點中的圖,是我對foundation/ace/ace_engine/frameworks這個目錄下2000個左右cpp文件中的函數全部添加XTrace后,得到的應用啟動流程火焰圖。