109.ATRACE 调试相机管线：性能瓶颈识别实践

ATRACE 调试相机管线：性能瓶颈识别实践

关键词：
ATRACE、相机调试、性能优化、Camera HAL、systrace、帧卡顿、RequestQueue、BufferQueue

摘要：
Android 相机系统在执行复杂拍照与预览任务时，往往会出现帧丢失、预览卡顿或拍照延迟等问题。定位这些性能瓶颈仅依靠 logcat 或 dumpsys 难以精准溯源。本文围绕 ATRACE 在 Camera 管线中的调试应用进行深入讲解，从如何启用 trace 埋点，到结合 systrace 工具分析多阶段执行路径，为开发者提供一整套系统性调优方法，适用于 HAL 层调试、Request 调度分析、GraphicBuffer 管理等多种典型场景。

目录：

1. ATRACE 在 Android 调试体系中的作用定位
2. 相机系统中的 ATRACE 埋点结构梳理
3. 如何开启 trace 并捕获关键性能数据
4. Systrace 工具的使用流程与可视化解读
5. 实战分析：拍照延迟与帧回调滞后的典型问题追踪
6. ATRACE 与 CameraRequestQueue、BufferQueue 的时序对齐
7. 多平台行为差异下的 ATRACE 结果解析技巧（QTI、MTK、Exynos）
8. 构建自定义 ATRACE 点与日常调试自动化建议

1. ATRACE 在 Android 调试体系中的作用定位

在 Android 相机系统的性能调试过程中，ATRACE 扮演着极其关键的角色。它不仅是一种低开销的系统级埋点机制，还为多线程调度、Binder 通信、图像处理、HAL 接口调用等流程提供了极具时序精度的可视化参考。在复杂的 Camera 管线中，使用 logcat 只能获得离散事件日志，而 ATRACE 则能够完整还原帧级调度路径、请求生命周期、图像处理阻塞点等关键性能指标。

1.1 什么是 ATRACE？

ATRACE（Android Trace）是 Android 平台上用于性能追踪的核心组件之一，其本质是基于内核的 ftrace 机制，通过内嵌在系统组件中的 trace 埋点收集运行时数据。这些数据可通过 systrace 或 perfetto 工具进行可视化展示，支持细粒度的耗时分析。

与 logcat 最大的区别是：

• logcat 是面向事件记录的文本日志；
• ATRACE 是面向执行路径的结构化时序记录。

ATRACE 提供了对线程执行时间、锁竞争、Binder 调度、CPU 核间切换等信息的采样能力，能以微秒级精度还原整个相机请求处理链条。

1.2 ATRACE 在 Camera 系统中的实际作用

在 Camera 系统中，ATRACE 广泛分布在以下模块中：

• Framework 层 ： CameraDeviceImpl , CameraCaptureSession , CameraManager 等模块中的 request 提交、回调处理、状态管理；
• CameraService ：对 request 队列、HAL 调用、线程切换等关键路径进行标记；
• CameraProvider/HAL ：标记与底层图像采集、Buffer 分发、ISP 处理等过程；
• SurfaceFlinger/GraphicBuffer ：跟踪图像从采集到显示的完整链条；
• Binder 层 ：记录跨进程通信的耗时与阻塞点；
• SoC 驱动 （部分平台支持）：例如 QTI 在 HAL3 中嵌入了 ISP 模块处理耗时的 trace 点。

通过这些埋点，开发者可以回答以下问题：

• 为什么帧率下降了？是预览帧丢失，还是 ISP 拍照路径阻塞？
• 哪一阶段导致拍照延迟？是请求构建卡顿还是回调未及时返回？
• 是否是 GPU/CPU 分配不均导致图像处理失败？
• HAL 是否因为 buffer 未就绪发生过超时或等待？

1.3 与其他调试手段的对比

结论是： logcat 和 dumpsys 更适合逻辑校验与接口调试，ATRACE 更适合性能瓶颈与系统性行为分析。

