一般來說，我們發現程序卡頓，排除其他程序問題和硬件問題，那一定是自身程序中某個位置運行時，消耗的時間過長導致。

性能問題分析方式

要找到耗時的代碼段，才能有針對性的進行優化，那第一個問題就是如何找到耗時的代碼段。

首先我們能想到，在程序中可能存在問題的地方，加入計算時間差的代碼，然后不斷縮小范圍，找到最終耗時的點。

#include
uint64_tGetTimeStampUS()
{
structtimevaltv;
gettimeofday(&tv,NULL);
returntv.tv_sec*1000000+tv.tv_usec;
}
.....
voidFuncA()
{
uint64_tt1=GetTimeStampUS();
FuncB();
uint64_tt2=GetTimeStampUS();
FuncC();
uint64_tt3=GetTimeStampUS();
printf("FuncBcost:%llu,FuncCcost:%llu
",t2-t1,t3-t2);
}

這種方式最終也能解決問題，但是會有一些缺點：

①對于大型項目來說，要經過大量的【編譯，執行驗證，添加代碼】迭代，消耗大量時間。

②排查到問題后，需要把測試代碼刪除，下次排查時又要重新添加代碼。

③通過查看文本 log 方式分析，不直觀。 下面我們看看如何使用 bytrace 來分析問題。

在OpenHarmony中使用 Bytrace

①在 BUILD.gn 中添加對 bytrace 的依賴：

external_deps=[
"bytrace_standard:bytrace_core",
]

②添加頭文件：

#include

③添加打點代碼：

voidFuncA(){
StartTrace(BYTRACE_TAG_GRAPHIC_AGP,"funcB");
funcB();
FinishTrace(BYTRACE_TAG_GRAPHIC_AGP);
}

代碼部分完成了，編譯更新到開發板，然后使用下面命令來抓取 log：

hdcshellbytrace-t10-b8192graphic>~/logs/log.ftrace

參數說明： -t 10：從運行命令行開始，抓取 10 秒時間（非必要參數，默認 5 秒） -b 8192：使用 8192kb(8M) 內存來緩存數據（非必要參數，默認 2048kb） graphic：抓取 graphic 類型的 trace，對應上面代碼中的 BYTRACE_TAG_GRAPHIC_AGP 最后把抓取的結果保存到 log.ftrace 這個文件中（文件后綴名非限定，txt 也行），通過文本編輯器打開查看。 到目前為止，看起來跟加入時間差代碼的方式差不多，還是打點看 log，接著往下看。

優化打點

把 bytrace 的打點代碼封裝起來，xtrace.h：

#include
#include"bytrace.h"

classXTrace
{
public:
XTrace(std::stringfname);
~XTrace();
};

xtrace.cpp：

XTrace::XTrace(std::stringfname)
{
StartTrace(BYTRACE_TAG_ZCAMERA,fname);
}

XTrace::~XTrace()
{
FinishTrace(BYTRACE_TAG_ZCAMERA);
}

這樣我們用起來就更方便了：

voidFuncB(){
XTracetrace1(__func__);
}

voidFuncA(){
{
XTracetrace1(__func__);
FuncB();
{
XTracetrace2(__func__);
FuncC();
}
}

函數開始，創建 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 來抓取。

其他

對于一個較大的模塊代碼，我們需要理解他的執行流程，函數調用關系，會比較頭疼。

所以我編寫了一個腳本，掃描所有的 .cpp 文件，在所有函數開頭自動添加：

XTracexxx(__func__);

在可視化界面分析 log，可以清晰的看到函數執行的，不同的線程，函數的調用棧，能快速的梳理代碼的執行流程。 第四點中的圖，是我對 foundation/ace/ace_engine/frameworks 這個目錄下 2000 個左右 cpp 文件中的函數全部添加 XTrace 后，得到的應用啟動流程火焰圖。

審核編輯：湯梓紅