在使用Android Studio进行内存泄露分析之前,我们先回顾一下Java相关的内存管理机制,然后再讲述一下内存分析工具如何使用。

一、Java内存管理机制

1. Java内存分配策略

Java 程序运行时的内存分配策略有三种:静态分配、栈式分配和堆式分配。

对应的存储区域如下:

  • 静态存储区(方法区):主要存放静态数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好,并且在程序整个运行期间都存在。
  • 栈区 :方法体内的局部变量都在栈上创建,并在方法执行结束时这些局部变量所持有的内存将会自动被释放。
  • 堆区 : 又称动态内存分配,通常就是指在程序运行时直接 new 出来的内存。这部分内存在不使用时将会由 Java 垃圾回收器来负责回收。

2. 堆与栈的区别

栈内存:在方法体内定义的局部变量(一些基本类型的变量和对象的引用变量)都是在方法的栈内存中分配的。当在一段方法块中定义一个变量时,Java 就会在栈中为该变量分配内存空间,当超过该变量的作用域后,分配给它的内存空间也将被释放掉,该内存空间可以被重新使用。

堆内存:用来存放所有由 new 创建的对象(包括该对象其中的所有成员变量)和数组。在堆中分配的内存,将由 Java 垃圾回收器来自动管理。在堆中产生了一个数组或者对象后,还可以在栈中定义一个特殊的变量,这个变量的取值等于数组或者对象在堆内存中的首地址,这个特殊的变量就是我们上面说的引用变量。我们可以通过这个引用变量来访问堆中的对象或者数组。

3. Java管理内存的机制

Java的内存管理就是对象的分配和释放问题。内存的分配是由程序员来完成,内存的释放由GC(垃圾回收机制)完成。GC 为了能够正确释放对象,必须监控每一个对象的运行状态,包括对象的申请、引用、被引用、赋值等。这是Java程序运行较慢的原因之一。

1). 释放对象的原则:

该对象不再被引用。

2). GC的工作原理:

将对象考虑为有向图的顶点,将引用关系考虑为有向图的有向边,有向边从引用者指向被引对象。另外,每个线程对象可以作为一个图的起始顶点,例如大多程序从 main 进程开始执行,那么该图就是以 main 进程为顶点开始的一棵根树。在有向图中,根顶点可达的对象都是有效对象,GC将不回收这些对象。如果某个对象与这个根顶点不可达,那么我们认为这个对象不再被引用,可以被 GC 回收。

另外,Java使用有向图的方式进行内存管理,可以消除引用循环的问题,例如有三个对象相互引用,但只要它们和根进程不可达,那么GC也是可以回收它们的。当然,除了有向图的方式,还有一些别的内存管理技术,不同的内存管理技术各有优缺点,在这里就不详细展开了。

3). Java中的内存泄漏

如果一个对象满足以下两个条件:

(1)这些对象是可达的,即在有向图中,存在通路可以与其相连

(2)这些对象是无用的,即程序以后不会再使用这些对象

就可以判定为Java中的内存泄漏,这些对象不会被GC所回收,继续占用着内存。

在C++中,内存泄漏的范围更大一些。有些对象被分配了内存空间,然后却不可达,由于C++中没有GC,这些内存将永远收不回来。在Java中,这些不可达的对象都由GC负责回收。

内存泄漏

二、Android中的内存泄漏

1. 单例造成的内存泄漏

在Android开发中,常见的单例问题造成内存泄漏的场景如下:

当创建这个单例的时候,由于需要传入一个Context,所以这个Context的生命周期的长短至关重要:

1.如果此时传入的是 Application 的 Context,因为 Application 的生命周期就是整个应用的生命周期,所以没有任何问题。

2.如果此时传入的是 Activity 的 Context,当这个 Context 所对应的 Activity 退出时,由于该 Context 的引用被单例对象所持有,其生命周期等于整个应用程序的生命周期,所以当前 Activity 退出时它的内存并不会被回收,这就造成泄漏了。

当然,Application 的 context 不是万能的,所以也不能随便乱用,例如Dialog必须使用 Activity 的 Context。

2. 非静态内部类创建静态实例造成的内存泄漏

非静态内部类默认会持有外部类的引用,而该非静态内部类又创建了一个静态的实例,该实例的生命周期和应用的一样长,这就导致了该静态实例一直会持有该Activity的引用,导致Activity的内存资源不能正常回收。

3. 匿名内部类造成的内存泄漏

匿名内部类默认也会持有外部类的引用。