1.4 使用场景总结

• 预览卡顿 / 帧丢失 / 拍照延迟 ：用 ATRACE 分析从 Request 到 Result 的完整路径；
• 多 UseCase 并发下的调度冲突 ：查看各 UseCase 的资源竞争和处理顺序；
• ZSL 快门响应不一致问题 ：分析图像缓存回溯的时间路径；
• HAL 执行耗时评估 ：排查 Sensor→ISP→Buffer 通路中哪个环节耗时最多；
• 平台适配性能回归 ：比较同一流程在不同芯片/系统版本上的 trace 曲线差异。

2. 相机系统中的 ATRACE 埋点结构梳理

在 Android Camera 系统中，ATRACE 埋点分布贯穿 Framework、Native Service、HAL、甚至底层驱动。要高效分析性能瓶颈，理解这些 trace event 的命名结构、触发点与数据意义是必要前提。本章将按模块划分，系统梳理 ATRACE 的核心埋点位置与用途。

2.1 Framework 层埋点（Java 层）

Framework 层主要在以下几个核心类中通过 Trace.beginSection() 与 Trace.endSection() 实现 trace 埋点：

这些 trace 标签通常表现为短时间事件，便于识别高层接口卡顿。

2.2 CameraService（Native Service 层）

CameraService 是性能分析的黄金入口，其 trace 通过 ATRACE_BEGIN() 宏在 C++ 层注入，分布广、粒度细：

此外还有 "camera3::flush" , "camera3::notify" 等标记，可用于排查阻塞、flush 延迟、notify 回调时间等问题。

2.3 HAL 层与 CameraProvider 埋点

HAL 模块通常由芯片厂商实现，Google 提供的参考 HAL3 实现也包含了标准 trace：

trace 内容往往包含帧号（Frame Number）、请求 ID（RequestID），便于做请求回溯。

2.4 Graphic 系统与 SurfaceFlinger 埋点

图像从 HAL 输出后经 Surface 系统到屏幕展示，ATRACE 可见完整路径：

尤其在预览卡顿时，可结合 Camera trace 分析是否存在 Buffer 拖尾、队列堵塞等问题。

2.5 Binder 通信 trace

系统自动记录每一次 Binder 通信的调度成本：

• "binder transaction" ：记录 Java → Native / Native → HAL 的通信耗时；
• "binder reply" ：记录响应时间；
• "binder lock contention" ：反映锁等待/资源冲突。

在相机预览卡顿或 HAL 拍照失败时，往往可以从 Binder 调用栈中识别谁阻塞了通路。

2.6 调用链可视化效果

最终使用 atrace 或 perfetto 采集数据后，将得到一条完整的时间线，包括：

[App Thread] → [CameraDeviceImpl] → [CameraService] → [Camera3Device] → [HAL] → [SurfaceFlinger]

每个阶段的耗时都能从 trace tag 上识别出来。例如一个拍照请求可拆解为：

• submitCaptureRequest: 3ms
• configureStreams: 8ms
• processCaptureRequest: 2ms
• HAL 响应: 25ms
• GraphicBuffer 传输: 12ms

3. 如何开启 trace 并捕获关键性能数据

在调试 Android 相机系统中的性能瓶颈时，trace 捕获是最关键的实战技能之一。无论是冷启动慢、拍照卡顿、预览掉帧，还是 HAL 响应延迟，ATRACE 都能通过精准的时间线揭示瓶颈所在。本章将基于 Android 13/14 实战经验，讲解从命令行抓取到可视化分析的全流程。

3.1 打开设备调试环境

前置条件：

• 已开启设备开发者选项与 USB 调试；
• 安装 Android SDK 工具（包含 adb , atrace , perfetto ）；
• 确保设备已 root 或开启 adb root （对 native trace 更关键）；
• 推荐关闭 SELinux enforcing 状态（调试期间）以解锁部分权限。

