作者：陈迅
一，性能问题分析方式
一般来说，我们发现程序卡顿，排除其他程序问题和硬件问题，那一定是自身程序中某个位置运行时，消耗的时间过长导致，要找到耗时的代码段，才能有针对性的进行优化，那第一个问题就是如何找到耗时的代码段。
首先我们能想到，在程序中可能存在问题的地方，加入计算时间差的代码，然后不断缩小范围，找到最终耗时的点
#include <sys/time.h>
uint64_t GetTimeStampUS()
{
struct timeval tv;
gettimeofday(&tv, NULL);
return tv.tv_sec * 1000000 + tv.tv_usec;
}
.....
void FuncA()
{
uint64_t t1 = GetTimeStampUS();
FuncB();
uint64_t t2 = GetTimeStampUS();
FuncC();
uint64_t t3 = GetTimeStampUS();
printf("FuncB cost : %llu,FuncC cost : %llu\n",t2-t1,t3-t2);
}
这种方式最终也能解决问题，但是会有一些缺点：
1，对于大型项目来说，要经过大量的【编译，执行验证，添加代码】迭代，消耗大量时间
2，排查到问题后，需要把测试代码删除，下次排查时又要重新添加代码
3，通过查看文本log方式分析，不直观
下面我们看看如何使用bytrace来分析问题
二，在OpenHarmony中使用Bytrace
1，在BUILD.gn中添加对bytrace的依赖
external_deps = [
"bytrace_standard:bytrace_core",
]
2，添加头文件
#include <bytrace.h>
3，添加打点代码
void FuncA() {
StartTrace(BYTRACE_TAG_GRAPHIC_AGP, "funcB");
funcB();
FinishTrace(BYTRACE_TAG_GRAPHIC_AGP);
}
代码部分完成了，编译更新到开发板，然后使用下面命令来抓取log：
hdc shell bytrace -t 10 -b 8192 graphic > ~/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 <string>
#include "bytrace.h"
class XTrace
{
public:
XTrace(std::string fname);
~XTrace();
};
xtrace.cpp：
XTrace::XTrace(std::string fname)
{
StartTrace(BYTRACE_TAG_ZCAMERA, fname);
}
XTrace::~XTrace()
{
FinishTrace(BYTRACE_TAG_ZCAMERA);
}
这样我们用起来就更方便了：
void FuncB(){
XTrace trace1(__func__);
}
void FuncA(){
{
XTrace trace1(__func__);
FuncB();
{
XTrace trace2(__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 | 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后，得到的应用启动流程火焰图。
更多原创内容请关注：深开鸿技术团队
入门到精通、技巧到案例，系统化分享OpenHarmony开发技术，欢迎投稿和订阅，让我们一起携手前行共建生态。