Chapter 150: Mobile System Debugging Surface
移动系统调试面的核心问题是：一个 App 可见现象出现后，工程师应从哪些层观察系统状态，并用哪些证据判断问题属于 App、Framework、系统服务、内核、驱动或硬件边界。调试面（Debugging Surface）指系统向开发者、测试人员、平台工程师或设备支持人员开放的观察入口，包括断点、日志、trace、metrics、crash report、bug report、sysdiagnose、服务 dump、内核事件和设备诊断包。
本章使用一个贯穿现象：视频通话 App 从后台回到前台后，用户看到相机预览黑屏约 2 秒，随后画面恢复；App 没有崩溃，权限指示器正常亮起，问题只在部分量产设备上出现。这个现象牵涉 App 生命周期、相机 API 状态、系统服务资源所有权、调度延迟、驱动启动、隐私策略和设备日志。读完本章后，读者应能把这种现象拆成可观察对象，按层级定位责任边界，并决定下一步需要日志、trace、metrics、crash report 还是设备级诊断包。
移动 OS 的调试面天然分层。App 能直接看到自己的状态、线程、回调、错误码和业务日志；Framework 能暴露 API 调用结果、权限状态和回调序列；系统服务掌握资源队列、设备所有权和跨进程请求；内核记录调度、内存、IPC、文件、网络和设备事件；驱动与硬件层处理寄存器、DMA、firmware、传感器、ISP、modem、display pipeline 等低层细节。一次现象能被哪一层解释，取决于证据能到达哪一层。
调试面的价值在于建立可复用的排查顺序。先把用户现象转成时间线，再确定进程、线程、服务和硬件资源边界，接着选择最小可用证据。日志适合回答“发生了什么事件”，trace 适合回答“时间耗在哪里”，metrics 适合回答“趋势是否稳定”，crash report 适合回答“异常终止现场是什么”，bug report 或 sysdiagnose 适合回答“当时设备全局状态如何”。
150.1 Debugging Surface 与系统可观测性边界
调试面是系统允许外部观察内部状态的接口集合。它解决的问题是把一个模糊现象转换成可验证的状态、时间、责任主体和资源边界，修复动作要建立在这个转换结果之上。对贯穿现象而言，“相机预览黑屏 2 秒”本身只是用户感知；调试面需要回答预览 Surface 是否已经创建、相机 session 是否启动、帧回调是否到达、系统服务是否持有 camera device、驱动是否完成 stream on、调度是否被后台恢复路径阻塞。
移动系统的可观测性边界由权限、构建类型、平台开放程度和隐私策略共同决定。普通 App 能记录自己的生命周期回调、权限结果、API 返回值、线程状态和业务事件；它通常无法直接读取其他进程的私有状态，也无法稳定访问驱动内部队列。平台工具可以扩展观察范围，例如 Android 的 logcat command-line tool 面向系统消息和 App 日志，Android bug report 面向设备级快照，Apple 的 crash reports and diagnostic logs 面向崩溃与诊断日志，Apple Instruments 面向性能分析。工具越靠近系统层，越依赖设备权限、系统版本和平台政策。
同一个现象在不同观察层会呈现不同形态。App 层看到的是 onResume 后第一帧没有到达；Framework 层看到的是 camera session configure、start repeating 或 output callback 的顺序；系统服务层看到的是相机设备所有权、并发访问、权限状态和请求队列；内核层看到的是线程调度、Binder 或 Mach/XPC 相关等待、I/O 中断和设备驱动事件；设备诊断包看到的是一段时间内的日志、服务状态、进程列表、电源、温度、内存和硬件错误信号。
| 观察层 | 能回答的问题 | 典型证据 | 边界 |
|---|---|---|---|
| App | App 是否发起请求、回调是否到达、UI 是否消费结果 | 业务日志、断点、线程栈、API 错误码、埋点 | 覆盖自身进程和公开 API 可见状态 |
| Framework | API 状态机是否按预期推进 | 回调顺序、权限结果、session 状态、异常对象 | 依赖公开 API 和 SDK 暴露信息 |
| System Service | 资源所有权、队列、策略检查和跨进程请求是否正常 | 服务 dump、系统日志、bug report、平台 trace | Android 较开放，Apple 多通过诊断包和公开工具间接观察 |
| Kernel | 调度、内存、IPC、I/O 和驱动事件是否形成瓶颈 | 内核日志、调度 trace、线程状态、设备错误 | 量产设备权限通常受限 |
| Device Diagnostics | 故障发生时全局状态是否支持某个判断 | bug report、sysdiagnose、crash logs、metrics | 数据量大，需回到具体时间线筛选 |
这张表给出本章的第一条判断规则：先根据问题要回答的层级选择调试面，再用证据收缩范围。黑屏 2 秒如果只有 App 日志，最多能证明 App 在某个时间点发起了请求；如果同时有 trace 和系统服务状态，才可能判断延迟是否来自系统服务排队、驱动启动或渲染线程被阻塞。
150.2 App-Level Debugging、Framework-Level Debugging、System-Level Debugging
App-Level Debugging 观察的是当前应用进程内部。它的输入是开发者可控制的代码、线程、状态变量、生命周期回调、API 调用和业务日志；输出是“App 是否按预期发起请求和处理返回”。对黑屏现象，App 层应先记录进入前台、创建预览视图、请求相机、收到 session 回调、收到第一帧、把帧提交给 UI 的时间点。这个层级可以定位 App 状态机遗漏、主线程阻塞、Surface 生命周期错配和错误码处理缺失。
Framework-Level Debugging 观察的是公开 API 和平台框架暴露的状态。它回答的问题是“App 调用平台能力后，Framework 是否给出了可解释的结果”。在 Android 相机路径里，公开 API 回调、权限结果、session configure 结果和 camera availability callback 都属于这一层可见材料；在 Apple 平台里，AVFoundation 等公开框架的授权状态、session 状态、runtime error callback 和中断通知承担类似作用。Framework 层的证据可以把 App 代码问题和平台能力状态分开。
System-Level Debugging 观察的是跨进程服务、系统策略和设备状态。它回答的问题是“系统是否接受请求、资源是否可用、策略是否放行、服务是否排队或阻塞”。Android 上，dumpsys、bug report、Perfetto trace 和系统日志可以提供较多系统层材料；Apple 平台上，Console、Instruments、MetricKit、crash logs、diagnostic logs 和 sysdiagnose 构成公开可用的主要入口。Apple 私有 daemon 与内部服务实现通常不作为可直接验证的事实写入结论，正文只使用公开工具能观察到的行为和诊断材料。
断点、日志、API 状态、系统 dump、trace 和内核事件应按问题类型选择。断点适合观察 App 变量和调用栈；日志适合建立事件顺序；API 状态适合确认权限、配置和错误返回；系统 dump 适合查看服务当前状态；trace 适合还原跨线程和跨进程时间线；内核事件适合解释调度、I/O、内存和驱动层延迟。把这些材料混用时，需要先固定同一个时间基准，例如用户点击回到前台的时间、App 记录 resume_start 的时间、第一帧上屏的时间。
| 层级 | 首要问题 | 对黑屏现象的可观察点 | 常见误判来源 |
|---|---|---|---|
| App | 请求是否正确发起 | 生命周期、Surface 创建、API 调用、首帧回调 | 只看到业务日志，直接归因到系统 |
| Framework | 公开 API 是否返回明确状态 | 权限、session、availability、runtime error | 忽略 API 回调中的中断或重配信号 |
| System Service | 资源是否被系统接受并调度 | camera service、window、power、activity 状态 | 只看单个服务状态，忽略生命周期和电源策略 |
| Kernel / Driver | 低层资源是否形成延迟 | 调度、内存、设备启动、驱动错误 | 把低层日志当成唯一原因，缺少上层时间线 |
调试层级之间是递进关系。App 层先确认请求存在，Framework 层确认平台 API 状态，System 层确认资源所有权和策略，Kernel / Driver 层确认低层执行。每一层都要回答一个更具体的问题，最终把“黑屏”这种感知问题转成“首帧延迟发生在请求发起前、API 状态转换中、系统服务排队中，还是设备启动中”。
150.3 Logs、Traces、Metrics、Crash Reports、Bug Reports 的职责划分
Logs 记录离散事件。它们擅长回答“某个时间点谁说了什么”，例如 App 记录 camera_open_requested、Framework 回调 session_configured、系统日志出现 camera service 状态变化。Android 官方文档把 logcat 描述为输出系统消息和 App 日志的命令行工具，并说明 Android 日志系统包含由系统维护的结构化环形缓冲区，例如 main、system、crash 等缓冲区。日志的优势是进入门槛低、和代码路径贴近；限制是它们只能表达被记录的事件，无法自动还原未记录的等待时间和跨线程依赖。
Traces 记录时间线。它们擅长回答“时间耗在哪里”，例如主线程是否在等待锁，渲染线程是否错过帧截止时间，Binder 调用是否排队，CPU 频率是否降低，camera service 是否在某段时间内阻塞。Android 的 Perfetto tracing documentation 面向系统级 trace；Apple 的 Instruments tutorials 面向性能分析和时间线观察。对黑屏现象，trace 比单条日志更适合证明 2 秒延迟发生在 UI 渲染、跨进程调用、服务队列还是设备启动阶段。
Metrics 量化趋势。它们擅长回答“这个问题是否稳定、是否集中在某类设备、系统版本或温度状态”。单个用户报告只能说明一次发生；metrics 可以把首帧时间、会话重建时间、失败率、设备型号、系统版本、前后台切换状态、低电量模式、温度状态等字段聚合起来。Apple 的 MetricKit 属于公开的性能与诊断指标入口；Android 侧也可以通过应用自有埋点、Play Console 质量数据和平台性能工具观察趋势。Metrics 提供趋势判断，现场时间线提供单次因果，两者合并后才能决定排查优先级。
Crash Reports 保存异常终止现场。它们回答“进程为何终止，终止时哪个线程处于什么调用栈”。Crash report 包含异常类型、signal、fault address、线程调用栈、二进制镜像和设备状态等材料。黑屏 2 秒并且 App 继续运行时，crash report 通常位于辅助位置；如果黑屏后伴随进程终止、native abort、watchdog 或内存压力终止，crash report 才成为第一入口。这里的判断顺序是先看现象是否包含异常终止，再决定是否把 crash report 放在前面。
Bug Reports 和 sysdiagnose 保存设备级现场。Android 的 Capture and read bug reports 文档把 bug report 作为帮助诊断和调试问题的设备报告入口；Apple 的 sysdiagnose 和 diagnostic logs 在公开支持与开发流程中承担类似“全局诊断包”的角色。设备级诊断包适合回答“故障窗口内系统整体状态是什么”，例如进程列表、服务 dump、系统日志、电源状态、温度、内存、网络和硬件错误。它们的数据量大，阅读时必须以现象时间线为索引。
下面的分工可以作为材料选择顺序：先用日志建立事件序列，再用 trace 定位时间开销，接着用 metrics 判断影响范围；出现异常终止时读取 crash report；需要全局设备状态时收集 bug report 或 sysdiagnose。对黑屏 2 秒，这个顺序会先要求 App 日志记录 resume_start → request_camera → session_configured → first_frame，再用 trace 或系统诊断确认两段时间之间的等待来自哪一层。
150.4 User-Space、Kernel-Space、Driver、System Service 的问题定位边界
User-Space 问题发生在应用进程、Framework 进程或系统服务进程内部。典型证据是异常、线程阻塞、主线程堆栈、IPC 等待、服务锁等待和 API 错误返回。黑屏现象如果表现为 App 主线程在前台恢复后长时间执行同步初始化，且第一帧回调已经到达，那么问题边界偏向 App 进程和 UI 渲染路径；如果 App 已经发起请求但 session 回调延迟，边界会移动到 Framework 与系统服务之间。
System Service 问题发生在能力代理层。移动 OS 通常由系统服务持有硬件资源状态，并执行权限、并发、生命周期、电源和隐私策略。相机、定位、音频、通知、窗口、电源、输入等能力都通过服务协调。黑屏 2 秒如果伴随 camera service 排队、设备被其他客户端占用、前台状态尚未完成切换或隐私策略重新授权，证据应来自服务状态、系统日志和跨进程 trace。这个层级的责任判断要同时看 App 请求、服务队列、资源所有权和策略结果。
Kernel-Space 问题发生在内核调度、内存、IPC、I/O、电源和驱动接口附近。典型证据是线程长时间不可运行、CPU 频率受限、内存回收压力、Binder 或 Mach message 等跨进程通信等待、设备中断异常和 kernel log。黑屏 2 秒如果集中在设备温度高、后台恢复时 CPU 频率低、系统负载高或内存回收强的场景，内核层证据能解释“服务已经发出请求但执行推进慢”的部分。
Driver 与硬件问题发生在设备控制和数据流启动阶段。相机预览依赖 sensor、ISP、buffer queue、display pipeline 和电源状态。驱动或 firmware 层的异常可能表现为 stream on 延迟、buffer 没有及时返回、设备初始化超时或硬件错误信号。量产设备上，普通应用通常只能通过公开 API 错误、系统诊断包、设备厂商日志和可复现条件间接判断这一层。结论应写成“证据支持问题靠近驱动启动边界”，而非写成无法公开验证的内部实现细节。
| 现象类型 | 优先观察层 | 关键证据 | 可下结论的范围 |
|---|---|---|---|
| App 崩溃 | User-Space | crash report、线程栈、异常类型 | 哪个进程、哪个线程、哪个调用点终止 |
| UI 卡顿 | User-Space + Kernel | 主线程栈、渲染 trace、调度状态 | 时间是否消耗在 App、渲染、调度或系统调用 |
| 权限失败 | Framework + System Service | 权限状态、API 错误、服务策略 | 授权、运行时检查或用户撤销路径 |
| 硬件无响应 | System Service + Driver | 服务状态、设备错误、诊断包 | 资源所有权、设备启动或驱动边界 |
| 仅部分设备出现 | Metrics + Device Diagnostics | 型号、系统版本、OEM 策略、温度、电源 | 是否和设备族、版本或厂商策略相关 |
责任边界的稳定写法是“证据位于哪一层，结论就停在哪一层”。App 日志能证明 App 行为，Framework 回调能证明公开 API 状态，系统 dump 能证明服务层状态，trace 能证明时间线，驱动日志或厂商诊断才能支撑驱动层结论。这样写结论可以减少跨层跳跃。
150.5 Debug Build、Release Build、Production Device 的可观测性差异
Debug Build 的可观测性最高。开发者可以打开详细日志、使用断点、查看变量、保留符号、降低优化等级、开启诊断开关，并在本地复现中收集更细粒度的材料。它适合确认 App 状态机、线程、对象生命周期和 API 调用顺序。Debug Build 的限制是运行条件和真实用户环境存在差异：断点会改变时间线，详细日志会增加 I/O 和同步开销，调试器会影响线程调度，调试包的权限和配置也可能不同于正式发布包。
Release Build 的调试目标是用低开销材料保留关键事实。发布包通常保留必要埋点、错误码、性能指标、崩溃上报、少量结构化日志和符号化所需映射文件。它适合判断问题是否在真实用户环境中发生，以及发生时的设备、系统版本、前后台状态、电源状态、网络状态和资源使用。对黑屏 2 秒，Release Build 至少应记录恢复前台时间、相机请求时间、session 成功时间、首帧时间、错误回调、设备型号和系统版本。
Production Device 的可观测性受平台权限和隐私策略限制。用户设备上的日志可能被裁剪，系统服务状态可能需要开发者选项或平台权限，驱动日志可能只存在于厂商诊断通道，Apple 平台的内部服务细节通常通过公开诊断、Instruments、MetricKit、crash logs 和 sysdiagnose 间接观察。Android 量产设备也会受到 user build、SELinux、OEM 策略和调试权限限制。生产环境结论应重视数据脱敏、最小采集和用户授权。
符号、日志级别、权限、采样开销和隐私脱敏会改变诊断深度。符号决定调用栈能否还原到函数名和源码位置；日志级别决定事件是否被记录；权限决定是否能访问系统服务和内核材料；采样开销决定 trace 和 profiling 能持续多长时间；隐私脱敏决定日志中用户数据、路径、联系人、位置、媒体内容和设备标识如何被处理。调试方案应把这些条件写清楚，否则同一现象在实验室和用户设备上会得到不同证据。
| 维度 | Debug Build | Release Build | Production Device |
|---|---|---|---|
| 符号 | 通常完整 | 需要保留映射和 dSYM | 依赖后端符号化流程 |
| 日志 | 可详细记录 | 保留结构化关键事件 | 受日志级别、系统政策和脱敏限制 |
| 权限 | 可使用调试工具 | 主要依赖公开 API 与上报 | 系统层材料受设备和平台约束 |
| 开销 | 可接受较高开销 | 控制常态开销 | 采样和触发式收集更合适 |
| 隐私 | 测试数据可控 | 需要默认脱敏 | 需要最小化采集和用户授权 |
贯穿现象在三种环境中的排查策略也不同。Debug Build 先用断点和详细日志确认 App 路径；Release Build 用埋点确认首帧延迟分布；Production Device 用诊断包和聚合指标判断是否集中在特定设备、系统版本、温度、电源状态或后台恢复路径。三种材料合在一起，才能把单次复现和真实影响范围连接起来。
150.6 Android 与 Apple 调试面的开放程度差异
Android 和 Apple 面对的是同一个系统问题：App 可见现象需要被还原成跨层路径。差异在于开放程度、工具入口、系统服务可见性、公开源码范围和诊断包内容。比较这两个平台时，应使用同一组维度：入口 API、系统服务状态、trace 能力、崩溃材料、设备级诊断包、源码或公开实现、隐私与权限边界。
Android 的调试面更强调命令行和系统状态导出。开发者常用 adb、logcat、dumpsys、bugreport、tombstone、ANR trace、Perfetto / systrace 和 Android Studio profiling 工具。AOSP 公开材料也让许多 Framework、system_server、HAL 接口和系统服务概念可以被追踪。这个开放性有明显版本和设备边界：不同 API level、OEM 定制、user / userdebug build、SELinux 策略和厂商服务会改变可见材料。
Apple 的调试面更强调 Xcode、Instruments、Console、MetricKit、Crash Logs、diagnostic logs 和 sysdiagnose。公开框架文档能解释 API 行为、授权状态、错误回调和性能工具入口；Darwin / XNU 的公开材料能支持内核层的通用理解；许多系统 daemon、entitlement 细节和驱动实现属于私有实现边界。工程判断应写成“公开工具观察到某种行为，结合公开平台模型推断问题靠近某个边界”，并标注无法公开验证的部分。
| 维度 | Android | Apple |
|---|---|---|
| App 入口 | Android Studio Debugger、Logcat、Profilers、公开 SDK 回调 | Xcode Debugger、Console、Instruments、公开 Framework 回调 |
| 系统状态 | dumpsys、bugreport、系统日志、部分服务状态 | sysdiagnose、diagnostic logs、Console、公开工具摘要 |
| 时间线 | Perfetto、systrace、FrameTimeline、sched、Binder 等 track | Instruments 的 Time Profiler、System Trace、Points of Interest 等模板 |
| 崩溃材料 | tombstone、Java/Kotlin crash、ANR trace、Play Console 数据 | crash logs、Jetsam/termination 相关诊断、MetricKit payload |
| 公开实现 | AOSP 覆盖大量 Framework 和系统组件概念 | Darwin / XNU 有公开部分，平台服务和框架内部多为私有实现 |
| 设备差异 | OEM 服务、电源策略、HAL、内核和 firmware 差异显著 | Apple 控制硬件和系统组合，私有实现可见性较低 |
对黑屏现象，Android 上可以从 App 日志进入 logcat，再看 camera、activity、window、power 等服务状态，必要时使用 Perfetto 追踪 Binder、调度和帧时间线。Apple 上可以从 App 日志、AVFoundation 回调、Instruments 时间线、MetricKit 指标、crash logs 或 sysdiagnose 进入，结论应更多依赖公开 API 回调、系统诊断材料和时间线观察。两者的共同点是都需要从用户现象回到 App 请求和系统资源边界；差异是 Android 往往能看到更多服务级文本状态，Apple 往往需要用公开工具和诊断包收束结论。
150.7 从现象到系统路径的定位流程
从现象到系统路径的第一步是把用户描述改写成可观察事件。黑屏 2 秒可以改写为：t0 用户从后台返回前台，t1 App 收到前台恢复信号，t2 App 请求相机或重建 session，t3 Framework 返回 session 可用，t4 第一帧到达，t5 第一帧提交到屏幕。这个改写把主观体验转成事件边界，后续每份日志、trace、metrics 或诊断包都要围绕这些时间点对齐。
第二步是建立复现矩阵。矩阵至少包含设备型号、系统版本、App 版本、前后台停留时间、电量模式、温度状态、网络状态、是否正在通话或录屏、是否存在其他相机客户端、是否刚完成权限授权或撤销。矩阵的作用是把“部分设备出现”拆成可比较条件。若问题只在某个 OEM 系统、某个 iOS 大版本、某个低电量状态或某个后台时长后出现，定位会从单纯 App 代码移动到系统策略或设备边界。
第三步是选择调试面并收集最小证据。App 层至少记录生命周期、API 调用、回调和首帧时间；Framework 层关注权限、session、availability、runtime error 和中断通知；系统层关注资源所有权、服务队列、电源状态、窗口状态和跨进程等待；内核或驱动层只在已有证据显示时间消耗靠近调度、I/O 或设备启动时进入。每次新增材料都要回答一个具体问题，减少无目标采集。
第四步是把材料汇成责任链。材料之间的关系可以按下面的图阅读，图中的每个节点都对应一个可观察问题，而非工具名称本身。
这条流程有两个关键点。第一，时间线是所有材料的索引，缺少时间线时，日志、trace 和 bug report 只是彼此分散的材料。第二，责任边界结论来自多层证据的交叉验证；App 日志说明请求存在，Framework 状态说明公开 API 的结果，系统服务状态说明资源是否被接受，trace 说明时间消耗位置，metrics 说明影响范围，设备诊断包说明全局状态。
第五步是写出可复核的结论。合格结论应包含现象、复现条件、证据来源、发生层级、责任主体、仍需确认的边界和下一步动作。例如：“在 Android 14 的某两类设备上，App 从后台恢复后 request_camera 到 session_configured 的中位耗时从 120ms 升到 2100ms；App 主线程没有长时间阻塞，首帧延迟集中在系统服务接受请求到相机 session 可用之间；下一步需要设备级 bug report 与 Perfetto trace 对齐 camera service、调度和电源状态。”这种结论把问题停在证据支持的层级，也给出下一步最小材料。
本章最终建立的理解是：移动系统调试面是一套从现象进入系统路径的分层观察方法，工具名称只承担入口作用。面对任何 App 可见异常，先用时间线固定事实，再用 App、Framework、System Service、Kernel、Driver 和 Device Diagnostics 的层级边界选择证据，最后把材料收束成可复核的责任边界。
最小自检任务
某视频通话 App 在用户从后台返回前台后，预览区域黑屏约 2 秒，随后自动恢复。App 没有崩溃，权限指示器亮起，问题集中在部分量产设备和正式发布包上。请写出一个调试面选择顺序，说明每一步要观察什么、能回答什么问题、结论能停在哪个层级。
答案要点
第一步把现象改写成时间线：后台返回、App 恢复、预览视图可用、相机请求发出、session 可用、第一帧到达、第一帧上屏。这样可以区分延迟发生在请求前、API 状态转换中、系统服务调度中，还是设备数据流启动中。
第二步先看 App 层材料：生命周期日志、Surface 或预览视图状态、相机请求时间、回调时间、主线程和渲染线程状态。若首帧已到达但 UI 未上屏，结论靠近 App UI 或渲染路径；若请求已发出但 session 回调延迟，进入 Framework 和系统服务层。
第三步看 Framework 层材料：权限状态、session configure 结果、availability callback、runtime error 或中断通知。它能回答公开 API 是否接受请求、是否发生中断、是否存在可见错误。结论应停在公开 API 可见状态。
第四步在平台允许时看系统服务和设备级诊断：Android 可使用 logcat、dumpsys、bugreport、Perfetto 等材料；Apple 可使用 Console、Instruments、MetricKit、crash logs、diagnostic logs 或 sysdiagnose。它们能回答资源所有权、服务队列、调度、电源、温度、内存和设备状态是否支持系统层或驱动层判断。
第五步用 Release / Production 视角收束：正式包重点看低开销埋点、符号化材料、聚合指标、设备型号、系统版本、电源和温度状态。若问题只集中在部分设备，结论应包含设备族、系统版本和诊断材料边界，并把下一步动作限定为收集对应设备的时间线和设备级诊断包。
本章知识点总结
- 调试面：调试面是系统开放的观察入口集合，用来把 App 可见现象转换成可验证的状态、时间和责任边界。
- 观察边界：App、Framework、系统服务、内核、驱动和设备诊断各自只能支撑本层可见范围内的结论。
- 时间线：时间线是日志、trace、metrics、crash report 和诊断包之间的共同索引。
- App 层：App 层主要确认请求是否发起、回调是否到达、线程和 UI 状态是否符合预期。
- Framework 层：Framework 层通过公开 API 状态、权限结果、session 回调和错误对象解释平台能力状态。
- 服务层：系统服务层负责资源所有权、并发访问、策略检查、队列和跨进程请求。
- 内核层：内核层通过调度、内存、IPC、I/O、电源和设备事件解释低层资源推进情况。
- 日志职责：日志记录离散事件，适合建立事件顺序和确认某个路径是否执行。
- Trace 职责：trace 还原时间线，适合定位跨线程、跨进程和系统资源上的时间消耗。
- Metrics 职责：metrics 量化趋势，适合判断问题是否集中在特定设备、版本、状态或用户路径。
- Crash 现场：crash report 保存异常终止现场，适合分析进程终止、线程栈和二进制映射。
- 诊断包：bug report 和 sysdiagnose 保存设备级现场，适合把服务状态、系统日志、资源状态和硬件信号放入同一时间窗口。
- 构建差异：Debug Build 适合细粒度验证，Release Build 适合低开销事实保留，Production Device 受权限和隐私策略约束。
- 平台差异：Android 调试面更开放且受 OEM 影响，Apple 调试面更依赖公开工具、诊断包和行为推断。
- 定位流程：合格定位从现象时间线开始，按层选择材料，最后把证据收束成可复核的责任边界。