adb root
adb shell setenforce 0

3.2 使用 ATRACE 命令手动抓取

在开发设备上通过如下命令抓取相机相关模块的性能 trace：

adb shell atrace --async_start -b 4096 -t 10 \
  gfx view wm am hal camera freq sched binder_driver input \
  > /sdcard/camera_trace.html

说明：

• --async_start/-t 指定采样持续时长；
• camera , hal , gfx , binder_driver , freq 是关键模块；
• -b 设置缓冲区大小（单位 KB）；
• 输出为可用 Chrome 打开的 HTML 文件。

采样完毕后：

adb shell atrace --async_stop
adb pull /sdcard/camera_trace.html

3.3 更推荐的现代方式：使用 perfetto

从 Android 10 起，Google 推荐使用 perfetto 替代传统 atrace 工具。它支持更多 trace source（如 binder async、syscall、gpu），而且 UI 更友好，数据更稳定。

快速抓取方式：

adb shell perfetto \
  -o /data/misc/perfetto-traces/trace_camera.pb \
  -c /data/misc/perfetto-traces/trace_config_camera.txt \
  --background

其中 trace_config_camera.txt 内容可如下配置：

buffers: {
  size_kb: 2048
}
data_sources: {
  config {
    name: "linux.ftrace"
    ftrace_config {
      ftrace_events: "camera"
      ftrace_events: "binder_driver"
      ftrace_events: "sched/sched_switch"
      atrace_categories: "camera"
      atrace_categories: "hal"
      atrace_categories: "view"
    }
  }
}

抓取完成后：

adb pull /data/misc/perfetto-traces/trace_camera.pb

然后访问 https://ui.perfetto.dev 上传文件分析。

3.4 抓取 Camera 特定事件的 trace 标签

以下是实际调试中推荐关注的 Trace 分类与标签：

可以使用 perfetto 的 Timeline 视图查看事件间关系，点击帧节点可查看对应的 Request ID、Frame Number。

3.5 建议组合调试工具使用

3.6 实战建议

• 抓冷启动问题 ：从打开 Camera 到首次预览显示，建议 -t 10 ，trace 期间避免其他系统干扰；
• 抓拍照延迟 ：trace 前点预览、trace 中触发拍照、trace 后停止采集，可定位 processCaptureRequest → HAL → JpegCompressor 路径；
• 卡顿排查 ：trace 中结合 sched/sched_switch 查看是否线程被系统抢占；
• 双摄/多帧同步异常 ：建议加上 freq , binder_driver , input 标签观测 pipeline 行为。

4. Systrace 工具的使用流程与可视化解读

Systrace 是 Android 原生支持的性能分析工具，基于系统内核的 tracing 机制，可生成 Chrome 可视化的 HTML 性能报告。在相机系统调试中，它主要用于识别 UI 卡顿、帧延迟、请求阻塞等问题。本章将基于实际工程流程，详解如何配置、抓取与解读 Systrace 输出，定位 Camera pipeline 中的瓶颈点。

4.1 Systrace 的适用场景

Systrace 更适合以下类型的性能问题：

• 预览帧率波动或卡顿
• 拍照操作的 UI 假死或响应延迟
• Surface 显示异常或 VSync 抖动
• Camera 请求提交 → 渲染 → 显示路径的线程调度瓶颈

4.2 准备工作与依赖安装

从 Android 8.0 起，Systrace 工具集已内置在 platform-tools 和 android-sdk 中，典型路径为：

<android-sdk>/platform-tools/systrace/systrace.py

确保设备开启开发者选项和 USB 调试。

4.3 启动 trace 抓取

典型的命令如下：

python systrace.py \
  gfx view wm am hal res dalvik camera sched freq \
  -t 10 -b 32768 \
  -o trace_camera_systrace.html

参数说明：

• -t ：trace 持续时间（单位：秒）
• -b ：缓冲区大小（单位：KB）
• -o ：输出文件名（HTML 格式）

