Android内存泄漏..docVIP

一、android内存机制 Android的程序由Java语言编写，所以Android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存，所有对象在java堆内分配空间；然而对象的释放是由垃圾回收器来完成的。C／C++中的内存机制是“谁污染，谁治理”，java的就比较人性化了，给我们请了一个专门的清洁工（GC）。 那么GC怎么能够确认某一个对象是不是已经被废弃了呢？Java采用了有向图的原理。Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。线程对象可以作为有向图的起始顶点，该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被GC回收。 二、内存泄漏原因 导致内存泄漏主要的原因是，先前申请了内存空间而忘记了释放。如果程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器GC验证这些对象是否不再需要。如果存在对象的引用，这个对象就被定义为有效的活动，同时不会被释放。要确定对象所占内存将被回收，我们就要务必确认该对象不再会被使用。典型的做法就是把对象数据成员设为null或者从集合中移除该对象。但当局部变量不需要时，不需明显的设为null，因为一个方法执行完毕时，这些引用会自动被清理。 在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是有被引用的，即在有向树形图中，存在树枝通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。 三、内存泄漏测试方法 内存泄漏的测试方法其实也没什么特别的，一句话就是：监控测试场景下应用程序(进程)的内存变化信息。但是测试开始之前我们还是有三件事要去做。第一，我们需要一个监控工具(monitor)，能实时(每隔一个时间片)采样应用程序的内存数据信息；第二，测试用例，开始测试前我们要分析并制定内存可能泄漏的场景；第三，执行测试自动化脚本，避免手工操作对测试数据带来一些影响（对CPU的影响比较大）。 1.准备工作 1.1监控工具 测试时使用是名叫AndroidresMonitor的python脚本工具，工具的具体的介绍请参见/group/3277/articles/show/140708，此处不做详细介绍。 1.2测试用例 内存泄漏的测试用例和功能测试有几个不同点： 1)操作的重复性 我们设计的测试场景要是重复性的。对于轻微的内存泄漏，我们可以通过操作次数的递增来积累泄漏的内存数量，直到我们能清晰的在曲线变化上内存的泄漏问题。 2)操作闭环 我们的测试场景必须是闭环的。这样我们才能横向对比不同次数的数据信息。 3)数据读写操作 涉及数据读写的操作和功能点，是我们内存泄漏测试需要重点关注的。 4)图片相关操作 图片向来是内存的重灾区，超级大胖子bitmap经常是内存泄漏的祸首。所以，图片的加载、释放、滑动查看等等都需要我们特别小心。 5)特别关注 重复启动退出应用，界面间跳转，登录-退出，多测几次也许问题就在这里。 1.3测试脚本--Monkeyrunner 把我们的手工操作转化成python脚本，重复执行多少次我们也不怕。而且，脚本化的用例也是我们测试标准化和可重复性的基础。 2.测试执行 开启我们的监控工具，测试用例的脚本也跑起来，喝杯咖啡等数据结果就好了。这就是我们内存泄漏测试时的场景。 (1)监控工具： (2)测试脚本 (3)测试数据 3.测试数据分析 测试场景下的内存数据变化曲线我们已经拿到了，那这个测试场景下是否是真的有内存泄漏？曲线只是一个表现，我们需要挖掘表象下更深层次的问题。 如上图，应用启动和退出的场测试数据，我们可以看到明显的内存申请和释放，good,开发同学做得不错。但是，整体趋势？？？不对，整体趋势怎么还是持续上升的！ 这里我们发现了一个内存泄漏的怀疑点。毕竟曲线不能说明这个场景一定有内存泄漏。我们还利用另一个杀手锏——MAT，对这个场景下应用程序内存堆栈的信息做进一步的调查。 关于MAT(HYPERLINK http://www.vogella.de/articles/EclipseMemoryAnalyser/article.htmlEclipse Memory Analyser (MAT) - Tutorial)的使用，有兴趣的同学可