如果在Activity/Fragment中使用了匿名类,并被异步线程持有,如果没有任何措施这样一定会导致泄漏。

例子:Handler造成的内存泄漏。

修复方法:在 Activity 中避免使用非静态内部类或匿名内部类,比如将 Handler 声明为静态的,则其存活期跟 Activity 的生命周期就无关了。如果需要用到Activity,就通过弱引用的方式引入 Activity,避免直接将 Activity 作为 context 传进去。另外, Looper 线程的消息队列中还是可能会有待处理的消息,所以我们在 Activity 的 Destroy 时或者 Stop 时应该移除消息队列 MessageQueue 中的消息。

代码示例如图:

代码示例

4. 资源未关闭造成的内存泄漏

对于使用了BraodcastReceiver,ContentObserver,File, Cursor,Stream,Bitmap等资源的使用,应该在Activity销毁时及时关闭或者注销,否则这些资源将不会被回收,造成内存泄漏。

5. 不良代码造成的内存使用压力

有些代码并不造成内存泄漏,但是它们,或是对没使用的内存没进行有效及时的释放,或是没有有效的利用已有的对象而是频繁的申请新内存。比如,Adapter里没有复用convertView等。

三、使用Android Studio的Memory Profiler来分析内存泄漏情况

Memory Profiler 是 Android Profiler中的一个组件,可帮助识别可能会导致应用卡顿、冻结甚至崩溃的内存泄露和内存抖动。它显示一个应用内存使用量的实时图表,可以捕获堆转储、强制执行垃圾回收以及跟踪内存分配。

要打开 Memory Profiler,请按以下步骤操作:

  1. 依次点击 View > Tool Windows > Profiler(您也可以点击工具栏中的 Profile 图标 )。
  2. 从 Android Profiler 工具栏中选择要分析的设备和应用进程。如果已通过 USB 连接设备但系统未列出该设备,请确保已启用 USB 调试。
  3. 点击 MEMORY 时间轴上的任意位置以打开 Memory Profiler。

或者,可以从命令行使用 dumpsys来检查应用内存,还可以在 logcat 中查看 GC 事件。

为什么应分析您的应用内存

Android 提供了托管内存环境 - 当它确定您的应用不再使用某些对象时,垃圾回收器会将未使用的内存释放回堆中。虽然 Android 查找未使用内存的方式在不断改进,但对于所有 Android 版本,系统都必须在某个时间点短暂地暂停您的代码。大多数情况下,这些暂停难以察觉。不过,如果您的应用分配内存的速度比系统回收内存的速度快,则当回收器释放足够的内存以满足您的分配需要时,您的应用可能会延迟。此延迟可能会导致您的应用跳帧,并使系统明显变慢。

尽管您的应用不会表现出变慢,但如果存在内存泄露,则即使应用在后台运行也会保留该内存。此行为会强制执行不必要的垃圾回收事件,因而拖慢系统其余部分的内存性能。最后,系统被迫终止您的应用进程以回收内存。然后,当用户返回您的应用时,它必须完全重启。

为帮助防止这些问题,您应使用 Memory Profiler 执行以下操作:

  • 在时间轴上查找可能会导致性能问题的不理想的内存分配模式。
  • 转储 Java 堆以查看在任何给定时间哪些对象耗尽了内存。在很长一段时间内进行多次堆转储有助于识别内存泄露。
  • 记录正常用户交互和极端用户交互期间的内存分配,以准确识别您的代码在何处短时间内分配了过多对象,或分配了泄露的对象。

Memory Profiler 概览

先看一下Android Studio 的 Memory Profiler界面:

memory-profiler

如图1所示,Memory Profiler 的默认视图包括以下各项:

  1. 用于强制执行垃圾回收事件的按钮。
  2. 用于捕获堆转储的按钮。注意:只有在连接到搭载 Android 7.1(API 级别 25)或更低版本的设备时,才会在堆转储按钮右侧显示用于记录内存分配的按钮。
  3. 用于指定分析器多久捕获一次内存分配的下拉菜单。选择适当的选项可帮助您在分析时提高应用性能。
  4. 用于缩放时间轴的按钮。
  5. 用于跳转到实时内存数据的按钮。
  6. 事件时间轴,显示活动状态、用户输入事件和屏幕旋转事件。
  7. 内存使用量时间轴,它会显示以下内容:
    • 一个堆叠图表,显示每个内存类别当前使用多少内存,如左侧的 y 轴以及顶部的彩色键所示。
    • 一条虚线,表示分配的对象数,如右侧的 y 轴所示。
    • 每个垃圾回收事件的图标。

