android 如何分析应用的内存（十八）

在前面两篇文章中，先是介绍了如何用AS查看Android的堆内存，然后介绍了使用MAT查看

Android的堆内存。AS能够满足基本的内存分析需求，但是无法进行多个堆的综合比较，因此引入了MAT工具。它可以很好的在两个堆之间进行比较。两个工具已经能解决95%的内存问题了。

但是在一些极端情况下，如多线程带来的内存泄漏，上面两个工具可能就不太好定位问题，即泄漏点的调用栈和调用线程了。

对于Android来讲，怎样才能定位这种多线程调用带来的内存呢？下面是一些经验之谈：

如果能够添加代码，对于不同的线程，在泄露的对象上，添加一个字段，用于表示线程的id。此方法比较简单，就不再赘述
如果不能添加代码，那么就需要同时录制java的调用栈和java的堆。根据在同时间段，进行逻辑比较，得出是哪一个调用栈导致的内存泄露。如，通过比较哪个调用栈调用的次数最多，哪个调用栈分配的内存最多。甚至需要在一段时间间隔之间做差分，来获得泄露的对象和调用栈之间的关系。这些方法往往需要一定的经验进行逻辑处理。

本文将围绕不能添加代码的情况，进行分析这种极端情况。

Android Studio虽然提供了java调用栈的录制和java 堆的转储。但是他们无法同时使用，导致在时间轴上面的对比无法完成。但是Perfetto提供了类似的功能。

接下来将以Perfetto为工具，首先介绍同时录制java的调用栈和java堆，在逻辑上进行比较，得出泄漏点的调用栈。然后在一定时间间隔上，对java调用栈和java堆进行差分比较，得出泄漏点的调用栈。

Perfetto同时录制堆栈和heap dump

在android 如何分析应用的内存（十三）------perfetto一文中我们介绍了Perfetto的使用方法。接下来我们将使用常规模式，来同时录制java heap和java callstack。

shell 复制代码

adb shell perfetto \
  -c - --txt \
  -o /data/misc/perfetto-traces/trace \
<<EOF

buffers: {
    size_kb: 63488
    fill_policy: DISCARD
}
buffers: {
    size_kb: 2048
    fill_policy: DISCARD
}
data_sources: {
    config {
        name: "android.packages_list"
        target_buffer: 1
    }
}
data_sources: {
    config {
        name: "android.heapprofd"
        target_buffer: 0
        heapprofd_config {
            sampling_interval_bytes: 4096
            process_cmdline: "com.example.test_malloc"
            shmem_size_bytes: 8388608
            block_client: true
            ## 只录制com.android.art的堆
            heaps: "com.android.art"
        }
    }
}
## 增加了第二个数据源
data_sources: {
    ## 数据源配置
    config {
        ## 名字必须为"android.java_hprof"
        name: "android.java_hprof"
        ## 指定目标buffer，关于目标buffer的含义见android 如何分析应用的内存（十三）
        target_buffer: 0
        ## java_hprof的配置
        java_hprof_config {
            ## dump的进程名为："com.example.test_malloc"
            process_cmdline: "com.example.test_malloc"
        }
    }
}
## 时间修改为60s
duration_ms: 60000

EOF

在上面的命令中，我们新增了一个data_source，并且将其指定为录制java heap。同时还有另外一个data_source即android.heapprofd。它会录制指定进程的堆内存，因为我们暂时不需要native堆，所以在heaps中设置了"com.android.art"

关于Perfetto配置文件的说明见：android 如何分析应用的内存（十三）------perfetto

分析结果

输入上面的命令，然后操作APP，60s之后，会在/data/misc/perfetto-traces/trace中形成结果文件，将其pull出来，用https://ui.perfetto.dev/打开即可。如下图

图中：

标记1：到GC root的这条路的retained size大小。
标记2：到GC root的这条路径的Retained set。

注意：某个对象的Retained size可以理解为：回收这个对象之后，会回收Retained size这么多内存。某个对象的Retained set可以理解为：回收这个对象之后，被它引用且能被回收的对象的集合。某个路径上的Retained size，即为这个路径上的对象的Retained size之和。某个路径上的Retained set，即为这个路径上的对象的Retained set之和

Retained size的计算见：<android 如何分析应用的内存（十六）------使用AS查看Android堆>

