## Android界面设计现场里这次问题怎么冒出来

这次碰到的不是教材里的标准题，而是 Compose 列表页 在线上跑着跑着突然失真：有的请求已经发出去，界面却还停在旧状态；有的任务明明结束了，后续回调却把现场再次搅乱。UI 重构最怕一次性推翻重来，这篇按列表页的真实重构顺序拆。真正难的不是知道它会出错，而是第一次看到报警时，工程师很容易把锅甩给网络、机型或者偶发波动。

我更在意的是把排障过程写成团队能复用的操作面：先看哪里、先排什么、什么证据能否定一个假设、什么修改值得进主干。对 Android 工程师来说，能复述推进路径的故障复盘，比泛泛的原理总结更有价值。

## 这类异常通常卡在什么触发条件上

从复现场景看，Compose 列表页 最容易在几个节点失控：页面恢复时旧状态回流、重试链路叠加、异步任务没有和 owner 一起结束、以及机型差异把原本隐蔽的问题放大。这些场景共同点很明显——入口变多以后，任何一个状态没收干净，最终都会表现成“偶发”。

我会把每种现场都对应到一个观测入口：看日志、看 trace、看队列、看数据库或看 UI 状态，这样后面每一步都有抓手。如果这一步没做，定位时通常很快会陷进“感觉像这里有问题”的讨论里。

## 先排掉Compose 列表页里的几类高频误判

这条链路里最常见的两个误区，一个是 状态提升不彻底导致重组频繁，另一个是 预览和真机表现偏差太大。它们共同的问题是：单看某一行日志都合理，拼回完整时序以后才知道哪里已经越界。如果团队直接从结论倒推，往往会在错误模块里消耗很多时间。

剩下最容易漏掉的是 滚动列表里图片加载抖动。这种问题不一定第一时间报错，但会把系统推到一种“还能运行、只是结果不可信”的状态。先把高频误判点排掉，后面每个观测动作的解释力都会更强。

## Compose 列表页的定位路径我一般这样走

### Compose 列表页：先把入口和调用边界卡住

定位时我不会一上来改代码，而是先把现场拆成入口、状态、外部依赖三层，然后确认到底是哪一层先失真。对 Compose 列表页 来说，第一步是画清谁发起、谁等待、谁补偿、谁兜底。只要入口边界没画出来，后面看到的超时、重试和回调顺序都可能只是表象。我会先把复现路径压缩成最短 checklist，再对照页面生命周期、线程切换和任务触发点逐个核对。

如果同一个异常能从冷启动、页面返回、后台恢复三条路径进来，根因通常不是某一行实现写错，而是状态收口本身就不完整。这一步做扎实以后，后面看到的每条日志才有上下文。

@Composable
fun ArticleListScreen(state: ArticleListState, onRefresh: () -> Unit) {
    SwipeRefresh(state = rememberSwipeRefreshState(state.refreshing), onRefresh = onRefresh) {
        LazyColumn {
            items(items = state.items, key = { it.id }) { item ->
                ArticleRow(item = item)
            }
        }
    }
}

### Compose 列表页：把观测点补到能复盘

第二步我会补观测，而不是继续猜。Compose 列表页 最大的问题通常不是没有日志，而是日志、监控和用户反馈互相对不上。所以关键状态、队列长度、重试次数、落库时机和耗时分位值最好在同一条链路里能串起来。

如果项目已经模块化，我会强制把 repository、worker、service、UI 事件放进一条可复盘的 trace；否则每个模块都能自证清白，最后没人知道故障真正在哪里开始。观测点补齐后，很多所谓随机问题都会开始呈现稳定规律。

adb shell am profile start com.example.app /sdcard/compose.trace
adb pull /sdcard/compose.trace ./compose.trace

### Compose 列表页：按状态机做修复和回归

等根因逼近以后，我更倾向先整理 Compose 列表页 的状态迁移，再决定兜底位置，而不是继续往外堆 if else。状态机不清晰时，哪怕这次把问题压下去了，后面也会在重试、补偿、页面恢复或并发触发时重新冒出来。

回归我至少会覆盖正常路径、弱网路径、前后台切换和异常恢复四类 case，因为真正危险的 bug 往往只藏在边界流程里。如果修复同时改动了线程模型、缓存策略或任务触发时机，我会把旧缺陷脚本再完整跑一遍，确认不是把问题从 A 点挪到 B 点。

fun verifyStateTransition(oldState: String, newState: String) {
    check(oldState != newState)
    println("transition=$oldState->$newState")
}

fun rollbackIfNeeded(enabled: Boolean) {
    if (!enabled) return
    println("rollback switch on")
}

## Compose 列表页修复动作我是这样收口的

真正落改动时，我一般不会同时推翻整条链路，而是按“补观测→收状态→调结构”的顺序推进。第一步先做 把 UI state 和 effect 分层，让每次异常都能落到统一证据上。然后再做 为 item key 建稳定主键，把 owner、线程、任务和状态边界重新对齐，先止血，再谈是否值得继续重构。

涉及高并发或大流量时，我会再补 把昂贵计算迁到 remember 或 ViewModel，把最容易失控的那段链路单独看住。这样上线以后即便还有波动，也能快速判断是旧问题残留还是新修改带来的副作用。

## 最后用什么证据确认这次修住了

我不太接受只凭“感觉好了”就收工。验证至少要让 Layout Inspector、Compose Tracing 和 Baseline Profile 三类证据能互相印证：日志指向一致、状态变化符合预期、旧复现脚本不再命中。只有把正常路径、异常路径和回归路径都跑通，结果才算闭环。

只有当错误率回落、关键链路耗时稳定、旧脚本复现不出问题，这次处理才算结束。验证结果最好带指标、命令或现象对照，不然团队后续很难复用。

## 这次Compose 列表页处理最后沉淀了什么

这次处理让我更确定一点：Compose 列表页 的稳定性从来不是单点优化，而是入口治理、状态机、日志和回归一起配合出来的结果。只要把修复动作沉淀成检查项、脚本和验证清单，下次同类故障再来，团队就不会再从头摸黑。