Android内存泄漏的简单检查与分析方法-低调大师

Android内存泄漏的简单检查与分析方法

2018-05-15 619

一、什么是内存泄漏？

大家都知道，java是有垃圾回收机制的，这使得java程序员比C++程序员轻松了许多，存储申请了，不用心心念念要加一句释放，java虚拟机会派出一些回收线程兢兢业业不定时地回收那些不再被需要的内存空间（注意回收的不是对象本身，而是对象占据的内存空间）。

Q1：什么叫不再被需要的内存空间？

**答：**Java没有指针，全凭引用来和对象进行关联，通过引用来操作对象。如果一个对象没有与任何引用关联，那么这个对象也就不太可能被使用到了，回收器便是把这些“无任何引用的对象”作为目标，回收了它们占据的内存空间。

Q2：如何分辨为对象无引用？

**答：**2种方法

引用计数法直接计数，简单高效，Python便是采用该方法。但是如果出现两个对象相互引用，即使它们都无法被外界访问到，计数器不为0它们也始终不会被回收。为了解决该问题，java采用的是b方法。
可达性分析法这个方法设置了一系列的“GC Roots”对象作为索引起点，如果一个对象与起点对象之间均无可达路径，那么这个不可达的对象就会成为回收对象。这种方法处理两个对象相互引用的问题，如果两个对象均没有外部引用，会被判断为不可达对象进而被回收（如下图）。

Q3：有了回收机制，放心大胆用不会有内存泄漏？

**答：**答案当然是No！

虽然垃圾回收器会帮我们干掉大部分无用的内存空间，但是对于还保持着引用，但逻辑上已经不会再用到的对象，垃圾回收器不会回收它们。这些对象积累在内存中，直到程序结束，就是我们所说的“内存泄漏”。

当然了，用户对单次的内存泄漏并没有什么感知，但当泄漏积累到内存都被消耗完，就会导致卡顿，崩溃。

二、发现内存泄漏

内存泄漏不可小视，在Android开发中，比如说一个Activity页面会占用许多资源开销，如果页面发生泄漏，关闭以后页面没有能被系统回收，对应用程序的伤害是很大的。

Q1：在Android开发测试中一般如何发现内存泄漏的发生呢？

答：

方法1：反复操作观察内存变化

内存泄漏常见变现为程序使用时间越长，内存占用越多。那我们通过反复操作应用，比如反复点开/关闭页面，观察内存变化状况是否一点点上涨，可以粗略地判断是否有内存泄漏

1.通过 DDMS 中的 heap 工具，可以查看应用内存的使用情况

2.Android studio也可以方便查看

方法2：通过代码检测Activity泄漏

基本思路：

1）debug版本可以起一个长期工作的线程LeakThread在后台专门做泄漏检测

2）向Application注册一个页面生命周期的监听：application.registerActivityLifecycleCallbacks

3）在监听类中对 onActivityDestoryed(Activity activity) 的事件回调做处理：

如果一个Activity走到onDestroy，那么这个Activity对象就是需要被回收的目标。

我们声明一个检测对象的弱引用ref = new WeakReference<Object>(activity)。

**PS：**与强引用和软引用相比，弱引用不会被回收器当做一个“有效”的引用，不会影响其引用对象的释放。实际上，垃圾回收器会毫不犹豫地回收只有弱引用的对象~

4）在 LeakThread中我们每隔一段时间检测一下ref.get() 是否为空，为空说明activity已被释放。不为空可以手动触一次发gc；如果超过一段时间，比如50s，页面对象还未被清理，我们可以推断内存泄漏的发生.

5）当内存泄漏发生时，提示给开发者，并自动dump出.prof文件。

因为代码检测不是这里的重点，代码就不贴了，只记思路。

三、分析内存泄漏（DDMS dump + MAT分析）

发现可能出现内存泄漏时，我们需要对.prof文件进行分析，方能快速定位到是哪个倒霉家伙导致了内存泄漏

3.1、如何dump出.prof文件？（可参照前文图片）

打开DDMS ，Eclipse 可以切到DDMS视图，Android studio可以从Tools-Android-Android device monitor进入DDMS
找到app的进程，在进程上方点击“update heap”按钮，可以先主动出发一次GC，待内存占用数据稍微稳定下来后点击“Dump HProf File”，便可以导出.prof文件

