一、卡顿现象的本质与分类
做移动端性能优化这么多年，我见过太多团队一上来就扎进代码里找问题。结果呢？折腾半天连卡顿的根因都没摸清楚。说白了，你得先理解卡顿到底是什么，才能对症下药。
1.1 什么是UI卡顿
UI卡顿，就是用户操作界面时，画面没有及时响应。你滑动列表，它卡一下才动；你点了个按钮，过一会儿才有反馈。这种感觉，就像你在跟一个反应慢半拍的人对话——很别扭。
我记得有一次，产品经理拿着手机来找我，说某个页面"有点卡"。我一看，确实，滑动商品列表时明显掉帧。但奇怪的是，同样的代码在另一台手机上却很流畅。嗯，这里要注意——卡顿不是绝对的，它跟设备性能、当前负载都有关系。
卡顿的本质：帧率低于人眼可接受的阈值，导致视觉上的不连续感。
1.2 帧率与刷新率的关系
先搞清楚两个概念：帧率（FPS）和刷新率（Hz）。
帧率是GPU每秒能渲染多少帧画面。刷新率是屏幕每秒能刷新多少次。你想想看，如果帧率跟不上刷新率，屏幕就只能重复显示上一帧——卡顿就来了。
| 概念 | 定义 | 常见值 | 谁负责 |
|---|---|---|---|
| 帧率 (FPS) | GPU每秒渲染的帧数 | 30、60、120 | 应用层 |
| 刷新率 (Hz) | 屏幕每秒刷新的次数 | 60、90、120、144 | 硬件层 |
理想情况下，帧率应该等于刷新率。比如60Hz的屏幕，你最好稳定输出60FPS。一旦掉到30FPS，人眼就能明显感知到卡顿。
我的经验：我个人习惯把60FPS作为基准线。低于这个值，就该警觉了。如果掉到30FPS以下，那基本就是灾难——用户会毫不犹豫地关掉你的App。
1.3 卡顿的三种类型
在实际项目中，我把卡顿分成三类。每一类的排查思路都不一样。
1. 加载卡顿
页面首次打开时，图片一张张蹦出来，或者白屏时间过长。这通常是资源加载策略出了问题。
- 表现：页面空白、图片渐进式显示、列表项突然撑开
- 根因：图片体积过大、网络请求阻塞、解码耗时过长
- 我踩过的坑：曾经有个项目，首页首屏加载了12张高清大图，每张2MB以上。结果在3G网络下，白屏时间超过8秒。后来改成渐进式加载+缩略图预览，体验才勉强能看。
2. 滑动卡顿
这是最常见的卡顿类型。用户上下滑动列表时，画面一顿一顿的，像在放幻灯片。
- 表现：滑动时画面跳跃、列表项加载延迟、滚动条不跟手
- 根因：主线程被阻塞、图片解码占用CPU、内存频繁GC
- 避坑指南：我曾经在优化一个电商App时发现，滑动卡顿的元凶竟然是列表项的圆角裁剪。每个item都用了clip-path，GPU直接罢工。换成预裁剪图片后，帧率从25FPS飙到55FPS。
3. 动画卡顿
转场动画、加载动画、交互动画出现掉帧。这类卡顿最容易被用户注意到，因为动画本身就是视觉焦点。
- 表现：动画不流畅、出现撕裂感、动画结束时抖动
- 根因：动画帧率不匹配、GPU过度绘制、动画与主线程任务冲突
- 我的教训：有次做一个图片放大动画，我直接在JS里用setInterval控制帧率。结果在低端机上，动画卡得不成样子。后来改用requestAnimationFrame + GPU加速，问题才解决。
注意：这三种卡顿经常同时出现。比如加载卡顿会引发滑动卡顿，滑动卡顿又会加剧动画卡顿。排查时一定要先定位主要矛盾，别被表象迷惑。
1.4 卡顿排查的核心逻辑
说了这么多，我们来画个图，把整个知识体系串起来。
这张图把卡顿排查的核心逻辑串起来了。从UI卡顿出发，先判断属于哪一类，再定位根因，最后选择对应的优化方案。我个人习惯在项目初期就建立这样的排查框架，能省下不少时间。
一个小技巧：遇到卡顿问题，先别急着看代码。打开性能工具（比如Xcode的Instruments或Android的Profiler），看看帧率曲线。曲线上的"坑"会告诉你问题出在哪一帧。
好了，这一章我们先把卡顿的本质和分类理清楚。后面几章，我会带你逐个击破每种卡顿的排查方法。记住，搞清楚问题是什么，比急着解决问题更重要。