我注意到一个现象，很多团队收到用户反馈说 App 卡顿，第一反应是去翻代码，但缺少一个关键环节——先量化卡顿的程度，再定位具体原因。做 iOS流畅度优化之前，先搞清楚卡顿是 FPS 掉帧、主线程阻塞还是内存压力导致的，优化才能对症下药。
第一步：量化卡顿
用户说的「卡」太主观，同一个页面有人觉得卡有人觉得还行。先把它变成数据：用 Instruments 的 Time Profiler 跑一遍，能看到主线程每帧的耗时，超过 16.67ms 就会掉帧。如果连续几帧超过这个值，用户就能感知到卡顿了。Instruments 定位非常准确，但每次跑都要连 Mac 配模板，整个流程比较长，不适合日常频繁反复使用。
日常开发中可以用 KeyMob 实时看 FPS 曲线——USB 连上 iPhone，打开性能面板，操作目标页面时曲线会实时反映帧率波动。看到波形在哪段操作出现下跌，就说明那段代码有问题。对 iOS流畅度优化来说，先拿到客观数据比凭感觉猜问题重要得多。而且 KeyMob 不需要重新编译，随时插上就能看。
第二步：定位根因
FPS 掉帧的原因不外乎几类：一是主线程做了耗时操作，比如图片解码、JSON 解析、复杂的 Auto Layout 计算；二是内存持续上涨触发系统回收，表现为操作一段时间后突然卡一下；三是 GPU 负载过高，视图层级过深或离屏渲染太多。
排查时需要把 CPU、内存、GPU 三个维度结合起来看。Instruments 的 Time Profiler 能给出精确的堆栈信息，但每次配置耗时不少。KeyMob 可以分担快速排查那部分——用内存面板观察退出页面后曲线是否回落，能快速判断是否存在内存泄漏。CPU 和 GPU 占用在同一界面里切着看，不用在多个工具之间切换。
第三步：针对性优化
主线程解码放到后台线程，用 SDWebImage 或 Kingfisher 的异步解码配置。内存缓存加上限，避免页面堆积不释放。复杂的列表 Cell 用预计算高度代替 Auto Layout。视图层级过深就扁平化，减少不必要的容器嵌套。离屏渲染做圆角用 layer.mask 替代或提前切好图。图片缓存策略加个合理上限，避免列表滑动时频繁加载释放。每次改动聚焦一个变量，改完马上验证效果。多线程和内存回收这类问题改完不一定会立即见效，需要多跑几轮确认稳定。
第四步：验证优化效果
改完后重新跑一遍同样的操作，对比优化前后的 FPS 曲线。之前掉帧到十几帧的地方现在稳定在 55-60 fps 就算达标。Instruments 可以做最终确认，但日常改完代码用 KeyMob 实时扫一眼就能知道效果，不用反复挂 Instruments。流畅度优化不是一次性的事，每次都把优化前后的数据记录下来，慢慢积累能形成一套属于自己项目的性能基线。