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。

adb shell perfetto \-c - --txt \-o /data/misc/perfetto-traces/trace \
<<EOFbuffers: {size_kb: 63488fill_policy: DISCARD
}
buffers: {size_kb: 2048fill_policy: DISCARD
}
data_sources: {config {name: "android.packages_list"target_buffer: 1}
}
data_sources: {config {name: "android.heapprofd"target_buffer: 0heapprofd_config {sampling_interval_bytes: 4096process_cmdline: "com.example.test_malloc"shmem_size_bytes: 8388608block_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: 60000EOF

在上面的命令中，我们新增了一个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，这两个棱形应该越靠近越好，因此，对上面的配置，调整如下：

adb shell perfetto \-c - --txt \-o /data/misc/perfetto-traces/trace \
<<EOFbuffers: {## 将buffer增大1000倍，否则出现Perfetto ui解析出错size_kb: 63488000fill_policy: DISCARD
}
buffers: {size_kb: 2048fill_policy: DISCARD
}
data_sources: {config {name: "android.packages_list"target_buffer: 1}
}
data_sources: {config {name: "android.heapprofd"target_buffer: 0heapprofd_config {sampling_interval_bytes: 4096process_cmdline: "com.example.test_malloc"shmem_size_bytes: 8388608heaps: "com.android.art"continuous_dump_config {## 10s之后，才开始第一次dumpdump_phase_ms: 10000## 每隔2s，dump一次dump_interval_ms: 10000}}}
}data_sources: {config {name: "android.java_hprof"target_buffer: 0java_hprof_config {process_cmdline: "com.example.test_malloc"continuous_dump_config {## 10s后，才开始第一次dumpdump_phase_ms: 10000## 每隔2s,dump一次dump_interval_ms: 10000}}}
}
## 总时间变成 30s
duration_ms: 30000EOF

注意：这里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工具进行查看

导出数据库

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

./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语句如下：

select * from heap_graph_object group by graph_sample_ts;

在这里插入图片描述

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

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

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

select class.id,sum(object.self_size) as totalSize,class.name from heap_graph_class as class inner join heap_graph_object as objecton class.id=object.type_id where object.graph_sample_ts=398831516584184group by class.idorder 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的两组进行差分比较分析。当然也可以选择其他组进行比较。

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

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

select * from heap_graph_object group by graph_sample_ts;

在这里插入图片描述

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

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

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 objecton class.id=object.type_id where object.graph_sample_ts=462051768285433 or object.graph_sample_ts=462061780815388group by class.idorder by totalSize desc;

在这里插入图片描述

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

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

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 objecton class.id=object.type_id where object.graph_sample_ts=462061780815388group by class.id,object.graph_sample_tsorder 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 objecton class.id=object.type_id where object.graph_sample_ts=462051768285433group by class.id,object.graph_sample_tsorder by totalSize desc
) as t1 on t2.name = t1.name
order by diff desc

在这里插入图片描述

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

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 objecton class.id=object.type_id where object.graph_sample_ts=462061780815388group by class.id,object.graph_sample_tsorder 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 objecton class.id=object.type_id where object.graph_sample_ts=462051768285433group by class.id,object.graph_sample_tsorder 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

查看各个采样时间

使用如下的命令查看。

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

在这里插入图片描述

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

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

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

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

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的调用栈，如下

WITH RECURSIVE RecursiveCTE AS (SELECT id, parent_id,frame_idFROM stack_profile_callsiteWHERE id = 701UNION ALLSELECT origin.id, origin.parent_id,origin.frame_idFROM stack_profile_callsite originJOIN 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;