无代码变更突发异常的排查步骤 #

你提到没改代码就出问题，这种情况大多是环境变化、测试数据触发了隐藏bug，或是依赖/缓存的隐性变化，给你一套通用排查思路：

1. 精准定位卡顿的代码位置

• 用CPU Profiler抓快照：打开Android Studio的Profiler，连接模拟器进程，启动CPU录制后点击异常按钮，直到卡顿/ANR出现再停止。查看主线程的调用栈，无限循环会显示同一个方法反复执行，耗时任务会看到某个方法占了90%以上的CPU时间。
• 拉取ANR traces文件：ANR发生后，系统会在/data/anr/traces.txt生成线程栈信息，用Device File Explorer把它拉到本地，找到主线程（main线程）的调用栈，就能看到它卡在了哪个方法里。

2. 聚焦Jetpack Navigation相关逻辑

因为问题出在跳转Fragment时，重点查：

• 异常按钮对应的目标Fragment的生命周期方法：比如onCreateView/onViewCreated里有没有处理数据的逻辑？比如遍历集合时，是不是因为测试数据新增了特殊元素（比如循环引用的对象、异常数值）导致无限循环？
• 导航参数传递：有没有传了null或超出预期的参数？比如某个参数是负数，导致后续计算逻辑出错？
• 全局导航监听：如果用了OnDestinationChangedListener，有没有在里面加了耗时的同步操作？

3. 排查环境与数据因素

• 模拟器/真机验证：换个不同版本的模拟器，或者直接用真机测试，看是不是新版本模拟器的兼容性问题。
• 测试数据排查：有没有修改过本地数据库、SharedPreferences里的测试数据？比如之前是有序列表，现在变成了无序且包含重复元素，导致排序/遍历逻辑卡壳？
• 依赖版本检查：有没有用implementation 'xxx:xxx:+这种动态版本的依赖？依赖库可能悄悄更新引入了bug，把版本号固定下来试试。

4. 死锁排查（概率较低，但可验证）

你的日志里CPU是满负载，死锁的概率很低（死锁时CPU使用率通常不高），但如果还是怀疑：

• 用Profiler的Threads面板看线程状态，有没有线程处于BLOCKED状态。
• 查看traces.txt，找有没有线程在等待某个锁，而持有锁的线程又在等待其他资源。

5. 缓存与版本回归

• 清理Android Studio缓存：File -> Invalidate Caches... -> Invalidate and Restart，有时候缓存损坏会导致诡异问题。
• 回滚到历史正常版本：用本地历史记录checkout之前确认没问题的代码，看问题是否消失，排除本地环境的隐性变更。

内容的提问来源于stack exchange，提问作者VanessaF