Perfetto重大更新：一边分析trace一边看画面录屏结合功能

背景

大家在使用Perfetto分析相关trace时候，经常会分析SurfaceFlinger主线程每个vsync的相关slice，虽然也可以通过hwc的合成图层知道当前显示每一帧画面是啥，但是没有具体的与每一帧的画面的功能，大家都很希望可以在分析trace时候顺便有当前手机的运行画面可以结合起来看，类似winscope分析闪黑问题一样，这样就可以更加直观清晰分析一些卡顿显示等性能问题。
针对这个需求Perfetto官方文档已经有这块trace中如何与录屏结合的说明了，所以本文就是摘录一下官方是如何手把手教你配置Perfetto抓取时候抓取录屏结合使用的功能。
（ps：但是马哥目前编译的最新aosp16 r4设备并没有成功，可能google公开版本中没有开放这个功能，有可以成功的记得可以留言告诉马哥哈）

屏幕录制 (Screen Recording)

android.display.video 数据源会记录 trace 采集期间每个物理屏幕显示的内容。Perfetto 将帧作为编码后的视频流存储在 trace 中，UI 会添加每个屏幕的时间线 track，在浏览器中解码它们。你可以悬停在 track 上预览帧、像播放视频一样回放帧，以及点击任意帧将其与下方的 track 对齐。

---

它会录制屏幕的实际内容，因此仅适用于 userdebug（debuggable）设备，任何包含此内容的 trace 都是敏感的：它精确地显示了屏幕上的内容。

本指南涵盖：

• 工作原理及成本: 帧如何进入 trace，以及对设备的开销。
• 采集屏幕视频：三种开启方式 — 设备端开关、录制页面以及可完全控制质量和大小的原始配置。
• 查看屏幕视频：时间线 track、悬停预览帧以及保持时间线同步地回放采集内容。

工作原理及成本

在数据源启用期间，设备将每个屏幕显示的内容编码为视频流并存储在 trace 中 — 屏幕每次变化产生一帧 — UI 在浏览器中将其解码回来。这有两方面成本：

• 编码器和 CPU 开销。 在 trace 运行期间，编码帧使用设备的视频编码器。在繁忙的屏幕上这会增加负载，并可能干扰你正在测量的时序。
• Trace 大小。 视频流随分辨率和屏幕变化量而增长；下面的 scale 和 max_stream_size_bytes 选项可以控制其大小上限。

当数据源关闭时，零成本。

采集屏幕视频

有三种方式开启屏幕视频采集，从最简单到最多控制。

在设备上，使用 System Tracing

System Tracing 应用在 Trace settings 下有一个 Record display video 开关。启用它，然后像往常一样录制 trace — 采集会自动包含在内。这是在你手中的设备上最快的方式 — 无需编写配置。

从录制页面

打开 Perfetto UI 录制页面，在 Android probes 下找到 Display video frames，然后启用它。这会使用 producer 的默认设置将 android.display.video 数据源添加到生成的配置中。

从原始 trace 配置

要获得完全控制，自行编写配置。启用 android.display.video，并添加 display_video_config 来设置质量和大小。不带选项时，每个屏幕使用设备的默认设置：

data_sources {
  config {
    name: "android.display.video"
  }
}

添加 display_video_config 来调优采集。每个字段都是可选的；未设置或为零的字段使用 producer 默认值。

data_sources {
  config {
    name: "android.display.video"
    display_video_config {
      scale: 0.5
      format: FORMAT_H264
      key_frame_interval_secs: 2
      max_stream_size_bytes: 67108864  # 64 MiB per display
    }
  }
}

选项	描述
scale	采集前应用于每个屏幕分辨率的比例因子，例如 0.5 为一半大小或 0.25 为四分之一。较低的比例意味着更少的编码器负载和更小的 trace，但会牺牲细节。
format	FORMAT_H264（默认）或 FORMAT_HEVC。HEVC 在相同质量下产生更小的流，但设备必须支持 HEVC 编码才能采集，浏览器必须支持 HEVC 解码才能预览。
key_frame_interval_secs	关键帧的发射频率。较小的值使定位更流畅但增大 trace；较大的值更紧凑但拖拽较慢。
max_stream_size_bytes	每个屏幕的发送字节数上限。当屏幕达到上限时，其流被拆除（记录大小上限错误），而非无限增长。未设置时，设备默认每屏幕 256 MiB 的上限。