如果您使用的是搭载 Android 7.1 或更低版本的设备,则并非所有分析数据在默认情况下都可见。如果您看到一条消息,显示“Advanced profiling is unavailable for the selected process”,您需要启用高级分析才能看到以下内容:

  • 事件时间轴
  • 分配的对象数
  • 垃圾回收事件

在 Android 8.0 及更高版本上,始终为可调试应用启用高级分析。

如何计算内存

您在 Memory Profiler 顶部看到的数字,基于您的应用根据 Android 系统机制所提交的所有私有内存页面。此计数不包含与系统或其他应用共享的页面。

内存计数中的类别

图2.内存计数中的类别如下:

  • Java:从 Java 或 Kotlin 代码分配的对象的内存。

  • Native:从 C 或 C++ 代码分配的对象的内存。

    即使您的应用中不使用 C++,您也可能会看到此处使用的一些原生内存,因为 Android 框架使用原生内存代表您处理各种任务,如处理图像资源和其他图形时,即使您编写的代码采用 Java 或 Kotlin 语言。

  • Graphics:图形缓冲区队列向屏幕显示像素(包括 GL 表面、GL 纹理等等)所使用的内存。(请注意,这是与 CPU 共享的内存,不是 GPU 专用内存。)

  • Stack:您的应用中的原生堆栈和 Java 堆栈使用的内存。这通常与您的应用运行多少线程有关。

  • Code:您的应用用于处理代码和资源(如 dex 字节码、经过优化或编译的 dex 代码、.so 库和字体)的内存。

  • Others:您的应用使用的系统不确定如何分类的内存。

  • Allocated:您的应用分配的 Java/Kotlin 对象数。此数字没有计入 C 或 C++ 中分配的对象。

    如果连接到搭载 Android 7.1 及更低版本的设备,只有在 Memory Profiler 连接到您运行的应用时,才开始此分配计数。因此,您开始分析之前分配的任何对象都不会被计入。不过,Android 8.0 及更高版本附带一个设备内置分析工具,该工具可跟踪所有分配,因此,在 Android 8.0 及更高版本上,此数字始终表示您的应用中待处理的 Java 对象总数。

与以前的 Android Monitor 工具中的内存计数相比,新的 Memory Profiler 以不同的方式记录您的内存,因此,您的内存使用量现在看上去可能会更高些。Memory Profiler 会监控一些额外的类别,这就增加了总的内存使用量,但如果您仅关心 Java 堆内存,则“Java”项的数字应与以前工具中的数值相似。 然而,Java 数字可能与您在 Android Monitor 中看到的数字并非完全相同,这是因为新数字计入了自应用的 Java 堆从 Zygote 派生以来为其分配的所有物理内存页面。因此,它可以准确反映您的应用实际使用了多少物理内存。

查看内存分配

内存分配为您显示内存中的每个 Java 对象和 JNI 引用是如何分配的。具体而言,Memory Profiler 可为您显示有关对象分配的以下信息:

  • 分配了哪些类型的对象以及它们使用多少空间。
  • 每个分配的堆栈轨迹,包括在哪个线程中。
  • 对象在何时被取消分配(仅当使用搭载 Android 8.0 或更高版本的设备时)。

如果您的设备搭载的是 Android 8.0 或更高版本,您可以随时查看对象分配,具体操作步骤如下:在时间轴上拖动以选择要查看哪个区域的分配(如视频 1 中所示)。不需要开始记录会话,因为 Android 8.0 及更高版本附带设备内置分析工具,可持续跟踪您的应用分配。

视频 1. 对于 Android 8.0 及更高版本,选择一个现有时间轴区域以查看对象分配

如果您的设备搭载的是 Android 7.1 或更低版本,请点击 Memory Profiler 工具栏中的 Record memory allocations 图标。记录时,Memory Profiler 会跟踪您的应用中发生的所有分配。完成后,请点击 Stop recording 图标 (同一按钮,请观看视频 2)以查看分配。

视频 2. 对于 Android 7.1 及更低版本,您必须明确记录内存分配

选择时间轴的某个区域后(或者使用搭载 Android 7.1 或更低版本的设备完成记录会话后),已分配对象的列表将显示在时间轴下方,按类名称进行分组,并按其堆计数排序。

注意:在 Android 7.1 及更低版本上,您最多可以记录 65535 个分配。 如果您的记录会话超出此限制,则记录中仅保存最新的 65535 个分配。(在 Android 8.0 及更高版本上,则没有实际的限制。)

