Lines Matching refs:Trace

5 当应用在运行时出现明显的延迟或不流畅的情况，会影响用户体验，开发者需要定位、分析、解决应用时延问题。本文先简单介绍应用流畅度评测指标，然后基于Trace数据，介绍时延问题分析思路，并结合案例实践，实…
31 **Trace抓取**
33 抓取Trace前，可以打开ArkUI在hdc的一些debug开关。这样会增加一些详细的trace信息，比如显示具体引起组件标脏的变量、增加布局相关的信息、展示布局过程中所有涉及的组件层级等等。打开的…
37 | param set persist.ace.debug.enabled 1             | 一些调试的Trace开关，包括状态变更更新的Trace  |
38 | param set persist.ace.trace.enabled 1             | ArkUI全局的Trace开关                        |
39 | param set persist.ace.layout.enabled true         | 节点树布局的详细过程的Trace                  |
43 在设备相关debug开关打开后，通过Frame或SmartPerf Host等工具抓取场景Trace，开发者在抓取时，应结合问题现象，使Trace短小而有针对性，以方便后续问题定位。
47 滑动操作占位符完成时延类问题的通用定位思路为先确认时延起止点，然后看起止点时延是否超标准的40ms，没有超过就是达标，超过就需要进一步分析Trace耗时主要发生在什么地方，主要分析网络耗时和帧渲染耗…
56 滑动页面占位符加载完成，是以滑动停止为起始点，在Trace中APP_LIST_FLING泳道可以体现滚动视图的FLING惯性滚动状态的起止，惯性滚动停止则滚动停止，此时开始计算占位符加载时延。
65 3. Trace标记了惯性滚动区间。
87 1. 如果从应用UI上发现有网络加载的动作，则可以在ArkTS CallStack泳道查找是否发送网络请求，关键Trace点createHttp，继续查找请求响应点off(request)，pars…
125 1. 根据起始点确定问题Trace起始点和终止点，如下图加载完成时延总共700ms。
130 2. 根据场景上拉加载更多，数据通过网络请求后刷新，放大Trace找到APP_LIST_FLING尾部，末尾触发request请求数据，即滚动到尾部将要停止时会触发上拉加载，发送请求获取网络接口数据…
135 发送网络数据请求后，会有Response体现在应用中则是解析后刷新数据，LazyForEach绑定的IDataSource会触发刷新监听，通过OnDataReloaded找出刷新数据Trace点，可…
165 1. 分析Trace发现列表每次滚动停止触发上拉加载后，会有一个超长帧。
170 2. 分析Trace中应用主线程泳道超长帧，发现有大量组件创建和布局测算。关键Trace点信息详见“UI绘帧关键Trace点”。
171 - 在应用主线程泳道超长帧前，有关键刷新Trace点：OnDataReloaded（LazyForEach通知控制器数据重新加载）。
186 …predict中大量aboutToBeDeleted发现析构处理，说明GridItem在滑动过程中被释放。从而分析出列表中子组件未做复用影响性能。关键Trace点信息见“UI绘帧关键Trace点”。
210 分析Trace滑动过程中的每一帧，发现在GridItem加载过程中使用了自定义动画，查看JSAnimation动画参数duration为150ms，说明此动画完成时间为150ms，影响图片的加载效果。
221 ## 附录：场景通用Trace流程点说明
223 ### 网络关键Trace点
225 图21 网络关键Trace点
230 |序号|泳道|Trace点|描述|
238 ### UI绘制关键Trace点
240 图22 UI绘制关键Trace点
243 |序号|泳道|Trace点|描述|
251 |序号|泳道|Trace点|描述|