建议开启如下模块用于调试 Camera 路径：

gfx view wm am hal res camera binder_driver sched freq

设备连接后可直接执行命令，等待 10 秒自动生成结果文件。

4.4 Chrome 可视化解读流程

Systrace 生成的 HTML 文件可以直接用 Chrome 打开，页面结构包括：

• CPU 使用情况总览 （Threads 时间线）
• 主线程 / Binder 线程 trace 节点
• Camera pipeline 各个阶段函数执行时长
• Surface 显示、UI 渲染、VSync 帧率帧延迟轨迹

常见模块解析：

4.5 性能瓶颈定位示例

场景 1：拍照慢

• Trace 点： Camera3Device::processCaptureRequest → HAL::process_capture_request
• 观察 HAL 调用是否阻塞超 20ms，可能需优化对焦流程或 JPEG 压缩路径。

场景 2：预览卡顿

• Trace 点： BufferQueue::queueBuffer , SurfaceFlinger::DrawFrame
• 分析 Producer（Camera）与 Consumer（Surface）同步失调，是否存在 buffer starvation。

场景 3：UI 响应延迟

• Trace 点： InputDispatchingTimedOut , Choreographer#doFrame
• 确认主线程是否被 Binder 阻塞，如等待某 camera callback 导致无法绘制。

4.6 Systrace 与 ATRACE 的区别与结合使用建议

工程实践中，建议先用 Systrace 快速定位问题时段，再结合 ATRACE/perfetto 精细分析具体模块耗时。

5. 实战分析：拍照延迟与帧回调滞后的典型问题追踪

在复杂的相机调用链中，拍照延迟或帧回调滞后是用户体验的常见痛点。本章将以典型 Android 相机应用中的 ATRACE 和 Systrace 分析流程为基础，解析如何从实际 trace 数据中识别性能瓶颈，定位滞后的源头，结合 HAL、Binder、CameraService 层的调度逻辑展开系统追踪。

5.1 问题现象与诊断入口

典型表现：

• 拍照按钮点击后，实际成像慢，预览停滞。
• onCaptureCompleted() 回调延迟严重。
• 触发 ImageReader.acquireNextImage() 超时。

初步诊断建议：

• 确定是否为单帧问题还是系统性帧延迟。
• 观察 HAL 提交 → Result 回调时间差。
• 使用 ATRACE_BEGIN/END 包裹 Camera 请求代码。

5.2 trace 轨迹中的关键时间轴

① 拍照触发 → 请求提交阶段

关注：

• CameraDevice::submitCaptureRequests
• Camera3Device::submitRequests
• HAL::process_capture_request

若延迟 > 10ms，可能因 JPEG 流 pipeline 创建缓慢，或 RequestQueue 滞留。

② HAL 处理阶段

关注：

• CameraHal::process_capture_request
• configure_streams_locked
• sendRequest

若 HAL 调用被卡住，需检查：

• ISP pipeline 是否占用或处于重配置状态。
• Sensor trigger 是否被长时间 block（如慢速对焦）。

③ Result → 回调分发阶段

关注：

• processCaptureResult
• Camera3OutputStream::returnBuffer
• ImageReader::postFrameAvailable

若 frame result 回调耗时高或 binder_transaction 拥堵，可能：

• 图像帧未及时入队 BufferQueue。
• Binder thread backlog，导致回调线程调度延迟。

5.3 拍照延迟实际分析案例

设备：Pixel 6 Pro / Android 14

现象： 使用 Camera2 拍照，触发快门后延迟约 500ms，回调滞后。

Trace 样本分析（部分时间点）：

诊断结论：

• 请求提交仅用时 <40ms，HAL 响应慢 → JPEG 编码路径耗时约 930ms。
• Binder 回调顺利，但 UI 响应落后 100ms，GC 触发或主线程抢占。

优化建议：

