Lines Matching refs:Trace

7 本文主要是以Trace数据为切入点进行分析，相应的工具可以使用SmartPerf Host或DevEco Studio内置的Frame等。若开发者需要补充SmartPerf Host工具和Trace…
12 开发者可以通过HiTrace命令工具抓取应用刷新时的Trace信息，并通过SmartPerf Host集成性能工具分析。例如，抓取某应用发生丢帧处的Trace信息如图1，则平均帧率计算过程如下：
14 **图1 应用丢帧处的Trace数据**
18 | 计算帧率时，可参考的Trace标签	| 含义| 	帧数| 	平均帧率 |
43 这里以点击应用tab，做页面跳转的场景为例，通过Trace分析其完成时延。  
44 …Trace分析应用的完成时延之前，开发者需要简单了解OpenHarmony中图形渲染的流程。在整个渲染流程中，首先由App侧响应用户的屏幕输入事件，由App侧处理完成后再提交给RS侧，由RS侧协调…
51 **图4 system侧Trace**
61 **图5 app侧Trace**
70 **图6 RS侧Trace**
77 App侧序列化与RS侧反序列化的Trace示例标签中都有 [7291，51]，分别是线程号与帧编号标识。可以看到被处理的帧信息，是按编号在App侧与RS侧一一对应的。  
103 导致应用丢帧的原因非常多，可能是应用本身原因，可能是系统原因，也有可能是硬件层原因。不同卡顿原因在Trace中有不同表现，识别需要大量经验积累。
105 分析过程，主要是结合App主进程和RenderService渲染进程Trace数据，先排查系统、硬件是否异常，再分析应用本身原因。
125 2.	找到 Trace中每一帧耗时的部分，大致定位是App侧问题还是RS侧问题，并结合Trace标签，初步定位原因。  
143 最终，根据卡顿原因，结合业务场景和API找出适合解决方案，并用Trace等数据验证优化结果。
174 这五个阶段，对应Trace中的标签信息如下：
189 之后，开发者可以结合应用启动各阶段Trace信息，对比应用前一个版本或竞品表现，找出差异点，大致分析是哪阶段时间增加了。
216 最终，根据延迟原因，结合业务场景和API，找出适合解决方案，并用Trace等数据验证优化结果。
220 文章首先介绍了通过分析Trace的方式，检测应用问题所对应的基础性能指标：  
221 针对丢帧问题，展示了如何结合Render Service进程下相关线程的Trace标签，估算用户真实感知到的平均帧率。  
222 针对响应速度问题，展示了如何结合OpenHarmony图形渲染流程相关Trace标签，估算用户真实感知到的点击完成时延。