Android内存泄漏_图文

1、一、android内存机制Android的程序由Java语言编写，所以Android的内存管理与Java的内存管理相似。程序员通过new为对象分配内存，所有对象在java堆内分配空间；然而对象的释放是由垃圾回收器来完成的。CC+中的内存机制是“谁污染，谁治理”，java的就比较人性化了，给我们请了一个专门的清洁工（GC）。那么GC怎么能够确认某一个对象是不是已经被废弃了呢？Java采用了有向图的原理。Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。线程对象可以作为有向图的起始顶点，该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。如果某个对

2、象 (连通子图与这个根顶点不可达(注意，该图为有向图，那么我们认为这个(这些对象不再被引用，可以被GC回收。二、内存泄漏原因导致内存泄漏主要的原因是，先前申请了内存空间而忘记了释放。如果程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器GC验证这些对象是否不再需要。如果存在对象的引用，这个对象就被定义为有效的活动，同时不会被释放。要确定对象所占内存将被回收，我们就要务必确认该对象不再会被使用。典型的做法就是把对象数据成员设为null或者从集合中移除该对象。但当局部变量不需要时，不需明显的设为null，因为一个方法执行完毕时，这些引用会自动被清理。在Java中，

3、内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是有被引用的，即在有向树形图中，存在树枝通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。三、内存泄漏测试方法内存泄漏的测试方法其实也没什么特别的，一句话就是：监控测试场景下应用程序(进程的内存变化信息。但是测试开始之前我们还是有三件事要去做。第一，我们需要一个监控工具(monitor，能实时(每隔一个时间片采样应用程序的内存数据信息；第二，测试用例，开始测试前我们要分析并制定内存可能泄漏的场

4、景；第三，执行测试自动化脚本，避免手工操作对测试数据带来一些影响（对CPU的影响比较大）。1.准备工作测试时使用是名叫AndroidresMonitor的python脚本工具，工具的具体的介绍请参见，此处不做详细介绍。内存泄漏的测试用例和功能测试有几个不同点：1操作的重复性我们设计的测试场景要是重复性的。对于轻微的内存泄漏，我们可以通过操作次数的递增来积累泄漏的内存数量，直到我们能清晰的在曲线变化上内存的泄漏问题。2操作闭环我们的测试场景必须是闭环的。这样我们才能横向对比不同次数的数据信息。3数据读写操作涉及数据读写的操作和功能点，是我们内存泄漏测试需要重点关注的。4图片相关操作图片向来是内存

5、的重灾区，超级大胖子bitmap经常是内存泄漏的祸首。所以，图片的加载、释放、滑动查看等等都需要我们特别小心。5特别关注重复启动退出应用，界面间跳转，登录-退出，多测几次也许问题就在这里。把我们的手工操作转化成python脚本，重复执行多少次我们也不怕。而且，脚本化的用例也是我们测试标准化和可重复性的基础。2.测试执行开启我们的监控工具，测试用例的脚本也跑起来，喝杯咖啡等数据结果就好了。这就是我们内存泄漏测试时的场景。(1监控工具：(2测试脚本(3测试数据3.测试数据分析测试场景下的内存数据变化曲线我们已经拿到了，那这个测试场景下是否是真的有内存泄漏？曲线只是一个表现，我们需要挖掘表象下更深层

6、次的问题。如上图，应用启动和退出的场测试数据，我们可以看到明显的内存申请和释放，good,开发同学做得不错。但是，整体趋势？不对，整体趋势怎么还是持续上升的！这里我们发现了一个内存泄漏的怀疑点。毕竟曲线不能说明这个场景一定有内存泄漏。我们还利用另一个杀手锏MAT，对这个场景下应用程序内存堆栈的信息做进一步的调查。关于MAT(Eclipse Memory Analyser (MAT - Tutorial的使用，有兴趣的同学可以找相关的文章来学习。我这边常用的就是对象数量的横向对比分析法。简单的说就是，操作一次之后分析一次对象的数量，重复操作N次之后再分析一次对象的数量，通过两次对象数量的横向对比

7、，查看测试场景下有无内存泄漏。【举例】=例子=场景三：界面间跳转，主界面分类界面设置主界面QQ笔记：界面跳转过程中CPU的占用率是15%左右；多次跳转，内存数据异常，明显呈持续增长的趋势。结果分析：Pss：在进行界面跳转时，内存占用持续增加，怀疑是否应用没有释放(可能没有及时释放之前的内存数据；或者重复加载相同数据。【内存泄漏分析】进行分析时，采样了两个数据场景：（1）界面跳转，操作一次；（2）连续进行界面跳转，操作10次。分别获取应用的hprof文件进行对比分析。使用MAT对打开照片过程进行内存泄漏分析，分析报告如下： 使用两个场景下的数据进行横向对比，对象数量及占用内存大小对比数据见下表：

8、=四、内存泄漏测试报告-正文-一、关键测试结论：1. 在10个测试场景的测试过程中，发现QQ笔记在界面间跳转和重复拍照加载图片过程中内存数据异常，呈持续增长的趋势；2. 测试意见：1）在测试界面跳转过程中(主要是主界面-分类界面-设置界面，内存占用持续增加，怀疑是否应用没有释放(或者没有及时释放之前的内存数据；2）在重复打开图片笔记和重复拍照-取消两个测试场景中，测试数据有轻微的增长趋势，怀疑操作过程中应用多有轻量的内存泄漏问题；3）在重复拍照加载照片时，用户放弃当前图片重新拍照选择新的图片时，内存占用持续增加，怀疑是否应用没有完全释放(或者没有及时释放之前的图片数据；二、测试环境：测试对象Q

9、Q笔记测试场景1 重复启动应用2 重复登录3 界面间跳转4 重复打开一条笔记5 重复播放一条录音6 重复从相册中加载图片7 拍照后点击“重拍”8 拍照后点击“取消”9 重复拍照加载图片10 左右滑动查看笔记内的图片测试用例见下表。测试指标1 CPU占用率：通过监控工具AndroidresMonitork实时获取应用的CPU值。2 内存占用值：通过工具AndroidresMonitork实时获取应用的内存数据(PSS、RSS、USS，测试中以PSS数据作为应用内存消耗的衡量指标。1.4 测试网络Free-WIFI环境测试机器配置HUAWEI T9510E 配置信息: 主屏尺寸：英寸 触摸屏：电容

10、屏，多点触控 主屏材质：IPS 主屏分辨率：1280x720像素 主屏色彩：1600万色 操作系统： 核心数：4核 CPU型号：海思K3V2 CPU频率：1433MHz RAM容量：1G ROM容量：8G 存储卡：MicroSD卡 扩展容量：32GB三、详细数据及分析：场景九：通过拍照添加图片，拍照确定后的图片-取消-返回编辑界面QQ笔记：拍照过程中CPU的占用率是13%左右；重复多次拍照返回的操作，内存数据异常，虽然有内存资源的释放，但是有明显呈持续增长的趋势。结果分析：Pss：在拍照完成-取消，返回编辑界面跳转时，内存有相应的释放，但是应用的内存占用持续增加，怀疑是否应用没有完全释放(可能

11、没有及时释放之前的内存数据；或者重复加载相同数据。【内存泄漏分析】进行分析时，采样了两个数据场景：（1）拍照-取消，操作一次；（2）连续进行拍照-取消，操作10次。分别获取应用的hprof文件进行对比分析。使用MAT对打开照片过程进行内存泄漏分析，分析报告如下：使用两个场景下的数据进行横向对比，对象数量及占用内存大小对比数据见下表：五、bug修复验证报告一、内存泄漏提单二、Bug具体描述及解决方案1、【内存泄漏】重复启动退出应用程序，内存数据持续上升测试场景CPU及内存数据曲线图 解决方案修复后内存数据曲线验证结果在版本上验证内存泄漏问题，内存的申请和释放过程明显，重复操作过程中内存无持续上升

12、或者积累上升趋势。2、【内存泄漏】通过拍照添加图片，拍照确定后的图片-取消-返回编辑界面，重复操作过程中存在内存泄漏测试场景CPU及内存数据曲线图解决方案修复后内存数据曲线验证结果在版本上验证内存泄漏问题，内存的申请和释放过程明显，重复操作过程中内存无持续上升或者积累上升趋势。三、测试反馈这次专项测试发现的问题主要属于两个类型：1）在activity生命周期的不同阶段未合理释放内存资源；2）图片操作相关的bitmap没有及时释放这里也梳理一些常见的需要关注内存操作相关问题：1. 查询数据库没有关闭游标程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的

13、查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。2. 构造Adapter时，没有使用缓存的 convertView以构造ListView的BaseAdapter为例，在BaseAdapter中提高了方法public View getView(int position, View convertView, ViewGroup parent来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象，同时ListV

14、iew会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView(方法完成的，getView(的第二个形参 View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null。由此可以看出，如果我们不去使用convertView，而是每次都在getView(中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。ListView回收list item

15、的view对象的过程可以查看:android.widget.AbsListView.java - void addScrapView(View scrap 方法。3. Bitmap对象不在使用时调用recycle(释放内存有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle(方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释： /* Free up the memory associated with this bitmaps pixels, and mark the * bitm

16、ap as dead, meaning it will throw an exception if getPixels( or* setPixels( is called, and will draw nothing. This operation cannot be* reversed, so it should only be called if you are sure there are no* further uses for the bitmap. This is an advanced call, and normally need ; * not be called, since the normal GC process will free up this memory when* there are no more references to this bitmap.*/4. 释放对象的引用5.