• JPEG 编码前使用 ZSL + Reprocess 替代实时 pipeline。
• 使用后台线程处理 onCaptureCompleted() 内逻辑，避免阻塞主线程。

5.4 拍照卡顿背后的数据通路瓶颈典型归因

5.5 高效日志配置建议（logcat + trace 双向验证）

日志设置建议：

setprop log.tag.Camera HAL1/V
setprop log.tag.Camera3Device VERBOSE
setprop log.tag.ImageReader VERBOSE

配合 ATRACE 开启：

ATRACE_BEGIN("submit jpeg capture");
cameraDevice->capture(request);
ATRACE_END();

或以 shell 方式统一打开：

atrace -c -b 32768 -t 5 -z camera hal binder_driver sched gfx > trace_camera_perf.html

6. ATRACE 与 CameraRequestQueue、BufferQueue 的时序对齐

在 Camera 系统中，实际性能瓶颈往往不仅发生在 CPU 运算或 HAL 调用阶段，还与请求调度（ CameraRequestQueue ）和图像缓冲（ BufferQueue ）的协作效率密切相关。本章将结合 ATRACE 机制，解析如何从时间轴上对齐这两个关键组件的行为，深入识别调度延迟、丢帧、帧阻塞等问题的根源。

6.1 CameraRequestQueue 的 ATRACE 关键打点结构

CameraRequestQueue 是 CameraService 中调度请求流的核心模块，其行为直接影响请求进入 HAL 的节奏。

在 frameworks/av/services/camera/libcameraservice/device3/Camera3Device.cpp 中，典型 trace 埋点包括：

ATRACE_CALL(); // submitRequests()
ATRACE_ASYNC_BEGIN("camera3->HAL_request", request_id);
ATRACE_ASYNC_END("camera3->HAL_request", request_id);

关键字段：

• Request submit time（提交请求）
• Request start in HAL（进入 HAL）
• Request completed（结果上报）

通过这些埋点，可以精确描绘如下过程的时间线：

App → CameraService → CameraRequestQueue → HAL → CaptureResult

若某帧的 Request 在 HAL 开始前有较长间隔，说明 RequestQueue 堆积或同步阻塞。

6.2 BufferQueue 时序与 Surface 绑定帧输出轨迹

图像流进入 UI 层，依赖 BufferQueue 实现生产者（HAL）与消费者（SurfaceView/ImageReader）间的缓冲流动。关键 trace 埋点路径位于：

• frameworks/native/libs/gui/BufferQueueProducer.cpp
• frameworks/native/libs/gui/BufferQueueConsumer.cpp

核心埋点：

ATRACE_NAME("queueBuffer");
ATRACE_NAME("dequeueBuffer");
ATRACE_NAME("acquireBuffer");

通过这些 trace，可以形成如下时序链：

HAL: queueBuffer → SurfaceFlinger/GL → dequeueBuffer → UI 消费线程

若 dequeueBuffer() 延迟明显，常见原因包括：

• 缓冲池不足
• Surface 未及时消费（UI卡顿）
• 绑定 Surface 不支持当前帧格式或分辨率

6.3 典型问题对齐分析：帧丢失与延迟同步

6.4 实战对齐路径建议：构建 Request-to-Buffer 流追踪链

要建立清晰的调试路径，推荐以下三步：

1. 构建每帧请求 → 成功 buffer 输出 的链路映射

   • 使用 Request ID/Frame Number 标记链路节点。
   • 结合 onCaptureCompleted() 中的时间戳、Tag 标记。

2. 开启 ATRACE 并同时 dump 关键模块

   atrace -z -b 32768 -t 10 -a system_server -a cameraserver camera hal gfx input view sched > trace_camera_perf.html
   
   

3. 结合 logs + systrace 还原帧级别 timeline

   • 起点：App 发出拍照命令（点击）
   • 中段：CameraRequestQueue 提交 → HAL 执行
   • 终点：图像帧入队 BufferQueue 并被 UI 消费