大小限制

屏幕视频每屏幕限制为 256 MiB，在两个独立的位置强制执行：

• 在设备端，max_stream_size_bytes 限制每个流的发送量（默认 256 MiB；达到限制时记录大小上限错误）。
• 独立地，trace_processor 在加载 trace 时丢弃每个流超过 256 MiB 的任何帧，因此仅提高设备端上限不会在 UI 中获得更多帧。

注意: 在长会话或高分辨率下，视频因此可能在 trace 结束之前停止。这两个限制都源自保存流的存储成本，而非根本性约束。如果它们妨碍到你，请在跟踪 issue perfetto#6609 上评论和点赞以便进行优先级排序。

查看屏幕视频

时间线 Track

包含屏幕视频的 trace 会显示一个 Video Frames 分组，每个屏幕有一个 track（对于手机，通常是一个 Built-in Screen）。Track 上的每个 slice 是一个采集的帧，标有帧号。该编号仅是采集帧的顺序计数器 — 与帧时间线中的 vsync ID 无关。

悬停预览帧

沿 track 移动指针即可预览帧。光标下的帧被解码并显示为该行上方的缩略图，因此你可以拖拽寻找想要的帧。

回放

点击一个帧打开其详情。面板左侧显示帧号和时间戳，右侧显示解码的 Preview，页眉中有播放控件：上一帧、播放/暂停、下一帧和播放速度选择器。按下播放，采集内容像视频一样播放：预览逐帧前进，时间线选择也随之前进，因此 UI 其余部分始终保持与屏幕上内容对齐。使用上一帧/下一帧按钮逐帧前进，或更改速度选择器以更慢（最低 0.1×）或更快（最高 2×）地回放。

---

Screen Recording

The android.display.video data source records what each physical display showed while a trace was being captured. Perfetto stores the frames as an encoded video stream inside the trace, and the UI adds a per-display timeline track that decodes them in the browser. You can hover the track to preview a frame, play the frames back like a video, and click any frame to line it up with the tracks below it.

---

It records the actual contents of the screen, so any trace that contains it is sensitive: it shows exactly what was on the display. On userdebug (debuggable) devices it is available out of the box. On user (production) builds it is disabled by default and must be unlocked with a system property first — see Prerequisite on user builds.

This guide covers:

• How it works, and what it costs — how the frames get into the trace, and the overhead on the device.
• Capturing display video: the property to set first on user builds, then the three ways to turn it on — the on-device toggle, the record page, and a raw config with full control over quality and size.
• Viewing display video: the timeline track, hovering to preview a frame, and playing the capture back with the timeline kept in sync.

How it works, and what it costs

While the data source is enabled, the device encodes what each display shows into a video stream stored in the trace — one frame each time the screen changes — and the UI decodes it back in the browser. This has two costs:

• Encoder and CPU overhead. Encoding frames uses the device’s video encoder while the trace runs. On a busy display this adds load and can perturb the timing you are measuring.
• Trace size. The stream grows with resolution and with how much the screen changes; the scale and max_stream_size_bytes options below keep it bounded.

When the data source is off, it costs nothing.

Capturing display video

There are three ways to turn on display-video capture, from the simplest to the most control. On user builds there is also a one-time-per-boot property to set first — see the prerequisite below.

Prerequisite on user builds

On userdebug (debuggable) devices, display-video capture works out of the box, and you can skip this step. On user (production) builds it is disabled by default: unlock it first by setting a system property over ADB.

adb shell setprop debug.tracing_video_allowed true

This property is not persistent — it is cleared on the next reboot. After the device restarts you have to set it again before you can capture display video. Once it is set, capture works through any of the methods below: the on-device toggle, the record page, or a raw config.

On the device, with System Tracing

The System Tracing app has a Record display video toggle under Trace settings. Enable it, then record a trace as usual — the capture is included automatically. This is the quickest route on a device you are holding — no config to write.