要检查分配记录,请按以下步骤操作:

  1. 浏览列表以查找堆计数异常大且可能存在泄露的对象。为帮助查找已知类,点击Class Name列标题以按字母顺序排序。然后,点击一个类名称。此时右侧将出现Instance View窗格,显示该类的每个实例,如图 3 所示。
    • 此外,您也可以快速找到对象,方法是点击 Filter 图标 ,或按 Ctrl+F 键(在 Mac 上,按 Command+F 键),然后在搜索字段中输入类或软件包名称。如果从下拉菜单中选择 Arrange by callstack,还可以按方法名称搜索。如果要使用正则表达式,请勾选 Regex 旁边的复选框。如果您的搜索查询区分大小写,请勾选 Match case 旁边的复选框。
  2. Instance View 窗格中,点击一个实例。此时下方将出现 Call Stack 标签页,显示该实例被分配到何处以及在哪个线程中。
  3. Call Stack 标签页中,右键点击任意行并选择 Jump to Source,以在编辑器中打开该代码。

有关每个已分配对象的详细信息

图 3. 有关每个已分配对象的详细信息显示在右侧的 Instance View

您可以使用已分配对象列表上方的两个菜单来选择要检查的堆以及如何组织数据。

从左侧的菜单中,选择要检查的堆:

  • default heap:当系统未指定堆时。
  • image heap:系统启动映像,包含启动期间预加载的类。此处的分配保证绝不会移动或消失。
  • zygote heap:写时复制堆,其中的应用进程是从 Android 系统中派生的。
  • app heap:您的应用在其中分配内存的主堆。
  • JNI heap:显示 Java 原生接口 (JNI) 引用被分配和释放到什么位置的堆。

从右侧的菜单中,选择如何安排分配:

  • Arrange by class:根据类名称对所有分配进行分组。这是默认选项。
  • Arrange by package:根据软件包名称对所有分配进行分组。
  • Arrange by callstack:将所有分配分组到其对应的调用堆栈。

在分析时提高应用性能

为了在分析时提高应用性能,Memory Profiler 在默认情况下会定期对内存分配进行采样。在运行 API 级别 26 或更高级别的设备上进行测试时,您可以使用 Allocation Tracking 下拉菜单来更改此行为。可用选项如下:

  • Full:捕获内存中的所有对象分配。这是 Android Studio 3.2 及更低版本中的默认行为。如果您有一个分配了大量对象的应用,则可能会在分析时观察到应用的运行速度明显减慢。
  • Sampled:定期对内存中的对象分配进行采样。这是默认选项,在分析时对应用性能的影响较小。在短时间内分配大量对象的应用仍可能会表现出明显的速度减慢。
  • Off:停止跟踪应用的内存分配。

注意:默认情况下,Android Studio 会在执行 CPU 记录时停止跟踪实时分配,并在 CPU 记录完成后重新开启该功能。 您可以在 CPU 记录配置对话框中更改此行为。

查看全局 JNI 引用

Java 原生接口 (JNI) 是一个允许 Java 代码和原生代码相互调用的框架。

JNI 引用由原生代码进行管理,因此原生代码使用的 Java 对象可能会保持活动状态太长时间。如果丢弃了 JNI 引用而未先明确将其删除,Java 堆上的某些对象可能会变得无法访问。此外,还可能会达到全局 JNI 引用限制。

要排查此类问题,请使用 Memory Profiler 中的 JNI heap 视图来浏览所有全局 JNI 引用,并按 Java 类型和原生调用堆栈对其进行过滤。借助此信息,您可以了解创建和删除全局 JNI 引用的时间和位置。

在您的应用运行时,选择您要检查的一部分时间轴,然后从类列表上方的下拉菜单中选择 JNI heap。 您随后可以像往常一样检查堆中的对象,还可以双击 Allocation Call Stack 标签页中的对象,以查看在代码中将 JNI 引用分配和释放到了什么位置,如图 4 所示。

查看全局 JNI 引用

图 4. 查看全局 JNI 引用

要检查应用的 JNI 代码的内存分配,您必须将应用部署到搭载 Android 8.0 或更高版本的设备上。

如需详细了解 JNI,请参阅 JNI 提示

捕获堆转储

堆转储显示在您捕获堆转储时您的应用中哪些对象正在使用内存。特别是在长时间的用户会话后,堆转储会显示您认为不应再位于内存中却仍在内存中的对象,从而帮助识别内存泄露。

