一图查››
一、APP问题
-
普通耗时问题
-
主线程阶段耗时
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| input | 主线程 | input事件处理流程时间较长 | |
| deliverInputEvent | 主线程 | deliverInputEvent事件处理流程过长 | |
| animation | 主线程 | 动画流程时间过长，需要关注动画相关callback中的具体逻辑 | |
| AssetManager::OpenXmlAsset | 主线程 | ||
| relayoutWindow | 主线程 | 该流程触发了relayoutWindow。有可能是由于界面发现变化导致。需要关注实际触发relayoutWindow的原因。 | |
| measure | 主线程 | ||
| layout | 主线程 | 存在较长的layout流程，需要关注界面变化 | |
| inflate | 主线程 | ||
| draw | 主线程 | draw 流程较长 | |
| syncAndDrawFrame | 主线程 | 较长的 Draw 流程是由于上一帧渲染线程存在耗时导致，因此触发 postAndWait 状态，需要对上一帧渲染线程进行重点分析 | |
| postAndWait | 主线程 | 本帧/上一帧的渲染线程中XXX过长，是导致主线程postAndWait流程过长的原因，请业务侧进一步分析确认说明：postAndWait的深度分析策略 | |
| Record View#draw() | 主线程 | draw方法中的Record View#draw()耗时过长，需要业务先行排查 | |
| ViewTree#OnPreDraw | 主线程 | 识别到ViewTree#OnPreDraw耗时，该耗时和当前页面视图关系较大，业务侧可以先检查当前绘制流程是否正常 | |
| dispatchOnGlobalLayout | 主线程 | dispatchOnGlobalLayout耗时主要由于布局变化频繁或视图层级过多。可以减少不必要的布局更新，尽量降低视图层次复杂度，注意有无addOnLayoutChangeListener等监听导致干扰 |
-
渲染线程耗时长
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| prepareTree | 渲染线程 | ||
| renderFrame | 渲染线程 | renderFrame 耗时过长 | |
| drawLayer | 渲染线程 | 存在Layer更新。需要关注页面中界面更新操作 | |
| flush layers | 渲染线程 | ||
| flush commands | 渲染线程 | flush commands耗时过长，主要目的是将收集的绘制命令转化为GPU可以执行的形式。 | |
| Texture upload | 渲染线程渲染线程/FlushCommandsTactic策略 | 发现Texture upload，图片资源相关操作导致耗时 | |
| FillRectOp | 渲染线程 | FillRectOp耗时主要源于过度绘制和视图层级复杂度。可以尝试简化视图层次结构，减少不必要的透明度和重叠区域的绘制。 |
-
GL线程耗时长
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| onDrawFrame | GL线程 | onDrawFrame方法耗时，需要业务先进行检查 | |
| eglSwapBuffers | GL线程 | eglSwapBuffers方法耗时，业务先进行检查 | |
| applyGrallocMetadataLocked | GL线程 | applyGrallocMetadataLocked持锁耗时，业务先进行检查持锁情况，也可能和当前机器性能有关系 |
-
特殊耗时问题
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| 前置阶段存在阻塞情况 | 主线程/前置流程耗时识别 | 主线程前置阶段阻塞耗时，需要关注 doFrame 开始前的流程 | |
| 距离上一帧的间隔过长 | 主线程/前置流程耗时识别 | 发现距离上一帧的间隔过长 | |
| 上一帧未发现渲染线程，隔帧绘制 | 主线程/前置流程耗时识别 | 上一帧未发现渲染线程，可能导致本帧绘制间隔过长 | |
| 上一帧主线程耗时过长 | 主线程/前置流程耗时识别 | 上一帧主线程耗时过长，影响到当前帧 | |
| MSG_WINDOW_FOCUS_CHANGED识别 | / | 主线程/前置流程耗时识别 | 发现MSG_WINDOW_FOCUS_CHANGED，代表正在进行窗口切换 |
| 软同步信号可能不规律 | 主线程/前置流程耗时识别 | 软同步信号可能不规律，导致 Vsync-app 信号同步间隔异常 | |
| 前置流程存在方法阻塞 | 主线程/前置流程耗时识别 | 前置方法存在阻塞，需要app检查耗时原因 | |
| activityPaused识别 | / | 主线程/前置流程耗时识别 | 处在页面切换期间，发现activityPaused |
| copyImageInto方法耗时识别 | 主线程/PostAndWaitDepthTatic | ||
| 其他中间耗时流程识别 | / | 主线程/PostAndWaitDepthTatic | 流程过长，可能是导致主线程postAndWait流程过长的原因，请业务侧进一步分析确认 |
| 上一帧渲染线程耗时 | 主线程/PostAndWaitDepthTatic | 主线程postAndWait流程过长,请业务侧进一步分析确认上一帧的渲染线程 |
二、surfaceflinger问题
-
普通耗时问题
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| dequeueBuffer | / | 渲染线程、GL线程 | |
| queueBuffer | 渲染线程、GL线程 | 存在较长的queueBuffer流程。这部分可以联系surfaceflinger模块进一步分析处理 | |
| waitOnFences | 渲染线程 | waitOnFences耗时，正在等待OpenGL渲染的绘制栏栅fence解放，该问题可以先寻求渲染模块进行协助排查 | |
| latchBuffers | SF线程 | ||
| chooseCompositionStrategy | SF线程 | chooseCompositionStrategy导致composite阶段耗时过长，需要SF团队协助 | |
| postComposition | SF线程 | ||
| postFramebuffer | SF线程 | postFramebuffer耗时源于帧缓存传输延迟和资源竞争，需要SF同学协助排查 | |
| finishFrame | SF线程 | finishFrame耗时主要由于等待GPU完成渲染和资源同步，需要SF同学协助排查 | |
| getDataspace | SF线程 | getDataspace是获取缓冲区中数据的色彩空间（Dataspace）的重要操作，这部分需要SF同学协助看一下 |
-
特殊耗时问题
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| AtlasTextOp | 渲染线程/FlushCommandsTactic策略 | AtlasTextOp耗时主要是对字体的一些渲染操作，需要SF模块辅助确认能否优化 | |
| 送显间隔过长，检查是否存在阻塞 | 送显阶段/送显间隔问题 | 需要检查本帧和上一帧的SF阶段是否存在阻塞送显的情况 | |
| SF未正确latch Buffer | 送显阶段/送显间隔问题 | 送显开始阶段距离上次送显间隔过长，可能存在SF周期出现异常或者插入绘制别的进程的frame，未正确latch BufferTX | |
| 上帧渲染线程没有正常合成buffer | 送显阶段/送显间隔问题、上一帧流程检查策略 | 上帧渲染线程没有正常合成产生bufferTX，导致掉帧 | |
| SF绘制间隔异常 | 送显间隔问题 | SF开始阶段距离上次SF间隔过长，需要检查本帧和上一帧的SF阶段是否存在阻塞的情况 |
三、Display 送显问题
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| 送显流程耗时 | 送显阶段 | 送显阶段耗时过长，需要Display协助分析 | |
| 送显完成时间不规律 | 送显阶段/送显间隔问题 | 发现上一帧的送显部分完成过快，导致本次送显正常完成情况下，依然产生掉帧 | |
| 上帧缺少送显阶段 | 送显阶段/送显间隔问题、上一帧流程检查策略 | 前置帧缺少送显阶段，导致发生掉帧 |
四、性能问题
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| CPU D状态异常 | CPU策略 | 流程下存在D状态的情况，且时间占比较高。需要系统侧帮忙分析确认。 | |
| CPU 较多的CPU Runnable情况 | CPU策略 | 流程下存在较多的 CPU Runnable 情况，需要确认是由于整体CPU繁忙还是CPU频率较低导致。 | |
| CPU CPU频率过低 | CPU策略 | 可以根据实际情况考虑提频处理 | |
| Cache miss | 渲染线程/FlushCommandsTactic策略 | 建议联系对应项目的性能组 | |
| Cache hit | 渲染线程/FlushCommandsTactic策略 | 建议联系对应项目的性能组 | |
| eglSwapBuffersWithDamageKHR | 渲染线程 | 该流程是一个数据交换相关的操作，该流程较慢一般并非由于上层导致。可能与当时的内存情况有关。 | |
| monitor contention with owner | / | 任意阶段 | |
| GC性能问题 | 任意阶段 | 内存开销过大导致GC线程持续运行，容易引发主线程和renderThread线程D状态。一般这种情况需要结合当前整机内存情况综合分析 | |
| 主线称阶段GC | 主线程 |
五、其他问题
| 案例 | Trace图示 | 发生阶段/所属策略 | 原因说明/执行建议 |
|---|---|---|---|
| iq报点异常导致滑动频率异常，隔帧绘制 | 主线程/前置流程耗时识别 | ||
| Trace尾部切割异常 | 无阶段归属 | 在自动化脚本执行过长时，Trace文件超过一定大小会自动进行分割分割的文件可能在尾部的信息发生丢失，此时perfetto解析异常，Atrace也容易误判此处发生严重掉帧针对该情况，目前只有复测，或者看atrace工具是否可以优化该场景，不进行掉帧判定 | |
| 送显脚本识别错误异常 | 送显阶段 | 此处送显间隔过长是发生掉帧的直接原因，但需要去检查是否是掉帧脚本判定有误，掉帧脚本可能对本帧送显阶段的识别存在异常 |