(Illustration: The “Record display video” toggle in the System Tracing app’s Trace settings, enabled, described as “Captures encoded display frames (adds encoder overhead, can cause jank, and records screen contents)”)

From the record page

Open the Perfetto UI record page, find Display video frames under the Android probes, and enable it. This adds the android.display.video data source to the generated config with the producer’s default settings.

(Illustration: The Perfetto record page with “Android apps & svcs” selected in the sidebar; the “Display video frames” probe sits in the probe list, toggled off, captioned “Captures what each display showed during the trace.”)

From a raw trace config

For full control, write the config yourself. Enable android.display.video, and add a display_video_config to set quality and size. With no options, each display uses the device’s default settings:

data_sources {
  config {
    name: "android.display.video"
  }
}

Add a display_video_config to tune the capture. Every field is optional; an unset or zero field uses the producer default.

data_sources {
  config {
    name: "android.display.video"
    display_video_config {
      scale: 0.5
      format: FORMAT_H264
      key_frame_interval_secs: 2
      max_stream_size_bytes: 67108864  # 64 MiB per display
    }
  }
}

Option	Description
scale	Factor applied to each display’s resolution before capture, e.g. 0.5 for half size or 0.25 for quarter. Lower scale means less encoder load and a smaller trace, at the cost of detail.
format	FORMAT_H264 (the default) or FORMAT_HEVC. HEVC produces a smaller stream at the same quality, but the device must support HEVC encoding to capture it and the browser must support HEVC decoding to preview it.
key_frame_interval_secs	How often a keyframe is emitted. Smaller values make seeking snappier but grow the trace; larger values are more compact but slower to scrub.
max_stream_size_bytes	A per-display cap on emitted bytes. When a display hits it, its stream is torn down (a size-cap error) rather than growing without bound. Left unset, the device applies a default cap of 256 MiB per display.

Size limits

Display video is limited to 256 MiB per display, enforced in two separate places:

• On the device, max_stream_size_bytes caps how much each stream emits (256 MiB by default; a size-cap error is recorded when it is hit).
• Independently, trace_processor drops any frames beyond 256 MiB per stream when it loads the trace, so raising the on-device cap alone will not get you more frames in the UI.

Note: On a long session or at a high resolution, the video can therefore stop before the end of the trace. Both limits exist because of the memory cost of holding the stream, not a fundamental constraint. If they get in your way, comment on and upvote the tracking issue perfetto#6609 so it can be prioritised.

Viewing display video

The timeline track

A trace that contains display video shows a Video Frames group with one track per display (for a phone, typically a single Built-in Screen). Each slice on the track is one captured frame, labelled with a frame number. That number is just a sequential counter of captured frames — it has nothing to do with the vsync ids in the frame timeline.

(Illustration: The Perfetto timeline with the “Video Frames” group’s “Built-in Screen” track pinned to the top — a row of coloured slices labelled Frame 30, Frame 57, and so on — above the CPU scheduling tracks)

Hovering to preview a frame

Move the pointer along the track to preview frames. The frame under the cursor is decoded and shown as a thumbnail above the row, so you can scrub to find the frame you want.

(Illustration: Sweeping the cursor along the video-frames track; a decoded thumbnail of the frame under the cursor follows along above the row, updating as the cursor moves)

Playing back

Click a frame to open its details. The panel shows the frame number and timestamp on the left and a decoded Preview on the right, with playback controls in the header: previous frame, play/pause, next frame, and a playback-speed selector. Press play and the capture runs as a video: the preview advances through the frames and the timeline selection moves with it, so the rest of the UI stays lined up with what is on screen. Step one frame at a time with the previous/next buttons, or change the speed selector to play back slower (down to 0.1×) or faster (up to 2×).

(Illustration: Playing a display-video capture back with the video-frames track pinned at the top: in the details panel the decoded preview advances from the settings screen to the launcher while the frame number and timestamp update)

---

Source: Screen Recording - Perfetto Docs - https://perfetto.dev/docs/data-sources/video-frames

原文地址：
https://mp.weixin.qq.com/s/Er3MbxiygC4XzXcBXYWLiA

更多framework和性能优化实战，请关注下面“千里马学框架”