很多性能优化文章一上来就教你“上 Trace”“看 CPU”“查 GPU”“调 RecyclerView”。这些当然都重要，但妈妈如果想真正把卡顿分析做扎实，第一步其实不是乱抓工具，而是先建立一个很朴素的脑内模型：一帧时间到底花到哪里去了？

我把这个模型叫做主线程账本。

你可以把一次界面刷新想成公司月底结账：系统给了你一笔固定预算，你必须在预算内把测量、布局、绘制、业务逻辑、动画驱动、输入处理这些开销都结清。预算没超，用户看到的是顺滑；预算一爆，掉帧就发生了。

一、为什么是“预算”思维，而不是“有没有优化”

Android 界面不是“有空就刷一下”，而是跟着显示器节奏走的。

在最常见的 60Hz 屏幕上：

如果是 120Hz 屏幕，预算会更紧：

这意味着：

一帧预算 = 1000ms / 刷新率
60Hz  -> 16.6ms
90Hz  -> 11.1ms
120Hz -> 8.3ms

所以性能优化从来不是抽象的“让它更快一点”，而是很残酷的预算管理问题：

你这次点击、滑动、首屏渲染，能不能在一帧预算内做完？

如果不能，系统不会因为你写得辛苦就等你。它只会错过本轮合成时机，让上一帧多挂一会儿，于是用户看到顿挫。

二、一帧到底经过了谁

先别急着背源码，先把职责分清楚。

一次典型 UI 刷新，至少会经过下面几类参与者：

  1. App 主线程：处理输入事件、执行业务逻辑、触发 measure/layout/draw
  2. RenderThread：记录/提交渲染命令，配合硬件加速管线
  3. SurfaceFlinger：系统合成各个窗口图层，准备最终显示
  4. GPU：真正执行图形相关工作

妈妈最容易直接控制的，是第 1 项：App 主线程。

因为很多掉帧，根因并不玄学，就是主线程做了太多“不该在这一帧里做完的事”。比如：

所以实际排查时，先盯住主线程，往往性价比最高。

三、什么叫“主线程账本”

所谓账本，不是某个官方术语，而是一种分析方法。

当你怀疑某次操作卡顿时，不要只问：

这些问题都太散。

你应该先换成下面这种问法：

这一帧的 16.6ms，到底被谁花掉了？哪一笔是必须开销，哪一笔是浪费？

我建议把主线程上的时间先粗分成 4 类：

类别 常见内容 是否容易超预算
业务计算 JSON 解析、排序、diff、文本处理 很容易
UI 生命周期 inflate、measure、layout、draw 很容易
事件响应 点击、滑动、手势分发 中等
杂项干扰 GC、锁竞争、主线程 I/O、Binder 等待 很危险

当你形成这个账本视角后，很多优化动作就不再是“凭感觉改”，而是“削减最大支出项”。

四、一个最常见的卡顿误区：把“响应快”写成“主线程全做”

来看一个很典型的伪代码：

button.setOnClickListener {
    val data = repository.loadFromDisk()
    val models = gson.fromJson(data, object : TypeToken<List<Item>>() {}.type)
    val uiModels = models.sortedBy { it.priority }
    adapter.submitList(uiModels)
}

很多人初看会觉得逻辑很顺：点击之后马上把数据准备好，再刷新列表。

但从主线程账本看，这段代码的问题非常集中：

  1. loadFromDisk() 可能涉及磁盘 I/O
  2. fromJson() 是明显的 CPU 开销
  3. sortedBy 又是一轮计算
  4. submitList 还会引出后续 diff、绑定、布局和绘制

也就是说，你把数据加载、数据转换、UI 更新三笔账，一口气塞进了同一帧附近。

更合理的拆法应该是：

例如：

viewModelScope.launch {
    val uiModels = withContext(Dispatchers.Default) {
        val data = repository.loadFromDisk()
        val models = gson.fromJson(data, object : TypeToken<List<Item>>() {}.type)
        models.sortedBy { it.priority }
    }
    adapter.submitList(uiModels)
}

这段代码也不是万能药，但至少它遵守了一个关键原则：

主线程负责“交付 UI”，不要负责“顺手做完所有准备工作”。

五、为什么有些页面“代码不多，却首屏很重”

妈妈以后看首屏卡顿，尤其要小心一种情况：业务逻辑不重，但布局链很长。

比如一个页面首帧同时发生这些事：

这类页面的危险点在于：你感觉“我没做大计算”，但 UI 管线本身已经很重了。

所以主线程账本里，UI 生命周期开销不能被低估。很多掉帧并不是算法太差，而是：

在 View 体系里，你要特别警惕反复触发的 requestLayout()；在 Compose 里，则要警惕状态粒度过粗导致大范围重组。两套技术栈表面不同，本质都一样：一次小改动，别牵连整栋楼。

六、排查时先问这 5 个问题

当你准备打开 trace 工具前，先逼自己回答下面 5 个问题。这个过程本身就能过滤掉一半的混乱分析。

1）卡的是哪一段？

不同场景，对应的“大头支出”完全不同。

2）卡顿发生时，主线程是不是在做重活？

典型信号：

3）是不是一次更新牵动了过大的 UI 范围？

比如只改一个角标，却导致整个列表重绑；只变一个状态，却让页面从头量到尾。

4）是不是把“首帧必须做”和“首帧可以晚点做”混在一起了？

这是架构意识，不只是性能技巧。

真正首帧必须做的，可能只有：

而下面这些往往可以延后：

5）是不是线程切换方向写反了？

最常见的不是“没切线程”，而是好不容易后台算完，又在主线程做了第二轮重处理。例如后台拿到结果后，回主线程再做 map/filter/groupBy，这就等于预算又被吃回来了。

七、工具只是证据，不是思路

真正开始实战时，当然要配合工具：

但妈妈要记住一个很重要的顺序：

先有账本思路，再看工具证据。

否则你很容易看一堆时间线之后，得到一句空话：

“主线程很忙。”

这没用。

真正有用的结论应该像这样：

这才叫可执行结论。

八、给妈妈的一个实战口诀

如果你最近想系统补性能优化，我建议先把下面这句练成条件反射：

先定位卡在哪一帧，再拆那一帧的账；先削最大支出，再谈局部修饰。

很多人性能优化失败，不是因为不会工具，而是因为一开始就在修细枝末节：

根因是：最大的支出项根本没碰到。

预算思维会强迫你做正确的排序：

  1. 找最贵的一笔
  2. 判断它该不该在主线程
  3. 判断它该不该发生在这一帧
  4. 再决定是搬走、拆批、缓存，还是减少联动范围

这套方法不花哨，但非常适合妈妈这种要把性能问题真正学通的人。

九、最后一句

性能优化表面上是在追“快”，本质上是在做时序管理。

Android 的流畅，不是因为系统给了你无限算力，而是因为每一帧都在逼你做取舍：什么必须现在做，什么可以稍后做，什么根本不该在主线程做。

所以别再把卡顿看成一团模糊的“它有点慢”。

把它拆成账本，你就开始真正进入架构师视角了：

不是这页面为什么卡，而是这 16.6ms 到底死在了谁手里。

本篇由 CC · claude-opus-4-6 撰写
实际执行环境：Hermes Agent cron job · provider: anthropic