AS 也能检测 Activity 内存泄露 | 吊打 OOM

最新推荐文章于 2023-05-12 13:47:26 发布

承香墨影

最新推荐文章于 2023-05-12 13:47:26 发布

阅读量368

点赞数

本文链接：https://blog.csdn.net/plokmju88/article/details/103354805

版权

版权声明：

本公众号发布的所有文章，未特殊署名，均属于原创，版权归本公众号所有。

转载请参阅公众号的：《转载授权》。

序

OOM（Out of Memory）是 Android 开发绕不过去的坎，一定会遇到。但是很多时候，报错的地方都并不是发生问题的原因，只是压死骆驼的最后一根稻草。

解决 OOM ，涉及到的东西太多了，从原理、分析工具、解决办法很多个方向，所以准备做一个专门解决 OOM 需要用到的知识，集合成一个系列来发布。

就叫它《吊打 OOM》吧，准备慢慢写好好写，希望完结之后，不惧 OOM。

一、前言

OOM（Out of Memory）大部分原因来自内存泄露，如果有内存泄露导致系统 GC 无法将无用资源回收，就可能导致下次申请内存空间的时候，出现 OOM 的错误。

其实 Android Studio（以下简称 AS）已经自带了一些内存泄露的检查。但是它的功能有限，暂时只能对 Activity 发生的内存泄露进行检查。

下面来了解如何使用 AS 分析 Activity 的内存泄露。

二、Android Monitor

一般用来做内存泄露的检测，会推荐使用 LeakCannary ，它是 Square 提供的一个检测内存泄露的开源库，集成也非常的简单。

有兴趣的可以去 Github 上看它的文档集成使用。

https://github.com/square/leakcanary

不过大多数情况下，我们可能不会去使用 LeakCanary ，毕竟它还是需要集成在项目中。而如果只是为了检测一下是否有 Activity 的内存泄露情况，其实 AS 中已经提供了检测的工具。

AS 本身也为我们提供了非常方便的 Android Monitor 工具，来帮我们监听当前 Debug 情况下，App 运行的情况，其中就包括 Memory 的监控。

Memory 窗口可以完全监听当前正在 Debug 的 App 的内存使用情况。如果在正常操作的时候，看到此处的内存一直在飙高，却没有降低的迹象，你的 App 就可能存在内存泄露的问题。

先来简单介绍一下 Memory 面板，如图中标记的区域。

1、当前监控的终端设备和进程。

2、被检测的设备的内存分配情况。

Allocated：已经被使用的空间。
Free : 当前剩余的空间。

3、Memroy 分析的工具栏，包含一些内存分析相关的操作。

分析内存的工具栏，从左到右依次的作用是：

Enable：终止检测。
Initiate GC ：手动触发 GC。
Jump java heap：获取 hprof 分析文件。
Start Allocation Tracking：开始分配追踪。
Memory monitor help：查看帮助文档。

特别提一下，内存分配情况只是标识当前的内存使用情况，如果还需要继续使用内存，是可以继续申请的，直到超过了 Dalvik Heap 分配的最大内存数，就会触发 OOM。

今天介绍的方法，主要会使用到『获取 hprof 分析文件的方法』，去获取一个 hprof 文件进行分析，AS 使用这种方式生成的 hprof 文件，并非标准的 hprof 文件，是专门为 AS 分析使用的，所以如果想要交给 MAT 进行分析，还需要使用 hprof-conv 命令进行转换一下。这不是本文的重点，本文介绍的方式只需要使用 AS 进行分析即可。

点击『Jump java heap』按钮之后，会自动生成当前设备当前进行的内存使用报告，我们就在此基础上进行分析。

生成的时间完全视情况而定，可能受当前使用的内存大小和当前使用的设备配置决定。最终会生成一个 .hprof 的文件，文件的命名掺杂了包名和日期时间，能帮我们很好的区分它们。