注意注意：在上面的操作中，我故意放置了一个小小的漏洞。仔细观察图中，两个菱形的位置，一个在开头，一个在结尾。为了进行泄露点的逻辑分析dump heap和callstack，这两个棱形应该越靠近越好，因此，对上面的配置，调整如下：

shell 复制代码

adb shell perfetto \
  -c - --txt \
  -o /data/misc/perfetto-traces/trace \
<<EOF

buffers: {
    ## 将buffer增大1000倍，否则出现Perfetto ui解析出错
    size_kb: 63488000
    fill_policy: DISCARD
}
buffers: {
    size_kb: 2048
    fill_policy: DISCARD
}
data_sources: {
    config {
        name: "android.packages_list"
        target_buffer: 1
    }
}
data_sources: {
    config {
        name: "android.heapprofd"
        target_buffer: 0
        heapprofd_config {
            sampling_interval_bytes: 4096
            process_cmdline: "com.example.test_malloc"
            shmem_size_bytes: 8388608
            heaps: "com.android.art"
            continuous_dump_config {
                ## 10s之后，才开始第一次dump
                dump_phase_ms: 10000
                ## 每隔2s，dump一次
                dump_interval_ms: 10000
            }
        }
    }
}

data_sources: {
    config {
        name: "android.java_hprof"
        target_buffer: 0
        java_hprof_config {
            process_cmdline: "com.example.test_malloc"
            continuous_dump_config {
                ## 10s后，才开始第一次dump
                dump_phase_ms: 10000
                ## 每隔2s,dump一次
                dump_interval_ms: 10000
            }
        }
    }
}
## 总时间变成 30s
duration_ms: 30000

EOF

注意：这里dump heap时，需要先启动APP，再运行Perfetto。

得到的结果如下图：

调整时间轴，将两个重合的棱形，放大一点如下图：

图中，点击第二个棱形图标，出现从GC root的火焰图。

晴天霹雳！！！发现Perfetto在我的Pixel 3上面拉取出来的java heap dump并没有正确的计算引用链。导致我的火焰图，没有正确的反应内存泄露。经过深入分析，发现问题出现在Classloader和它加载的对象之间的引用链没有正确处理，导致了一些从GC root可达的对象，变成了不可达，即已经是泄露的对象，变成了没有泄露。

我们的目标是为了同时采集callstack和heap dump进行逻辑分析。因此我们可以忽略这种影响，直接操作数据库即可。

Heap dump的数据库表

java heap dump只会涉及到3张表：

heap_graph_reference：存储引用
heap_graph_object:存储对象
heap_graph_class:存储类

为了能够直观的展示这些表的结构。下面使用工具，将trace文件的数据库导出来，然后使用数据库UI工具进行查看

导出数据库

使用如下的命令进行数据库的导出。

shell 复制代码

./trace_processor /Users/biaowan/Documents/trace_single_conti -e  ~/Documents/trace_to_sqlite.db

本次实验，使用了DBeaver的社区版，进行数据库的查看。打开导出的数据库：trace_to_sqlite.db.如下图：

表说明

在真正使用之前，需要对表的各个列做一个说明：

heap_graph_reference

id 本引用唯一的id
type 本表名字，即heap_graph_reference
reference_set_id 引用对象集ID，如果这个引用是在某个对象中，那么在heap_graph_object中的reference_set_id和此值相等
owned_id 被引用的对象的id,即heap_graph_object的id
owner_id 使用这个引用的对象的id
field_name 这个引用的字段名
field_type_name 这个引用的字段的类型名
deobfuscated_field_name 反混淆之后的字段名

heap_graph_object

id 本对象的id
type 本表的名字
upid pid
graph_sample_ts 采样时间，即dump这个对象的时间
self_size 自身大小
native_size native大小
reference_set_id 本对象引用的其他对象的应用集id
reachable 从根对象是否可达，如果可达，则不可回收，否则，可回收(有bug)
type_id 本对象对应的class的id
root_type 如果不为空，则说明是根对象

heap_graph_class

id 本class的id
type 本表名字
name 本class的名字
deobfuscated_name 本class反混淆之后的名字
location 本class在什么地方
classloader_id classloader的id，这个id即为heap_graph_object的id
superclass_id 父类id，对应于本表的id
kind 类型

有了这些表的使用说明之后，我们就可以根据自己的需要使用SQL查询语句查看堆中的对象。