3.2：导出.prof文件后如何分析？

Android studio可以直接打开prof文件。点开Analyzer Tasks的面板，点击右上角的开始按钮。

分析完成后，发生内存泄漏的页面对象会出现在Analysis Results面板-Leak Activityes的目录下。

如图，原来泄漏发生是LoadingRoomActivity的锅！

3.3 进一步分析泄漏的原因，你会需要一个好用的内存分析工具：MAT

在官网可以下载到它：

http://www.eclipse.org/mat/downloads.php

虽然MAT不会准确告诉你你的代码哪泄漏了，但是它会给你发现哪泄露的数据和线索。

3.3.1 打开.hprof前可能遇到的问题：

在MAT中打开.prof页面，你可能会遇到一点小挫折：

如上图，可能会弹出 ‘Parsing heap dump from xxx has encountered a proplem’ 的错误弹窗

这是因为文件版本和编辑器能支持的版本有冲突的原因。

解决方案如下：

Sdk安装目录下platform-tools里有一个hprof-conv工具可以解决该问题。在cmd控制台执行：

hprof-conv input.hprof output.hprof

重新再MAT打开output.hprof 就可以打开了~

值得一提的是，如果你dump出的文件太大的话，也有可能发现打不开的现象，这时候，打开安装MAT目录下的MemoryAnalyzer.ini 把-XmX改大些重启即可。但是也不要改得比你机器的可用内存还大，不能太贪心哈哈~

3.3.2 打开.phrof文件后的分析

通过MAT打开.phrof文件后，会弹出Overview 和 Leak Suspects 2个标签页。

Leak Suspects标签页可见如下图：

Leak Suspects视图展示了app内存占用的比例，浅色是空闲的内存，其他是内存占用的空间。每块内存对应的问题也都列在下面。点开每个Problem Suspect下的details，可以看到有哪些类的实例占用了内存和占用大小等信息~

此时我们已经有了怀疑的目标，为了更清晰地查看，我们可以回到Overview页面，打开Histogram页面：

在打开的Histogram标签页中，我们填入检测对象，在列出的匹配项中过滤掉对象的非强引用。

到这里我们就可以看到，是哪个坏蛋hold住了你的对象了。MAT能够给到的支持也就到这里，接下来，还是需要你根据这些线索到代码中寻找判别和修正了~``

微信关注我们

原文链接：https://yq.aliyun.com/articles/593521

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

C# DataGridView 在最左侧显示行号方法

代码： private void dataGridView1_RowPostPaint(object sender, DataGridViewRowPostPaintEventArgs e) { DataGridView dgv = sender as DataGridView; Rectangle rectangle = new Rectangle(e.RowBounds.Location.X, e.RowBounds.Location.Y, dgv.RowHeadersWidth - 4, e.RowBounds.Height); TextRenderer.DrawText(e.Graphics, (e.RowIndex + 1).ToString(), dgv.RowHeadersDefaultCellStyle.Font, rectangle, dgv.RowHeadersDefaultCellStyle.ForeColor, TextFormatFlags.VerticalCenter | TextFormatFlags.Right); } 效果：

2018-05-16

694

在Java中，所有对象都存储在堆中。他们通过new关键字来进行分配，JVM会检查是否所有线程都无法在访问他们了，并且会将他们进行回收。在大多数时候程序员都不会有一丝一毫的察觉，这些工作都被静悄悄的执行。但是，有时候在发布前的最后一天，程序挂了。 Exception in thread "main" java.lang.OutOfMemoryError: Java heap space OutOfMemoryError是一个让人很郁闷的异常。它通常说明你干了写错误的事情：没必要的长时间保存一些没必要的数据，或者同一时间处理了过多的数据。有些时候，这些问题并不一定受你的控制，比如说一些第三方的库对一些字符串做了缓存，或者一些应用服务器在部署的时候并没有进行清理。并且，对于堆中已经存在的对象，我们往往拿他们没办法。这篇文章分析了导致OutOfMemoryError的不同原因，以及你该怎样应对这种原因的方法。以下分析仅限于Sun Hotspot虚拟机，但是大多数结论都适用于其他任何的JVM实现。它们大多数基于网上的文章以及我自己的经验。我没有直接做JVM开发的工作，因此结论并不代表JVM的作...

2018-05-16

581

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。