SELinux avc日志中帧率抖动根因教程 - 第1节 SELinux avc日志中帧率抖动根因教程 - 第1节

📚 课程目录第1章帧率抖动现象识别

## 第1章帧率抖动现象识别帧率抖动（Frame Rate Jitter）是用户能直接感知的卡顿形态，表现为画面频繁出现短暂停滞、滑动不跟手或动画断裂。本章聚焦**现象识别**这一环节，建立从用户主观反馈到系统客观日志的映射关系，并判断是否可能与 SELinux AVC（Access Vector Cache）日志有关联。

目标：能够根据应用层卡顿特征、系统日志关键字和量化指标，快速判定是否存在帧率抖动问题，并决定是否需要进一步查看 SELinux AVC 日志。

### 现象识别流程总览下面的 SVG 流程图概括了帧率抖动现象识别的完整路径，包含三个核心输入源和合并判断逻辑。 ### 1.1 应用层卡顿特征应用层的卡顿可通过以下症状直接观察或通过工具采集：

掉帧（Dropped Frames）：动画每秒钟跳过若干帧，典型表现为画面“一顿一顿”。
滑动不跟手：手指在列表中滑动时，UI响应滞后超过 100ms，或出现跳跃感。
动画断裂：过渡动画中途停止或反向，常见于 ViewPager、RecyclerView 切换。
Choreographer 帧跳过日志：logcat 中出现 Choreographer: Skipped 47 frames!。

应用层卡顿特征往往是最容易捕获的第一信号，运维人员应训练肉眼识别以上症状，并在初步确认后立即采集现场日志。

### 1.2 系统日志关联性系统日志提供了关键上下文。以下表格列出与帧率抖动最相关的日志类型、典型关键字和关联说明。

日志类别	典型字段/关键字	与帧率抖动的关联
logcat (主线程)	`Choreographer: Skipped XX frames!`	直接反映丢帧数，数值越大卡顿越明显。
logcat (RenderThread)	`drawFrame timed out`	渲染线程超时导致帧无法按时提交。
kernel log (dmesg)	`sched: RT throttling activated`	内核调度器限流可能影响渲染线程优先级。
avc log (audit.log)	`avc: denied { search } for pid=...`	SELinux 拒绝文件访问或进程操作，可能阻塞关键路径。
SurfaceFlinger trace	`Missing frame for id=...`	系统合成器缺少帧，可能导致显示停顿。

### 1.3 用户反馈与客观指标对齐用户反馈往往是主观的“卡”、“不流畅”，将其量化为客观指标有助于统一判断标准。 | 主观反馈 | 客观指标阈值（典型） | 说明 | |----------|----------------------|------| | 轻微卡顿 | FPS > 30 且 < 55，或 frame time > 16.7ms | 用户可感知但不严重，偶发掉帧 | | 明显卡顿 | FPS < 30 持续 2 秒以上，或 jank count > 2 帧/秒 | 严重抖动，需要立即采集现场 | | 严重卡顿 | FPS < 15 或连续丢帧 > 10 帧 | 几乎无法操作，必须介入排查 |

判断规则：当同时满足以下任意 2 项时，应进入后续章节的详细 AVC 日志排查流程：

① 应用层卡顿特征明显且反复出现；

② 系统日志中包含 avc: denied 条目且与进程 PID 匹配；

③ 客观指标 FPS 低于 30 持续超过 3 秒。

### 1.4 故障树简述为了结构化排查，可将现象识别过程建模为如下分支判断：

根节点：是否存在帧率抖动？
分支1：无抖动 → 结束排查；
分支2：有抖动 → 检查应用层日志 → 若出现 Choreographer 丢帧 → 进入性能分析；
分支3：有抖动 → 检查 avc 日志 → 若出现大量 denied → 标记为 SELinux 相关；
分支4：合并采集用户反馈 → 对照指标表确定严重等级。

通过故障树结构，可以快速将现象分类，避免在初始阶段盲目深入。

常见误区：不要仅凭“帧率低”就认定是 SELinux 问题。很多帧率抖动由应用逻辑（如主线程耗时计算、布局复杂）或渲染管线（如过度绘制）引起。本章的指标对齐步骤就是用来过滤掉非系统层原因，否则后续排查会走错方向。

以上就是第1章的全部内容。现象识别是整个排查链条的起点，为后续数据采集和根因定位打下基础。当完成本章识别后，如果锁定为“疑似 SELinux AVC 相关”，请继续进入第2章“AVC 日志采集与解析”。