接下来，我们先简单的查看，在第二个heap dump中，哪些对象占据的内存空间最大。

查看第二个堆中的内存占用情况

注意：为什么要使用第二个堆？因为在我们的采集数据中，是从Perfetto开始运行的第十秒开始采集，然后再过十秒再次采集。而第一次采集的数据，因为callstack和heap时间间隔较大，所以不采用它。

选取正确的时间戳

使用SQL语句如下：

sql 复制代码

select * from heap_graph_object group by graph_sample_ts;

从图中，我们可以看到有三个时间段。分别对应于火焰图中的三个菱形。其余的菱形为callstack

我们要分析的就是第二个采样时间即：398831516584184

将对应时间戳的堆中对象，按照类进行分类，并统计其大小，倒序输出

sql 复制代码

select class.id,sum(object.self_size) as totalSize,class.name 
  from heap_graph_class as class inner join heap_graph_object as object
  on class.id=object.type_id 
  where object.graph_sample_ts=398831516584184
  group by class.id
  order by totalSize desc;

结果如下

图中可以看到最大的对象类型是int[]，其次为String。

注意:本次查询，即包括了能被回收的对象，也包括了不能回收的对象。因为Perfetto本身的错误，不能通过reachable字段来判断是否可回收。事实上，可以自己写一个脚本，递归处理classloader的引用关系，然后修改数据库中的reachable字段。不过我们的任务是为了找到泄漏对象和调用栈的关系。泄露对象其实已经明确了。即可以通过前面两篇的文章，来确定泄露的对象。见：

android 如何分析应用的内存（十七）------使用MAT查看Android堆:http://t.csdn.cn/c3BfM

android 如何分析应用的内存（十六）------使用AS查看Android堆:http://t.csdn.cn/xYGoA

如果仅仅是上面的查询结果，并不能简单的归因于内存泄露对象为int[],好在我们有AS和MAT工具可以辅助归因。随着Perfetto工具的完善(修复reachable字段的值)，仅用Perfetto也可以很好的找到内存泄露点。

又因为前两篇文章和本篇文章，都是使用的一个测试APP，所以，我们已经将内存泄漏点归因于int[]了。接下来就是将这个内存泄漏点与调用栈联系起来

将泄露对象与调用栈简单的联系起来

上面小节说明了泄露对象为int[],如果同一时间在调用栈中某个调用点执行的次数最多，或者在该调用点分配的对象最大，即可简单的将其进行逻辑联系起来。认为是该调用点导致的内存泄露。

我们点击离第二个堆最近的，棱形图标，如下图：

因为int[]占用了大量的空间，所以我们选择调用栈的total allocation size.如下

从图中，我们可以看到，doText()这个调用点，几乎占据了99%的分配大小。毫无疑问，int[]的泄露是这个doText()调用点导致的。但是这里面有两个doText(),分别占据约60%和约40%，可以肯定这两个调用点，都导致了内存的泄露。

然后查看其火焰图，可以找到整个调用栈和调用线程。

思考：一切看起来很简单，对吗？是否思考过一个问题------他们的时间点真的对的上吗？或者他们的时间点真的合理吗？

事实上：java的heap dump的数据，是从程序开始运行到dump点的堆中数据。而heapprofd中的数据(即这里的java调用栈)为Perfetto开始运行，到录制点之间的数据。画个图如下

解决办法：可能读者会想到将Perfetto在app启动之前启动，这样他们开始计算的时间点都是从app启动的时候开始了。然而，根据实测，要抓取java heap，必须先app启动，所以此种方法不可取。真正要解决这种问题，我们只需要再次进行一次录制，然后分别对callstack和heap进行差分比较即可。

用差分比较解决解决剩下难以定位的问题

用差分比较，可以排除，上述时间起始点不同步带来的干扰，同时还能排除，线程过多调用栈过杂带来的干扰。接下来看看使用步骤

重新录制更长时间段的内存数据和调用栈

将上面的配置文件的总时长更改为60s。然后重新录制，得如下图所示的情况

如上图我们采样了大约6组数据，现在我们选择第40s和第50s的两组进行差分比较分析。当然也可以选择其他组进行比较。

差分分析两个堆中查看增加内容最多的数据

先找出两者之间的时间。如下

sql 复制代码

select * from heap_graph_object group by graph_sample_ts;

