如何使用DevEco Studio性能调优工具Profiler定位应用内存问题

正文

请到「今天看啥」查看全文

定位内存问题

从1.2节中的分析可知，当前应用内存的增长主要集中在FilePage Other/Native Heap/ArkTS Heap这三个部分，那么需要使用进一步的分析方法对这三个方面的内存进行分析，定位内存上涨的根因。

在分析鸿蒙应用的内存问题时，可以将鸿蒙应用的内存大体分为两部分，方舟虚拟机内存和Native内存：

1. 方舟虚拟机内存：由方舟虚拟机管控的应用内存，同其他的虚拟机内存（例如Java）管理策略相似，开发者可以使用并操控的内存基本集中于虚拟机堆上，在方舟虚拟机上被称作ArkTS Heap，这部分内存受到方舟虚拟机的管控。

2. Native内存：这部分内存主要是应用使用到的一些涉及Native的API所申请的内存以及开发者自己的Native代码所申请使用的堆内存（通常是C/C++），这部分内存需要开发者自己去管理申请和释放。

因为两种内存的使用方式和管理方式不尽相同，因此在对这两类内存的分析过程中所使用的方法也有比较大的区别，下面将从这两个方面分别介绍分析方法。

2.1 ArkTS内存问题

2.1.1 ArkTS内存管理

首先针对ArkTS Heap，由于该部分堆内存受到方舟虚拟机的管理，可以对堆内存进行垃圾回收（Garbage Collect，GC）和拍摄快照（HeapSnapshot或HeapDump，简称dump）以反映出瞬时的全量堆内存使用及分布情况，因此这部分内存的问题分析手段主要是对堆dump进行引用关系分析，分析泄漏对象无法被GC回收的原因。

不同于引用计数算法，方舟虚拟机采用可达性分析的机制来管理对象是否可被垃圾收集器回收，因此针对方舟虚拟机内存的分析方法主要集中于对象的引用分析，即分析哪些对象引用关系是错误的或者异常的，从而导致了泄漏对象被长时间持有无法被GC，最终通过解除强引用关系的手段来解决内存泄露问题。如下图1所示，蓝色的对象节点表示在内存引用分析中该对象GC Root引用可达，其余对象GC Root引用不可达，引用不可达的对象在GC中可以被虚拟机回收。

图1 对象可达性分析

2.1.2 ArkTS Heap分析

针对虚拟机的内存问题分析通常都集中在对dump的对象分布及引用关系的分析上，方舟虚拟机也不例外，这里在DevEco Profiler上提供了Snapshot Insight来对方舟虚拟机的堆内存进行分析。

在使用Snapshot分析时，通常会使用三快照技术（Three Snapshot Technique），通过内存快照的对比视图将某两次快照之间分配且仍然驻留的内存筛选出来，这些对象中的一部分就可能是导致内存泄漏的对象。通用的流程为：

打开应用，初始化场景 (触发GC)-> 拍摄第一次Snapshot作为基准 -> 多（N）次触发内存泄漏操作 -> 拍摄第二次堆快照 -> 触发主动GC -> 拍摄第三次堆快照

由于方舟虚拟机提供了在获取堆快照之前自动GC的功能，因此我们可以将上述流程简化为两步，同时加上Profiler的录制功能，整体流程为：

打开应用，初始化场景 -> 开启录制Snapshot Insight-> 拍摄第一次Snapshot作为基准 -> 多（N）次触发内存泄漏操作 -> 拍摄第二次堆快照 -> 结束录制

录制完成后，会得到如下图所示的数据

录制过程中，我们采集了两次堆快照，对应在Profiler的界面上就是两个紫色的条块，每一个条块内的数据都是当前的虚拟机堆快照。 条块上的数字大小代表的是虚拟机堆内存的实际占用。

由于在每次拍摄堆快照之前，虚拟机都会触发GC，所以理论上堆快照内存在的对象都是当前虚拟机已经无法GC掉的对象，所以我们可以将两个堆快照进行比较，来查看哪些对象是我们在触发问题场景时新增了且不能释放的。

点击Snapshot Insight面板的Comparison页签，将两次Snapshot进行比较，如下图。图中数据的含义为以Snapshot2作为基准，Snapshot2对比Snapshot1的数据变化量。

即便是比较视图，东西也非常多，怎么分析呢？

还记得上面说的操作 N次 吗，在触发内存问题场景时将问题触发N次，在比较视图中首先就去找与N强相关、与业务代码强相关的constructor，首先来分析这些对象是否正常。

首先介绍一下Snapshot比较视图中各项数据的含义，如下图，更加具体的也可以参考 内存泄露分析 或者

请到「今天看啥」查看全文