做 Android 稳定性测试时，I/O 阻塞是很容易被低估的一类问题。它不像 Java Crash 那样有清晰堆栈，也不像重启那样有明显边界。很多时候，测试同学看到的是“系统变慢”“相机打不开”“桌面无响应”“设置页卡住”“日志停止刷新”，而设备内部真正发生的是写盘队列堆积、文件系统等待、数据库事务卡住、日志服务反压、system_server 里的关键线程被同步 I/O 拖住。 I/O 问题麻烦的地方在...
top、cpuinfo、线程栈和 Perfetto 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 CPU 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、哪些结论不能轻易下，以及怎样把一次偶现问...
资源耗尽型稳定性问题 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 FD/Thread/Binder 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、哪些结论不能轻易下，以及怎样把一次偶现问题整...
PSS、RSS、USS、Java Heap 和 Native Heap 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 内存 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、哪些结论不能轻易下，以...
从现象到根因和复盘 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 完整案例 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、哪些结论不能轻易下，以及怎样把一次偶现问题整理成开发可以继续分析的报告...
reboot reason、pstore、Watchdog 和 Kernel Panic 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 随机重启 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、...
Window、Display、Power 与 SurfaceFlinger 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 黑屏 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、哪些结论不能轻易下...
卡顿、黑屏和系统阻塞时间线 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 Perfetto 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、哪些结论不能轻易下，以及怎样把一次偶现问题整理成开发可...
重启和内核异常 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 pstore 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、哪些结论不能轻易下，以及怎样把一次偶现问题整理成开发可以继续分析的报告...
窗口、进程、内存、电量和服务状态 是 Android 稳定性测试里非常容易被写成一句话的问题，但真正能推动开发定位的材料，必须包含现象、时间、系统状态、关键日志、复现路径和排除项。本文围绕 dumpsys 建立一条可执行的排查链路：先判断问题类型，再采集正确证据，然后把证据按时间线组织成结论。 这篇不是命令清单，而是面向测试开发的定位方法。你应该能在读完后知道工具在哪里、每个输出看什么、哪些结论不能轻易下，以及怎样把一次偶现问题整理成开...