捕获堆转储后,您可以查看以下信息:

  • 您的应用分配了哪些类型的对象,以及每种对象有多少。
  • 每个对象当前使用多少内存。
  • 在代码中的什么位置保持着对每个对象的引用。
  • 对象所分配到的调用堆栈。(目前,对于 Android 7.1 及更低版本,只有在记录分配期间捕获堆转储时,才会显示调用堆栈的堆转储。)

要捕获堆转储,请点击 Memory Profiler 工具栏中的 Dump Java heap 图标 。 在转储堆期间,Java 内存量可能会暂时增加。 这很正常,因为堆转储与您的应用发生在同一进程中,并需要一些内存来收集数据。

堆转储出现在内存时间轴下方,显示堆中的所有类类型,如图 5 所示。

查看堆转储

图 5. 查看堆转储

如果您需要更确切地了解转储的创建时间,可以通过调用 dumpHprofData() 在应用代码的关键点创建堆转储。

在类列表中,您可以查看以下信息:

  • Allocations:堆中的分配数。

  • Native Size:此对象类型使用的原生内存总量(以字节为单位)。只有在使用 Android 7.0 及更高版本时,才会看到此列。

    您会在此处看到采用 Java 分配的某些对象的内存,因为 Android 对某些框架类(如 Bitmap)使用原生内存。

  • Shallow Size:此对象类型使用的 Java 内存总量(以字节为单位)。

  • Retained Size:为此类的所有实例而保留的内存总大小(以字节为单位)。

您可以使用已分配对象列表上方的两个菜单来选择要检查的堆转储以及如何组织数据。

从左侧的菜单中,选择要检查的堆:

  • default heap:当系统未指定堆时。
  • app heap:您的应用在其中分配内存的主堆。
  • image heap:系统启动映像,包含启动期间预加载的类。此处的分配保证绝不会移动或消失。
  • zygote heap:写时复制堆,其中的应用进程是从 Android 系统中派生的。

从右侧的菜单中,选择如何安排分配:

  • Arrange by class:根据类名称对所有分配进行分组。这是默认选项。
  • Arrange by package:根据软件包名称对所有分配进行分组。
  • Arrange by callstack:将所有分配分组到其对应的调用堆栈。只有在记录分配期间捕获堆转储时,此选项才有效。即便如此,堆中也很可能有在您开始记录之前分配的对象,所以会先显示这些分配,直接按类名称列出它们。

默认情况下,此列表按 Retained Size 列排序。要按其他列中的值排序,请点击该列的标题。

点击一个类名称可在右侧打开 Instance View 窗口(如图 6 所示)。列出的每个实例都包含以下信息:

  • Depth:从任意 GC 根到选定实例的最短跳数。
  • Native Size:原生内存中此实例的大小。 只有在使用 Android 7.0 及更高版本时,才会看到此列。
  • Shallow Size:Java 内存中此实例的大小。
  • Retained Size:此实例所支配内存的大小。

注意:默认情况下,堆转储不会向您显示每个已分配对象的堆栈轨迹。要获取堆栈轨迹,在点击 Dump Java heap 之前,您必须先开始记录内存分配。然后,您可以在 Instance View 中选择一个实例,并查看 References 标签页旁边的 Call Stack 标签页,如图 6 所示。不过,在您开始记录分配之前,可能已分配一些对象,因此不会显示这些对象的调用堆栈。包含调用堆栈的实例在图标上用一个“堆栈”标志表示。(遗憾的是,由于堆栈轨迹需要您执行分配记录,因此您目前无法在 Android 8.0 上查看堆转储的堆栈轨迹。)

在时间轴上标示捕获堆转储所需的持续时间

图 6. 在时间轴上标示捕获堆转储所需的持续时间

要检查您的堆,请按以下步骤操作:

  1. 浏览列表以查找堆计数异常大且可能存在泄露的对象。为帮助查找已知类,点击Class Name列标题以按字母顺序排序。然后,点击一个类名称。此时右侧将出现 Instance View窗格,显示该类的每个实例,如图 6 所示。

    • 此外,您也可以快速找到对象,方法是点击 Filter 图标,或按 Ctrl+F 键(在 Mac 上,按 Command+F 键),然后在搜索字段中输入类或软件包名称。如果从下拉菜单中选择 Arrange by callstack,还可以按方法名称搜索。如果要使用正则表达式,请勾选 Regex 旁边的复选框。如果您的搜索查询区分大小写,请勾选 Match case 旁边的复选框。
  2. Instance View窗格中,点击一个实例。此时下方将出现 References标签页,显示对该对象的每个引用。

    或者,点击实例名称旁边的箭头以查看其所有字段,然后点击一个字段名称以查看其所有引用。如果您要查看某个字段的实例详细信息,请右键点击该字段并选择 Go to Instance

  3. References 标签页中,如果您发现某个引用可能在泄露内存,请右键点击它并选择 Go to Instance。这样会从堆转储中选择相应的实例,从而向您显示它自己的实例数据。