根据结果我们选择上图的两个时间，分别为：462051768285433和462061780815388

将两个时间上的堆做减法，留下40s到50s中增加的对象。
为了对两个表有一个感性的认知，可以执行下面的指令，进行查看

sql 复制代码

select class.id,object.graph_sample_ts,
    sum(object.self_size) as totalSize,class.name 
  from heap_graph_class as class inner join heap_graph_object as object
  on class.id=object.type_id 
  where object.graph_sample_ts=462051768285433 or 
     object.graph_sample_ts=462061780815388
  group by class.id
  order by totalSize desc;

从图中可以看到，不同时间段上对象的大小之和。

接下来，将50s和40s之间的堆，进行相减，如下：

sql 复制代码

select t2.totalSize - COALESCE(t1.totalSize,0) as diff,t2.name
from (
   select class.id,object.graph_sample_ts,
      sum(object.self_size) as totalSize,class.name 
   from heap_graph_class as class inner join heap_graph_object as object
   on class.id=object.type_id 
   where object.graph_sample_ts=462061780815388
   group by class.id,object.graph_sample_ts
   order by totalSize desc
) as t2 left join (
   select class.id,object.graph_sample_ts,
      sum(object.self_size) as totalSize,class.name 
   from heap_graph_class as class inner join heap_graph_object as object
   on class.id=object.type_id 
   where object.graph_sample_ts=462051768285433
   group by class.id,object.graph_sample_ts
   order by totalSize desc
) as t1 on t2.name = t1.name
order by diff desc

为了更好的计算它们所占的百分比，我在这里求总和之后，直接写入插入语句中，如下：

sql 复制代码

select (t2.totalSize - COALESCE(t1.totalSize,0))/2119766.0 
   as percentage,t2.totalSize - COALESCE(t1.totalSize,0) as diff,t2.name
from (
   select class.id,object.graph_sample_ts,
      sum(object.self_size) as totalSize,class.name 
   from heap_graph_class as class inner join heap_graph_object as object
   on class.id=object.type_id 
   where object.graph_sample_ts=462061780815388
   group by class.id,object.graph_sample_ts
   order by totalSize desc
) as t2 left join (
   select class.id,object.graph_sample_ts,
      sum(object.self_size) as totalSize,class.name 
   from heap_graph_class as class inner join heap_graph_object as object
   on class.id=object.type_id 
   where object.graph_sample_ts=462051768285433
   group by class.id,object.graph_sample_ts
   order by totalSize desc
) as t1 on t2.name = t1.name
order by percentage desc

如下图

从图中我们看到了97%的对象为int[]，接下来只要比较40s到50s之间，什么样的调用点被调用的次数最多，或者该调用点分配的内存最多，那么这个调用点大概率就是产生这97%的int[]的地方

差分分析同时间段的调用栈

在介绍如何查看调用栈的差分之前，我们需要知道跟调用栈相关的数据库中的表，分别有下面三张表：

heap_profile_allocation:存储分配
stack_profile_frame:存储栈帧名
stack_profile_callsite:存储调用点

当然除了上面三个表以外，还有其他的表，但是对于我们的分析关系不大，故不在啰嗦，查看所有表的信息可参阅：https://perfetto.dev/docs/analysis/sql-tables

调用栈表说明

heap_profile_allocation

id 唯一id
type 本表名
ts 采样时间
upid pid
heap_name 堆名字
callsite_id 调用点id，即stack_profile_callsite的di
count 分配的次数,正数就是该调用点的分配次数，负数就是该调用点的释放次数
size 分配的大小,同样有正负之分，正数表示分配大小，负数表示释放大小

stack_profile_frame

id 唯一id
type 本表名
name 函数名
mapping 该函数映射到哪一个库，如so，.dex 即stack_profile_mapping的id
rel_pc 相对于映射库的pc值
symbol_set_id 该函数名对应的符号表的id，即stack_profile_symbol的id
deobfuscated_name 反混淆之后的名字

stack_profile_callsite

id 唯一id
type 本表名
depth 到调用栈顶部的距离，多一个函数，则深度加一
parent_id 本调用点的父函数的调用点id。即stack_profile_callsite的id
frame_id 帧id，即stack_profile_frame的id

查看各个采样时间

使用如下的命令查看。

sql 复制代码

