首頁 > 技術 > 正文

Android Perfetto 系列 14:heapprofd 与内存 Profiling

2026-10-30  ·  閱讀:157
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
WITH target_process AS (
SELECT upid, pid, name, cmdline
FROM process
WHERE name = 'com.example.app'
ORDER BY start_ts DESC
LIMIT 1
),
target_dump AS (
SELECT MAX(ts_end) AS dump_ts
FROM heap_profile
WHERE upid = (SELECT upid FROM target_process)
AND heap_name = 'libc.malloc'
)
SELECT
d.dump_ts,
p.upid,
p.pid,
p.name AS process_name,
p.cmdline AS process_cmdline,
a.callsite_id,
f.name AS frame_name,
m.name AS mapping_name,
SUM(a.size) / 1024.0 / 1024.0 AS leaf_unreleased_mb,
SUM(a.count) AS unreleased_count
FROM heap_profile_allocation a
JOIN target_process p USING (upid)
JOIN target_dump d ON a.ts <= d.dump_ts
JOIN stack_profile_callsite c ON a.callsite_id = c.id
JOIN stack_profile_frame f ON c.frame_id = f.id
JOIN stack_profile_mapping m ON f.mapping = m.id
WHERE a.heap_name = 'libc.malloc'
GROUP BY d.dump_ts, p.upid, p.pid, p.name, p.cmdline, a.callsite_id, f.name, m.name
HAVING leaf_unreleased_mb > 0
ORDER BY dump_ts DESC, leaf_unreleased_mb DESC
LIMIT 50;

SQL 只能帮你快速找大头。原始表查询把调用栈拆成了 frame 行,容易只看到 malloc、realloc 这类 leaf frame;summary tree 和 UI flamegraph 更适合读完整归因。写稳定脚本前,先用 PRAGMA table_info(heap_profile_allocation); 确认字段,避免不同 Perfetto 版本导致查询失效。

未改变分配量的 dump 可能没有新的 allocation 行,因此用 heap_profile.ts_end 选 dump,再累计 allocation 表。使用较旧 Trace Processor 时先确认 heap_profile schema;没有该表就从 UI 确认 dump 时段,不能退回用 allocation 的 MAX(ts) 假装最终 dump 已成功。还要核对 heapprofd stats。被覆盖的历史增量也不能靠累加恢复。

泄漏判断要做三点对照:操作前、操作后、释放后。这段是报告查询骨架,baseline_dump_ts、after_action_dump_ts、after_release_dump_ts 可以来自业务 marker 最近的 heap dump:

本文由News整理發布,僅供參考。

12345678
評論載入中…

友情連結申請友鏈

聯盟矩陣53