在您的堆转储中,请注意由下列任意情况引起的内存泄露:

  • 长时间引用 ActivityContextViewDrawable 和其他对象,可能会保持对 ActivityContext 容器的引用。
  • 可以保持 Activity 实例的非静态内部类,如 Runnable
  • 对象保持时间比所需时间长的缓存。

将堆转储另存为 HPROF 文件

捕获堆转储后,只有在 Memory Profiler 正在运行时,才能在该分析器中查看数据。当您退出分析会话时,会丢失堆转储。因此,如果您要保存堆转储以供日后查看,请将其导出到 HPROF 文件。在 Android Studio 3.1 及更低版本中,Export capture to file 按钮位于时间轴下方工具栏的左侧;在 Android Studio 3.2 及更高版本中,Sessions 窗格中每个 Heap Dump 条目的右侧都有一个 Export Heap Dump 按钮。在随即显示的 Export As 对话框中,使用 .hprof 文件扩展名保存文件。

要使用其他 HPROF 分析器(如 jhat),您需要将 HPROF 文件从 Android 格式转换为 Java SE HPROF 格式。 您可以使用 android_sdk/platform-tools/ 目录中提供的 hprof-conv 工具执行此操作。运行包含两个参数(即原始 HPROF 文件和转换后 HPROF 文件的写入位置)的 hprof-conv 命令。例如:

hprof-conv heap-original.hprof heap-converted.hprof

导入堆转储文件

要导入一个 HPROF (.hprof) 文件,请点击 Sessions 窗格中的 Start a new profiling session 图标 ,选择 Load from file,然后从文件浏览器中选择该文件。

您还可以通过将 HPROF 文件从文件浏览器拖动到编辑器窗口来导入该文件。

Memory Profiler 中的泄露检测

在 Memory Profiler 中分析堆转储时,您可以过滤 Android Studio 认为可能表明应用中的 ActivityFragment 实例存在内存泄露的分析数据。

过滤器显示的数据类型包括:

  • 已销毁但仍被引用的 Activity 实例。
  • 没有有效的 FragmentManager 但仍被引用的 Fragment 实例。

在某些情况(如以下情况)下,过滤器可能会产生误报:

  • 已创建 Fragment,但尚未使用它。
  • 正在缓存 Fragment,但它不是 FragmentTransaction 的一部分。

如需使用此功能,请先捕获堆转储或将堆转储文件导入Android Studio。如需显示可能泄露内存的 Fragment 和 Activity,请勾选 Memory Profiler 的堆转储窗格中的 Activity/Fragment Leaks 复选框,如图 7 所示。

Memory Profiler:内存泄露检测

图 7. 过滤堆转储以检测内存泄露。

分析内存的技巧

使用 Memory Profiler 时,您应对应用代码施加压力并尝试强制内存泄露。在应用中引发内存泄露的一种方式是,先让其运行一段时间,然后再检查堆。泄露在堆中可能逐渐汇聚到分配顶部。不过,泄露越小,为了看到泄露而需要运行应用的时间就越长。

您还可以通过以下某种方式来触发内存泄露:

  • 在不同的 Activity 状态下,先将设备从纵向旋转为横向,再将其旋转回来,这样反复旋转多次。旋转设备经常会使应用泄露 ActivityContextView 对象,因为系统会重新创建 Activity,而如果您的应用在其他地方保持对这些对象其中一个的引用,系统将无法对其进行垃圾回收。
  • 在不同的 Activity 状态下,在您的应用与其他应用之间切换(导航到主屏幕,然后返回到您的应用)。

最原始的内存泄漏排查方式如下:

重复多次操作关键的可疑的路径,从内存监控工具中观察内存曲线,看是否存在不断上升的趋势,且退出一个界面后,程序内存迟迟不降低的话,可能就发生了严重的内存泄漏。

这种方式可以发现最基本,也是最明显的内存泄漏问题,对用户价值最大,操作难度小,性价比极高。

最后修改:2020 年 07 月 23 日 05 : 24 PM
如果觉得我的文章对你有用,请随意赞赏