select *,sum(count) as totalCount ,sum (size) as totalSize 
from heap_profile_allocation group by ts;

从图中可以看到，整个数据被分成了6个时间段，刚好对应于火焰图的六菱形。在火焰图中，每个棱形表示的是从开始抓取到棱形位置对应时间的所有分配。

然而数据库中的每个时间点，表示的是从上一个时间点到本次抓取的所有数据，因此查看40s到50s之间的数据，只需要看第50s的数据即可。也就是倒数第二行。

查看40s和50s的调用详细情况

为了便于理解，下面的语句，将40s和50s的两个堆都列出来分析。如下

sql 复制代码

select * 
from (
   select * 
   from heap_profile_allocation 
   where ts = 462061299971174 
   order by count desc
) as t1
union all 
select * 
from (
   select * 
   from heap_profile_allocation 
   where ts = 462071449972185 
   order by count desc
) as t2

上图列出了30-40区间的情况，以及40-50区间的情况，稍微计算下各个调用点分配的内存占比，可以知道：701调用点的内存分配占据了40s到50s所有分配的82% 因此我们可以大胆的下结论------40s到50s之间的内存泄露由701分配点导致。

查看701分配点的调用栈

使用下面的递归语句，查看整个701的调用栈，如下

sql 复制代码

WITH RECURSIVE RecursiveCTE AS (
    SELECT id, parent_id,frame_id
    FROM stack_profile_callsite
    WHERE id = 701
    UNION ALL
    SELECT origin.id, origin.parent_id,origin.frame_id
    FROM stack_profile_callsite origin
    JOIN RecursiveCTE r ON r.parent_id = origin.id
)
SELECT result.id,result.parent_id,frame.name 
FROM RecursiveCTE as result inner join stack_profile_frame as frame 
   on frame.id=result.frame_id 
order by result.id desc;

如下图

直接观察即可看到40s至50s之间泄露对象int[]由上图的调用栈产生泄露。

注意，使用同样的分析方法，查看调用点518，依然会得出相同的结论，不过他们发生在30s至40s之间。同样的操作步骤，不再继续举例

至此，使用perfetto进行内存分析，已经介绍完毕。

内存方法大总结

万事大吉，关于Android的内存分析已经介绍完毕。现在对前面的所有文章进行一个总结：

native篇

第零个工具xdd:只能查看任意内存
第一个工具gdb:它可以查看：寄存器，和任意位置的内存，分析coredump，能查看栈情况，不能查看堆情况
第二个工具lldb：它可以查看：寄存器，和任意位置的内存，分析coredump，能查看栈情况，不能查看堆情况
第三个工具自定义malloc:只能查看堆情况，且查看的范围较小，几乎只有自己编译的代码
第四个工具malloc hook:能查看所有的堆分配情况
第五个工具malloc统计和libmemunreachable：可以查看所有堆分配情况
第六个工具malloc debug和libc回调:能查看所有堆分配情况
第七个工具ASan/HWASan:只能查看linux的堆分配情况，无法查找android的分配情况，列在此处只是为了知识的完整性
第八个工具perfetto:只能查看堆内存分配情况

java篇

第零个工具jdb:查看堆帧，本地变量，锁，对象
第一个工具java debugger for vscode:查看堆栈，本地变量，对象
第二个工具Android studio:查看堆，对象引用，Retained size，调用栈
第三个工具MAT：查看堆，对象引用，Retained size ,还能进行堆间差分分析
第四个工具Perfetto：查看堆，对象引用，Retained size，调用栈，还能在堆和调用栈之间进行差分分析

本系列完。

android 如何分析应用的内存（十八）终章——使用Perfetto查看内存与调用栈之间的泄露

android 如何分析应用的内存（十八）

Perfetto同时录制堆栈和heap dump

分析结果

Heap dump的数据库表

导出数据库

表说明

查看第二个堆中的内存占用情况

选取正确的时间戳

将对应时间戳的堆中对象，按照类进行分类，并统计其大小，倒序输出

将泄露对象与调用栈简单的联系起来

用差分比较解决解决剩下难以定位的问题

重新录制更长时间段的内存数据和调用栈

差分分析两个堆中查看增加内容最多的数据

差分分析同时间段的调用栈

调用栈表说明

查看各个采样时间

查看40s和50s的调用详细情况

查看701分配点的调用栈

内存方法大总结

native篇

java篇