UI 卡顿原理：了解卡顿的成因与表现
做移动端开发这么些年，我觉得最让用户抓狂的，就是卡顿。
用户不会关心你用了什么牛逼的架构、多酷的动画库。他们只认一个感受——滑起来是不是「丝般顺滑」。一旦掉帧，信任感立马打折。我以前维护过一个电商项目，双十一首页加载四五个秒杀模块，一个过度绘制排查了一整天……嗯，那次之后我养成了习惯：任何 UI 改动上线前，先过一遍卡顿检查清单。
从硬件到 UI：一条帧的「生死时速」
你想想看，屏幕要连续地、快速地刷出一张张静态图片，我们才能看到流畅的动画。这个速度，就是「帧率」。Android 系统往往以 60fps 或 120fps 作为目标。说白了，每一帧留给你的「生死时间」只有大概 16.6ms（60fps）或 8.3ms（120fps）。
在这一帧还没结束前，你的主线程必须完成：
- 处理用户的输入事件（点击、滑动）
- 运行应用代码（逻辑更新、数据读取）
- 执行 Measure / Layout / Draw 流程
- 将渲染指令交给 GPU
任何一个环节超时，这帧就只能被丢弃。屏幕就会重复显示上一帧的画面。这就是「掉帧」。掉帧多了，用户就感觉「卡」。我个人习惯用一个直观的比喻来理解这件事：
每一帧就像一顿快餐的出餐流程。厨师（CPU）备菜、炒菜，装盘（GPU 合成）。如果备菜时间太长（比如读数据库、解大图），整桌菜就延误了。顾客只能干等着看上一盘的残渣。
卡顿的「三座大山」
卡顿的成因千奇百怪，但说到底，我通常把它们归为三类。这些东西，我在无数个项目里都反复踩过坑。
| 卡顿类型 | 核心原因 | 具体表现 |
|---|---|---|
| 主线程耗时 | 任务太多、太长，占用了 UI 线程 | IO 读写、复杂布局计算、Json 解析、位图解码 |
| 过度绘制 | GPU 反复绘制同一像素区域 | 多层层叠背景、嵌套透明 View、复杂 Shadow |
| 渲染管线性能 | GPU 提交指令过多，合成压力大 | 频繁重绘、无效区域 invalidate、硬件加速瓶颈 |
避坑指南： 我曾经排查过一个「滑着滑着突然卡一下」的问题。全程没找到死循环，也没过度绘制。后来抓 Systrace 发现——那一瞬间后台在触发 Full GC！主线程直接被挂起几十毫秒。所以要记住：不是只有 UI 代码才能引发卡顿。
帧率与掉帧
先别被那些 fancy 的 Profiler 工具吓到。我们先搞清楚两个基础术语：
- 帧率（FPS）：每秒画面刷新的数量。60fps 就是一秒内完成 60 帧的渲染。
- 掉帧（Jank）：某一帧或多帧的渲染时间超过预定间隔，导致视觉上的停滞、跳跃。
为什么说「掉帧」比「帧率低」更伤人？因为人眼对跳跃的敏感度远高于稳定的低帧率。比如视频 30fps 看习惯了也还行，但 60fps 突然变成 20fps，你就会感觉到明显的闪动和不跟手。
卡顿的几大表现形式
- 掉帧（微卡顿）/ 跳帧 —— 滑动列表时字符「飘」一下，或者动画感觉不连贯。
- 滑动粘滞/不跟手 —— 手指滑过去了，画面延迟半拍才动，或者阻力感明显。
- 动画不连贯、缺少过渡 —— 比如 Activity 转场看起来僵硬，没平滑过渡。
- 触控延迟 —— 点击按钮后，视觉反馈出现得比预期晚。这种情况在加解密场景里特别常见，因为解帧过程可能阻塞了主线程。
- APP Not Responding (ANR) —— 最严重的一种：主线程被堵死超过 5 秒，直接闪对话框。加解密文件过大或 io 阻塞是典型元凶之一。
警告： 不要只依赖 FPS 这个指标。FPS 超过 30 并不能说明 UI 流畅。掉帧的均匀性更重要。我建议你在测试时多关注「丢帧数量」和「帧间隔方差」。它们是卡顿的预警信号。
Android 系统卡顿指标
从 Android 7.0 开始，官方引入了「掉帧检测」机制。每个 Choreographer 记录每帧开始时间和结束时间。如果结束 - 开始 > 16ms，就计为一次掉帧。这些数据我们可以通过 `FrameMetrics` API 拿到。
fun detectJanks(activity: Activity) {
activity.window.addOnFrameMetricsAvailableListener(
{ _, frameMetrics, _ ->
val frameDurationNs = frameMetrics.getMetric(FrameMetrics.TOTAL_DURATION)
// 若帧时长超过 16.6ms（约 1.66e7 ns），计为一次卡顿
if (frameDurationNs > 16600000) {
Log.w("FrameMonitor", "检测到掉帧：${frameDurationNs / 1e6f} ms")
}
},
Handler(Looper.getMainLooper())
)
}本质上，我们只用关心一个数字：帧渲染总耗时。超出阈值，就是卡顿。加解密逻辑如果丢在主线程，很容易让这个数字飙升到 100ms 以上。
开发阶段的卡顿监控方案
知道了原理，我们必须有法可依。我个人在开发阶段常用以下几招：
- 开启「Profile GPU Rendering」（开发者选项中的条形图）——几根彩色的竖条，每一条代表一帧。超出绿色基准线（16ms）的就是砸锅的帧。
- 使用 Systrace / Perfetto——最强大的工具，能让你看清每一帧各个阶段的耗时（Input、Animation、Measure/Layout、Draw 等）。我但凡遇到万不得已的地步，一定会掏 Systrace。
- BlockCanary 或 StrictMode —— 帮你抓出主线程上的「敏感」操作，比如 SharedPreference 写操作、File IO、网络请求。
- 手动插桩监控 —— 在关键操作（比如加解密、图片压缩）前后打 Log，算耗时。这个虽然土，但排查定向问题特别有效。
小技巧： 你可以在 Android Studio 的 Profiler 里，勾选「Force GPU rendering」打开硬件加速模拟，这样可以更直观地看到哪一条渲染管线卡住了。
章节核心知识结构图
从这张图上可以清晰地看到：一条帧从「用户操作」出发，经过主线程（M/L/D）、渲染管线、GPU 综合处理，最终到达屏幕。任何一个环节出问题，都会以卡顿的形式表现出来。我们后面要做的事情，就是把那些耗时的加解密操作从主线程那颗「蓝色节点」里摘出去，确保每个环节都在 16ms 以内完成。