6.5 多 UseCase 并发下的时序一致性建议

若系统启用 Preview + ImageCapture + Analysis 并发模式，建议：

• 将不同 UseCase 的 Surface 设置不同的 tag，便于 trace 区分。
• 使用 Surface.setSharedBufferModeEnabled(true) 启用缓冲共享（Android 12+）。
• 明确主帧与辅帧的输出路径，并避免复用同一 Surface 引发调度冲突。

7. 多平台行为差异下的 ATRACE 结果解析技巧（QTI、MTK、Exynos）

不同 SoC 厂商（如 Qualcomm、MTK、Samsung Exynos）在 Camera HAL、Buffer 管理、ISP 调度等方面均有独立实现路径，导致 ATRACE 输出的内容、命名习惯及时序行为上存在明显差异。本章聚焦实际调试中如何理解并分析各平台的 trace 数据，确保跨平台的性能问题追踪具备一致性与可读性。

7.1 Qualcomm 平台（QTI）的 ATRACE 特征分析

关键特点 ：

• 使用 camera.qcom.software 命名空间划分 trace 域。

• ISP/CPP/FD 等模块的调度行为较为细化。

• 常见 trace 标记如：

  • QCamera3HWI::captureRequest
  • mm-camera: cpp_thread
  • mm-camera: isp_process_frame

调试建议 ：

• 使用 atrace hal mm-camera camera view sched 捕获完整 ISP 流程。

• 检查 mm-camera 域的延迟集中区，典型的卡顿帧都在此暴露。

• trace 标签顺序能完整对齐以下链路：

  Request → ISP 构图 → JPEG 编码 → Buffer queue
  
  

常见异常信号 ：

• isp_process_frame 时间跨度异常长 → ISP 处理阻塞。
• jpeg_process_job 超过 40ms → JPEG 编码瓶颈。

7.2 MTK 平台的 trace 埋点与行为特征

关键特点 ：

• 埋点集中在 mtkcam-* 域，常以线程名区分模块角色。

• 强调 feature pipeline 架构，trace 会呈现多个并发处理路径。

• 常见 trace 点：

  • mtkcam-PipelineModel
  • mtkcam-P2AProcessing
  • mtkcam-JpegNode
  • mtkcam-ZslNode

调试建议 ：

• 使用 atrace hal mtkcam sched gfx 捕获高层逻辑与驱动通道。
• 多帧路径需注意 ZSL、RAW、YUV 同时处理时的 trace 分离。
• 注意 trace 中各模块线程的 FrameNo 打印，可精准对齐请求帧。

异常行为辨识 ：

• P2AProcessing > 33ms：P2 节点图像处理过慢。
• ZslNode 堆积明显：缓存未及时消费，或流控异常。

7.3 Samsung Exynos 平台的 trace 输出特征

关键特点 ：

• Trace 埋点较为抽象，集中在 ExynosCamera 域。
• 使用 requestHandling , frameFactory , captureProcess 等模块标签。
• 强调 frame factory 架构模型，构建 Trace Flow 时需逻辑反推。

常见标签举例 ：

• ExynosCamera::handleRequest
• ExynosCameraFrameFactory::createNewFrame
• ExynosCameraNode::putBuffer

调试建议 ：

• 使用 atrace hal camera ExynosCamera sched 捕获调度路径。
• 使用 logcat | grep ExynosCamera 配合 trace 补充帧级时间信息。
• 将 requestID 与 frameCount 映射，建立 timeline 追踪。

常见异常表现 ：

• frameFactory 初始化时长过长：Session 构建瓶颈。
• putBuffer 卡顿：Buffer 回收慢、Surface 未及时消费。

7.4 多平台差异下的统一分析策略建议

为提升跨平台调试效率，建议开发团队统一以下策略：

7.5 案例总结：连拍掉帧问题在三平台的 trace 对比

8. 构建自定义 ATRACE 点与日常调试自动化建议

