## 先把AOSP 问题定位异常表象摆出来

这次碰到的不是教材里的标准题，而是 AOSP 问题定位 在线上跑着跑着突然失真：有的请求已经发出去，界面却还停在旧状态；有的任务明明结束了，后续回调却把现场再次搅乱。看源码最怕陷入目录海，真正高效的方式是先用日志把模块边界卡住，再按调用栈回到源码。真正难的不是知道它会出错，而是第一次看到报警时，工程师很容易把锅甩给网络、机型或者偶发波动。

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

## AOSP 问题定位一般会在哪些场景失控

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

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

## 这条链路最容易踩的坑先列出来

这条链路里最常见的两个误区，一个是 一上来全局搜索导致失焦，另一个是 分支版本与真机 build 不一致。它们共同的问题是：单看某一行日志都合理，拼回完整时序以后才知道哪里已经越界。如果团队直接从结论倒推，往往会在错误模块里消耗很多时间。

剩下最容易漏掉的是 补丁验证只看编译通过。这种问题不一定第一时间报错，但会把系统推到一种“还能运行、只是结果不可信”的状态。先把高频误判点排掉，后面每个观测动作的解释力都会更强。

## 先按这几步把AOSP 问题定位根因逼出来

### AOSP 问题定位：先把入口和调用边界卡住

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

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

repo forall framework* -c "git rev-parse --short HEAD"
repo grep -n "Timeout waiting for service" frameworks base services

### AOSP 问题定位：把观测点补到能复盘

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

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

adb logcat -v threadtime ActivityManager:* SystemServer:* *:S
m services/tests/servicestests

### AOSP 问题定位：按状态机做修复和回归

等根因逼近以后，我更倾向先整理 AOSP 问题定位 的状态迁移，再决定兜底位置，而不是继续往外堆 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")
}

## 真正动手改时我会先落这几步

真正落改动时，我一般不会同时推翻整条链路，而是按“补观测→收状态→调结构”的顺序推进。第一步先做 建立 log tag 到源码目录的索引，让每次异常都能落到统一证据上。然后再做 保留常用 repo branch 和 tag 速查表，把 owner、线程、任务和状态边界重新对齐，先止血，再谈是否值得继续重构。

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

## 改完AOSP 问题定位以后我怎么确认没再炸

我不太接受只凭“感觉好了”就收工。验证至少要让 cs.android.com、repo grep 和 m / mm 增量编译 三类证据能互相印证：日志指向一致、状态变化符合预期、旧复现脚本不再命中。只有把正常路径、异常路径和回归路径都跑通，结果才算闭环。

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

## 留给团队的AOSP 问题定位复盘结论

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