在真实项目开发过程中，系统提供的 ATRACE 埋点虽然丰富，但并不能覆盖所有业务链路、平台定制路径及 UseCase 特有流程。构建自定义 ATRACE 埋点机制，配合标准化的调试脚本与工具链，是实现高效性能定位和系统级问题闭环的关键。本章将围绕实际工程经验展开分析，提供一套可落地的开发者调试增强路径。

8.1 ATRACE 标签自定义规范建议

开发者可通过 <cutils/trace.h> 或 android/trace.h 添加自定义 trace 点，推荐使用以下结构约定：

ATRACE_NAME("MyCameraModule::startRequest");
...
ATRACE_BEGIN("MyCameraPipeline::JPEGCompress");
// 执行耗时操作
ATRACE_END();

命名建议：

• 命名统一使用双层结构：模块名::功能点，例如 ZSLManager::selectBestFrame

• 对应模块使用唯一前缀，避免与系统已有 trace 标签冲突

• 样例分类：

  功能模块	推荐 Trace 标签
  拍照流程	CaptureFlow::submitRequest
  ZSL 管理器	ZSLManager::selectFrame , ZSL::flush
  UseCase 管理	UseCaseManager::bindPreview
  ImagePipeline	ImagePipeline::cropAndScale
  Meta 分析	MetadataParser::validateExposure

8.2 常用自定义 trace 应用场景

• 帧处理瓶颈识别：

  • 在图像处理路径上标注每一帧处理步骤，便于定位卡顿段落。

  • 示例：

    ATRACE_NAME("JPEGCompress::encode");
    jpeg_encode(...);
    
    

• ZSL 拍照帧选择调试：

  • Trace ZSL buffer pool 中帧入队/出队。
  • 标注候选帧数量、选中时间戳等关键信息。

• Pipeline 组装分析：

  • 标注 SurfaceRequest 的创建 → 提交过程。
  • 区分 Session 重建是否因绑定 UseCase 数量变化所致。

8.3 自动化 trace 捕获脚本（开发者通用模板）

在设备端部署如下脚本，实现标准调试流程快速复现：

#!/system/bin/sh

echo "Starting Camera Trace..."

TRACE_TAGS="camera hal sched freq"
TRACE_DURATION=10  # seconds

adb shell "atrace --async_start -b 4096 ${TRACE_TAGS}"
sleep ${TRACE_DURATION}
adb shell "atrace --async_stop -z -o /data/local/tmp/trace_camera.txt"

adb pull /data/local/tmp/trace_camera.txt ./trace_camera.txt
echo "Trace complete: saved as trace_camera.txt"

可结合 Perfetto 转换为 HTML 可视化格式：

perfetto --txt ./trace_camera.txt -o trace_output.html

8.4 日常开发调试推荐流程

8.5 工程实践建议与调试框架封装

为了形成团队可复用的调试标准，推荐构建统一的调试封装类：

class TraceGuard {
public:
    explicit TraceGuard(const char* label) {
        ATRACE_BEGIN(label);
    }
    ~TraceGuard() {
        ATRACE_END();
    }
};

使用方式：

void captureFrame() {
    TraceGuard trace("Capture::SubmitRequest");
    // 拍照处理代码
}

优势：

• 保证 begin/end 成对出现，避免 trace 截断
• 支持代码审计中快速识别热点流程
• 配合 GTest/Monkey 自动化回归定位性能波动

8.6 总结

借助 ATRACE 的定制化能力，开发者可以将关键拍照流程、缓冲管理、ZSL 控制逻辑与平台底层对齐，形成跨端统一的调试闭环体系。配合自动采集与可视化分析工具，Camera 性能调优的效率与精准度将大幅提升，建议团队在早期项目阶段即嵌入相关机制，以支撑后续快速迭代与回归分析。

本文转自 https://jc-performance.cn//online/4623_148670588.html，如有侵权，请联系删除。