Android下怎么诊断/防止程序的内存泄漏/内存碎片，大家有没什么好方法

Android下怎么诊断/防止程序的内存泄漏/内存碎片，大家有没什么好方法

42 个解决方案

#1

关于Android堆内存的设置

关于Android堆内存的设置[ 已编辑] 选项 将帖子标记为未读
 
将此主题添加到书签
 
订阅此主题
 
订阅此主题的 RSS 提要
 
高亮显示此贴
 
打印此贴
 
通过电子邮件将此主题发送给好友
 
举报此贴
 
修改时间 08-30-2010 12:21 AM 上次修改时间: 08-30-2010 10:26 AM 

大家都知道Android的上层应用是基于 Dalvik Virtual Machine的。Dalvik VM的特点是基于寄存器，相比SUN的JVM（基于堆栈，没有寄存器）来说，理论上完成同样的功能需要的指令条数少，但是指令集复杂。到了Android2.2，Dalvik终于实现了JIT（Just In Time）功能，前进了一大步。

 

近期我们遇到OutOfMemory的错误，通常是堆内存溢出。网上有些帖子说可以通过函数设置应用的HEAP SIZE来解决这个问题，其实是不对的。

 

 

VMRuntime.getRuntime().setMinimumHeapSize(NewSize); 

堆（HEAP）是VM中占用内存最多的部分，通常是动态分配的。堆的大小不是一成不变的，通常有一个分配机制来控制它的大小。比如初始的HEAP是4M大，当4M的空间被占用超过75%的时候，重新分配堆为8M大；当8M被占用超过75%，分配堆为16M大。倒过来，当16M的堆利用不足30%的时候，缩减它的大小为8M大。重新设置堆的大小，尤其是压缩，一般会涉及到内存的拷贝，所以变更堆的大小对效率有不良影响。

 

上面只是个例子，不过可以看到三个参数：max heap size, min heap size, heap utilization（堆利用率）。

 

Max Heap Size，是堆内存的上限值，Android的缺省值是16M（某些机型是24M），对于普通应用这是不能改的。函数setMinimumHeapSize其实只是改变了堆的下限值，它可以防止过于频繁的堆内存分配，当设置最小堆内存大小超过上限值时仍然采用堆的上限值，对于内存不足没什么作用。

 

setTargetHeapUtilization(float newTarget) 可以设定内存利用率的百分比，当实际的利用率偏离这个百分比的时候，虚拟机会在GC的时候调整堆内存大小，让实际占用率向个百分比靠拢。

#2

Java性能优化[3]：垃圾回收(GC)

http://hulefei29.javaeye.com/blog/658546

#3

错误消息举例

E/SurfaceFlinger(  181): not enough memory for layer bitmap size=770048 (w=800, h=480, stride=800, format=4)
D/MemoryDealer(  181):   LayerBitmap (0x1ff018, size=8388608)
D/MemoryDealer(  181):     0: 001ff050 | 0x00000000 | 0x000BC000 | A 
D/MemoryDealer(  181):     1: 002b7be8 | 0x000BC000 | 0x000BC000 | A 
D/MemoryDealer(  181):     2: 002b7cb8 | 0x00178000 | 0x000BC000 | A 
D/MemoryDealer(  181):     3: 000af020 | 0x00234000 | 0x0000A000 | A 
D/MemoryDealer(  181):     4: 00248e98 | 0x0023E000 | 0x000B2000 | F 
D/MemoryDealer(  181):     5: 001faab0 | 0x002F0000 | 0x0000A000 | A 
D/MemoryDealer(  181):     6: 0026c288 | 0x002FA000 | 0x000BC000 | A 
D/MemoryDealer(  181):     7: 002c0eb0 | 0x003B6000 | 0x000BC000 | A 
D/MemoryDealer(  181):     8: 002c8980 | 0x00472000 | 0x000BC000 | A 
D/MemoryDealer(  181):     9: 003060f0 | 0x0052E000 | 0x000BC000 | A 
D/MemoryDealer(  181):    10: 002cab70 | 0x005EA000 | 0x000BC000 | A 
D/MemoryDealer(  181):    11: 0030ef00 | 0x006A6000 | 0x000BC000 | A 
D/MemoryDealer(  181):    12: 00290978 | 0x00762000 | 0x0009E000 | F 
D/MemoryDealer(  181):   size allocated: 7012352 (6848 KB)
E/SurfaceFlinger(  181): createNormalSurfaceLocked() failed (Out of memory)
W/WindowManager(  181): OutOfResourcesException creating surface
I/WindowManager(  181): Out of memory for surface!  Looking for leaks...
W/WindowManager(  181): No leaked surfaces; killing applicatons!
W/ActivityManager(  181): Killing processes for memory at adjustment 0
W/WindowManager(  181): Due to memory failure, waiting a bit for next layout

#4

java内存溢出相关问题【转】

http://hi.baidu.com/%C7%E9%B6%A8%BD%E9%B0%C9/blog/item/fc62d2ec2117974379f0557e.html

一、内存溢出类型
1、java.lang.OutOfMemoryError: PermGen space 

JVM管理两种类型的内存，堆和非堆。堆是给开发人员用的上面说的就是，是在JVM启动时创建；非堆是留给JVM自己用的，用来存放类的信息的。它和堆不同，运行期内GC不会释放空间。如果web app用了大量的第三方jar或者应用有太多的class文件而恰好MaxPermSize设置较小，超出了也会导致这块内存的占用过多造成溢出，或者tomcat热部署时侯不会清理前面加载的环境，只会将context更改为新部署的，非堆存的内容就会越来越多。


2、java.lang.OutOfMemoryError: Java heap space

第一种情况是个补充，主要存在问题就是出现在这个情况中。其默认空间(即-Xms)是物理内存的1/64，最大空间(-Xmx)是物理内存的1/4。如果内存剩余不到40％，JVM就会增大堆到Xmx设置的值，内存剩余超过70％，JVM就会减小堆到Xms设置的值。所以服务器的Xmx和Xms设置一般应该设置相同避免每次GC后都要调整虚拟机堆的大小。假设物理内存无限大，那么JVM内存的最大值跟操作系统有关，一般32位机是1.5g到3g之间，而64位的就不会有限制了。


注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。


垃圾回收GC的角色

JVM调用GC的频度还是很高的，主要两种情况下进行垃圾回收：

当应用程序线程空闲；另一个是java内存堆不足时，会不断调用GC，若连续回收都解决不了内存堆不足的问题时，就会报out of memory错误。因为这个异常根据系统运行环境决定，所以无法预期它何时出现。

根据GC的机制，程序的运行会引起系统运行环境的变化，增加GC的触发机会。

为了避免这些问题，程序的设计和编写就应避免垃圾对象的内存占用和GC的开销。显示调用System.GC()只能建议JVM需要在内存中对垃圾对象进行回收，但不是必须马上回收，

一个是并不能解决内存资源耗空的局面，另外也会增加GC的消耗。

二、JVM内存区域组成
简单的说java中的堆和栈

java把内存分两种：一种是栈内存，另一种是堆内存

1。在函数中定义的基本类型变量和对象的引用变量都在函数的栈内存中分配；

2。堆内存用来存放由new创建的对象和数组

在函数（代码块）中定义一个变量时，java就在栈中为这个变量分配内存空间，当超过变量的作用域后，java会自动释放掉为该变量所分配的内存空间；在堆中分配的内存由java虚拟机的自动垃圾回收器来管理


堆的优势是可以动态分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的。缺点就是要在运行时动态分配内存，存取速度较慢；

栈的优势是存取速度比堆要快，缺点是存在栈中的数据大小与生存期必须是确定的无灵活性。


java堆分为三个区：New、Old和Permanent

GC有两个线程：

新创建的对象被分配到New区，当该区被填满时会被GC辅助线程移到Old区，当Old区也填满了会触发GC主线程遍历堆内存里的所有对象。Old区的大小等于Xmx减去-Xmn


java栈存放

栈调整：参数有+UseDefaultStackSize -Xss256K，表示每个线程可申请256k的栈空间

每个线程都有他自己的Stack


三、JVM如何设置虚拟内存
提示：在JVM中如果98％的时间是用于GC且可用的Heap size 不足2％的时候将抛出此异常信息。

提示：Heap Size 最大不要超过可用物理内存的80％，一般的要将-Xms和-Xmx选项设置为相同，而-Xmn为1/4的-Xmx值。 

提示：JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4。

默认空余堆内存小于40%时，JVM就会增大堆直到-Xmx的最大限制；空余堆内存大于70%时，JVM会减少堆直到-Xms的最小限制。因此服务器一般设置-Xms、-Xmx相等以避免在每次GC 后调整堆的大小。 

提示：假设物理内存无限大的话，JVM内存的最大值跟操作系统有很大的关系。

简单的说就32位处理器虽然可控内存空间有4GB,但是具体的操作系统会给一个限制，

这个限制一般是2GB-3GB（一般来说Windows系统下为1.5G-2G，Linux系统下为2G-3G），而64bit以上的处理器就不会有限制了

提示：注意：如果Xms超过了Xmx值，或者堆最大值和非堆最大值的总和超过了物理内存或者操作系统的最大限制都会引起服务器启动不起来。

提示：设置NewSize、MaxNewSize相等，"new"的大小最好不要大于"old"的一半，原因是old区如果不够大会频繁的触发"主" GC ，大大降低了性能


JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；

由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。



解决方法：手动设置Heap size

修改TOMCAT_HOME/bin/catalina.bat

在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：

JAVA_OPTS="-server -Xms800m -Xmx800m -XX:MaxNewSize=256m"



四、性能检查工具使用
定位内存泄漏：

JProfiler工具主要用于检查和跟踪系统（限于Java开发的）的性能。JProfiler可以通过时时的监控系统的内存使用情况，随时监视垃圾回收，线程运行状况等手段，从而很好的监视JVM运行情况及其性能。

1. 应用服务器内存长期不合理占用，内存经常处于高位占用，很难回收到低位； 

2. 应用服务器极为不稳定，几乎每两天重新启动一次，有时甚至每天重新启动一次； 

3. 应用服务器经常做Full GC(Garbage Collection)，而且时间很长，大约需要30-40秒，应用服务器在做Full GC的时候是不响应客户的交易请求的，非常影响系统性能。 


因为开发环境和产品环境会有不同，导致该问题发生有时会在产品环境中发生，通常可以使用工具跟踪系统的内存使用情况，在有些个别情况下或许某个时刻确实是使用了大量内存导致out of memory，这时应继续跟踪看接下来是否会有下降，

如果一直居高不下这肯定就因为程序的原因导致内存泄漏。


五、不健壮代码的特征及解决办法
1、尽早释放无用对象的引用。好的办法是使用临时变量的时候，让引用变量在退出活动域后，自动设置为null，暗示垃圾收集器来收集该对象，防止发生内存泄露。

对于仍然有指针指向的实例，jvm就不会回收该资源,因为垃圾回收会将值为null的对象作为垃圾，提高GC回收机制效率；

2、我们的程序里不可避免大量使用字符串处理，避免使用String，应大量使用StringBuffer，每一个String对象都得独立占用内存一块区域；

String str = "aaa"; 

String str2 = "bbb"; 

String str3 = str + str2;//假如执行此次之后str ,str2以后再不被调用,那它就会被放在内存中等待Java的gc去回收,程序内过多的出现这样的情况就会报上面的那个错误,建议在使用字符串时能使用StringBuffer就不要用String,这样可以省不少开销； 


3、尽量少用静态变量，因为静态变量是全局的，GC不会回收的；

4、避免集中创建对象尤其是大对象，JVM会突然需要大量内存，这时必然会触发GC优化系统内存环境；显示的声明数组空间，而且申请数量还极大。

这是一个案例想定供大家警戒

使用jspsmartUpload作文件上传,运行过程中经常出现java.outofMemoryError的错误，

检查之后发现问题：组件里的代码

m_totalBytes = m_request.getContentLength();

m_binArray = new byte[m_totalBytes];

问题原因是totalBytes这个变量得到的数极大，导致该数组分配了很多内存空间，而且该数组不能及时释放。解决办法只能换一种更合适的办法，至少是不会引发outofMemoryError的方式解决。参考：http://bbs.xml.org.cn/blog/more.asp?name=hongrui&id=3747


5、尽量运用对象池技术以提高系统性能；生命周期长的对象拥有生命周期短的对象时容易引发内存泄漏，例如大集合对象拥有大数据量的业务对象的时候，可以考虑分块进行处理，然后解决一块释放一块的策略。

6、不要在经常调用的方法中创建对象，尤其是忌讳在循环中创建对象。可以适当的使用hashtable，vector 创建一组对象容器，然后从容器中去取那些对象，而不用每次new之后又丢弃

7、一般都是发生在开启大型文件或跟数据库一次拿了太多的数据，造成 Out Of Memory Error 的状况，这时就大概要计算一下数据量的最大值是多少，并且设定所需最小及最大的内存空间值。

#5

[Android] 内存泄漏调试经验分享 (一)

http://rayleeya.javaeye.com/blog/727074

 各位兄弟姐妹，Java开发中的内存泄露的问题经常会给我们带来很多烦恼。特别是对一些新手，如果平时不注意一些细节问题，最后很可能会导致很严重的后果。

    在Android中的Java开发也同样会有这样的问题。附件中的pdf整理了一些关于Android中的Java开发，在内存使用方面需要注意的一些问题，希望能够对大家有所帮助。

 

接下篇: [Android] 内存泄漏调试经验分享 (二) http://rayleeya.javaeye.com/blog/755657

 

Android 内存泄漏调试

Made by 李文栋  

[e-mail] | [e-mail]

2010-07-25  Friday

 

 

 

一、概述 1

二、Android(Java)中常见的容易引起内存泄漏的不良代码 1

(一) 查询数据库没有关闭游标 2

(二) 构造Adapter时，没有使用缓存的 convertView 3

(三) Bitmap对象不在使用时调用recycle()释放内存 4

(四) 释放对象的引用 4

(五) 其他 5

三、内存监测工具 DDMS --> Heap 5

四、内存分析工具 MAT(Memory Analyzer Tool) 7

(一) 生成.hprof文件 7

(二) 使用MAT导入.hprof文件 8

(三) 使用MAT的视图工具分析内存 8

 

 

一、概述 
    Java编程中经常容易被忽视，但本身又十分重要的一个问题就是内存使用的问题。Android应用主要使用Java语言编写，因此这个问题也同样会在Android开发中出现。本文不对Java编程问题做探讨，而是对于在Android中，特别是应用开发中的此类问题进行整理。

    由于作者接触Android时间并不是很长，因此如有叙述不当之处，欢迎指正。

二、Android(Java)中常见的容易引起内存泄漏的不良代码 
    Android主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会引起系统重启）。另一方面Android为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉。Android为应用进程分配的内存上限如下所示：

位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本

# Define the oom_adj values for the classes of processes that can be

# killed by the kernel.  These are used in ActivityManagerService.

    setprop ro.FOREGROUND_APP_ADJ 0

    setprop ro.VISIBLE_APP_ADJ 1

    setprop ro.SECONDARY_SERVER_ADJ 2

    setprop ro.BACKUP_APP_ADJ 2

    setprop ro.HOME_APP_ADJ 4

    setprop ro.HIDDEN_APP_MIN_ADJ 7

    setprop ro.CONTENT_PROVIDER_ADJ 14

    setprop ro.EMPTY_APP_ADJ 15

 

# Define the memory thresholds at which the above process classes will

# be killed.  These numbers are in pages (4k).

    setprop ro.FOREGROUND_APP_MEM 1536

    setprop ro.VISIBLE_APP_MEM 2048

    setprop ro.SECONDARY_SERVER_MEM 4096

    setprop ro.BACKUP_APP_MEM 4096

    setprop ro.HOME_APP_MEM 4096

    setprop ro.HIDDEN_APP_MEM 5120

    setprop ro.CONTENT_PROVIDER_MEM 5632

    setprop ro.EMPTY_APP_MEM 6144

 

# Write value must be consistent with the above properties.

# Note that the driver only supports 6 slots, so we have HOME_APP at the

# same memory level as services.

    write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15

 

    write /proc/sys/vm/overcommit_memory 1

    write /proc/sys/vm/min_free_order_shift 4

    write /sys/module/lowmemorykiller/parameters/minfree 1536,2048,4096,5120,5632,6144

 

    # Set init its forked children's oom_adj.

    write /proc/1/oom_adj -16

 

    正因为我们的应用程序能够使用的内存有限，所以在编写代码的时候需要特别注意内存使用问题。如下是一些常见的内存使用不当的情况。

 

(一) 查询数据库没有关闭游标 
描述：

    程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。

 

示例代码：

Cursor cursor = getContentResolver().query(uri ...);

if (cursor.moveToNext()) {

    ... ... 

}

 

修正示例代码：

Cursor cursor = null;

try {

    cursor = getContentResolver().query(uri ...);

    if (cursor != null && cursor.moveToNext()) {

        ... ... 

    }

} finally {

    if (cursor != null) {

        try { 

            cursor.close();

        } catch (Exception e) {

            //ignore this

        }

    }

} 

 

(二) 构造Adapter时，没有使用缓存的 convertView 
描述：

    以构造ListView的BaseAdapter为例，在BaseAdapter中提高了方法：

public View getView(int position, View convertView, ViewGroup parent)

来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参 View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。

    由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。ListView回收list item的view对象的过程可以查看:

android.widget.AbsListView.java --> void addScrapView(View scrap) 方法。

 

示例代码：

public View getView(int position, View convertView, ViewGroup parent) {

    View view = new Xxx(...);

    ... ...

    return view;

}

 

修正示例代码：

public View getView(int position, View convertView, ViewGroup parent) {

    View view = null;

    if (convertView != null) {

        view = convertView;

        populate(view, getItem(position));

        ...

    } else {

        view = new Xxx(...);

        ...

    }

    return view;

} 

 

(三) Bitmap对象不在使用时调用recycle()释放内存 
描述：

    有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：

    /**

     * Free up the memory associated with this bitmap's pixels, and mark the

     * bitmap 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.

     */

(四) 释放对象的引用 
描述：

    这种情况描述起来比较麻烦，举两个例子进行说明。

示例A：

假设有如下操作

public class DemoActivity extends Activity {

    ... ...

    private Handler mHandler = ...

    private Object obj;

    public void operation() {

     obj = initObj();

     ...

     [Mark]

     mHandler.post(new Runnable() {

            public void run() {

             useObj(obj);

            }

     });

    }

}

    我们有一个成员变量 obj，在operation()中我们希望能够将处理obj实例的操作post到某个线程的MessageQueue中。在以上的代码中，即便是mHandler所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。所以如果在DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的引用，而代码可以修改为：

... ...

public void operation() {

    obj = initObj();

    ...

    final Object o = obj;

    obj = null;

    mHandler.post(new Runnable() {

        public void run() {

            useObj(o);

        }

    }

}

... ...

 

示例B:

    假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。

    但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process进程挂掉。

    总之当一个生命周期较短的对象A，被一个生命周期较长的对象B保有其引用的情况下，在A的生命周期结束时，要在B中清除掉对A的引用。

(五) 其他 
    Android应用程序中最典型的需要注意释放资源的情况是在Activity的生命周期中，在onPause()、onStop()、onDestroy()方法中需要适当的释放资源的情况。由于此情况很基础，在此不详细说明，具体可以查看官方文档对Activity生命周期的介绍，以明确何时应该释放哪些资源。

#6

[Android] 内存泄漏调试经验分享 (二)

http://rayleeya.javaeye.com/blog/755657

接上篇：[Android] 内存泄漏调试经验分享 (一) http://rayleeya.javaeye.com/blog/727074

 

三、内存监测工具 DDMS --> Heap 
    无论怎么小心，想完全避免bad code是不可能的，此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件，并以真机为例，在模拟器中的情况类似)。用Heap监测应用进程使用内存情况的步骤如下：

1. 启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的；

2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“Mass Storage”；

3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；

4. 点击选中想要监测的进程，比如system_process进程；

5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标；

6. 点击Heap视图中的“Cause GC”按钮；

7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况［如图所示］。

 



 

说明：

a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作；

b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；

c) 内存使用信息的各项参数根据名称即可知道其意思，在此不再赘述。

 

    如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：

a) 不断的操作当前应用，同时注意观察data object的Total Size值；

b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；

c) 反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，

    直到到达一个上限后导致进程被kill掉。

d) 此处已system_process进程为例，在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间，而当其值超过3.55后进程就会被kill。

 

    总之，使用DDMS的Heap视图工具可以很方便的确认我们的程序是否存在内存泄漏的可能性。

四、内存分析工具 MAT(Memory Analyzer Tool) 
    如果使用DDMS确实发现了我们的程序中存在内存泄漏，那又如何定位到具体出现问题的代码片段，最终找到问题所在呢？如果从头到尾的分析代码逻辑，那肯定会把人逼疯，特别是在维护别人写的代码的时候。这里介绍一个极好的内存分析工具 -- Memory Analyzer Tool(MAT)。

    MAT是一个Eclipse插件，同时也有单独的RCP客户端。官方下载地址、MAT介绍和详细的使用教程请参见：www.eclipse.org/mat，在此不进行说明了。另外在MAT安装后的帮助文档里也有完备的使用教程。在此仅举例说明其使用方法。我自己使用的是MAT的eclipse插件，使用插件要比RCP稍微方便一些。

 

    使用MAT进行内存分析需要几个步骤，包括：生成.hprof文件、打开MAT并导入.hprof文件、使用MAT的视图工具分析内存。以下详细介绍。

(一) 生成.hprof文件 
    生成.hprof文件的方法有很多，而且Android的不同版本中生成.hprof的方式也稍有差别，我使用的版本的是2.1，各个版本中生成.prof文件的方法请参考：

http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/heap-profiling.html;hb=HEAD。

1. 打开eclipse并切换到DDMS透视图，同时确认Devices、Heap和logcat视图已经打开了；

2. 将手机设备链接到电脑，并确保使用“USB 调试”模式链接，而不是“Mass Storage“模式；

3. 链接成功后在Devices视图中就会看到设备的序列号，和设备中正在运行的部分进程；

4. 点击选中想要分析的应用的进程，在Devices视图上方的一行图标按钮中，同时选中“Update Heap”和“Dump HPROF file”两个按钮；

5. 这是DDMS工具将会自动生成当前选中进程的.hprof文件，并将其进行转换后存放在sdcard当中，如果你已经安装了MAT插件，那么此时MAT将会自动被启用，并开始对.hprof文件进行分析；

    注意：第4步和第5步能够正常使用前提是我们需要有sdcard，并且当前进程有向sdcard中写入的权限(WRITE_EXTERNAL_STORAGE)，否则.hprof文件不会被生成，在logcat中会显示诸如

     ERROR/dalvikvm(8574): hprof: can't open /sdcard/com.xxx.hprof-hptemp: Permission denied. 

    的信息。

   

    如果我们没有sdcard，或者当前进程没有向sdcard写入的权限（如system_process），那我们可以这样做：

6. 在当前程序中，例如framework中某些代码中，可以使用android.os.Debug中的：

   public static void dumpHprofData(String fileName) throws IOException

   方法，手动的指定.hprof文件的生成位置。例如：

   xxxButton.setOnClickListener(new View.OnClickListener() {

       public void onClick(View view) {

          android.os.Debug.dumpHprofData("/data/temp/myapp.hprof");

          ... ...

       }

   }

    上述代码意图是希望在xxxButton被点击的时候开始抓取内存使用信息，并保存在我们指定的位置：/data/temp/myapp.hprof，这样就没有权限的限制了，而且也无须用sdcard。但要保证/data/temp目录是存在的。这个路径可以自己定义，当然也可以写成sdcard当中的某个路径。

 

(二) 使用MAT导入.hprof文件 
1. 如果是eclipse自动生成的.hprof文件，可以使用MAT插件直接打开（可能是比较新的ADT才支持）；

2. 如果eclipse自动生成的.hprof文件不能被MAT直接打开，或者是使用android.os.Debug.dumpHprofData()方法手动生成的.hprof文件，则需要将.hprof文件进行转换，转换的方法：

    例如我将.hprof文件拷贝到PC上的/ANDROID_SDK/tools目录下，并输入命令hprof-conv xxx.hprof yyy.hprof，其中xxx.hprof为原始文件，yyy.hprof为转换过后的文件。转换过后的文件自动放在/ANDROID_SDK/tools目录下。OK，到此为止，.hprof文件处理完毕，可以用来分析内存泄露情况了。

3. 在Eclipse中点击Windows->Open Perspective->Other->Memory Analyzer，或者打Memory Analyzer Tool的RCP。在MAT中点击File->Open File，浏览并导入刚刚转换而得到的.hprof文件。

(三) 使用MAT的视图工具分析内存 
    导入.hprof文件以后，MAT会自动解析并生成报告，点击Dominator Tree，并按Package分组，选择自己所定义的Package类点右键，在弹出菜单中选择List objects->With incoming references。这时会列出所有可疑类，右键点击某一项，并选择Path to GC Roots -> exclude weak/soft references，会进一步筛选出跟程序相关的所有有内存泄露的类。据此，可以追踪到代码中的某一个产生泄露的类。

    MAT的界面如下图所示。

 



 

    具体的分析方法在此不做说明了，因为在MAT的官方网站和客户端的帮助文档中有十分详尽的介绍。

    了解MAT中各个视图的作用很重要，例如www.eclipse.org/mat/about/screenshots.php中介绍的。

  

    总之使用MAT分析内存查找内存泄漏的根本思路，就是找到哪个类的对象的引用没有被释放，找到没有被释放的原因，也就可以很容易定位代码中的哪些片段的逻辑有问题了。

 

   至此请各位自己动手，丰衣足食吧！

#7

网上有一篇文章不错

Android_内存泄漏调试.pdf

#8

应用程序的内存检测，楼上很热心，说了不少，很有用的 ：）

至于C部分，那个目前还没辙，最好多用android封装的smart pointer吧

#9

Android避免内存泄露（译）

http://lovezhou.javaeye.com/blog/868754

Android应用程序的内存被限定在16MB，至少在G1手机上是这样。对于一个手机来说，这已经占用了非常多的内存了，但是对于开发者想要实现的目标而言，这些内存是非常少的。即时你本来就没打算用掉所有的内存，但是你应该尽可能的少用内存，来让其他程序可以保持运行，而不是被系统杀掉。系统在内存里保存的应用程序越多，用户在应用程序之间选择切换的速度就会越快。作为我工作的一部分，我跟踪了Android应用程序内存泄露的情况，发现它们大多数是因为同一个问题：保持了对Context对象的长期的引用。 

在Android系统上，很多操作都用到了Context对象，但是大多数都是用来加载和访问资源的。这就是为什么所有的显示控件都需要一个Context对象作为构造方法的参数。在Android应用程序中，你通常可以使用两种Context对象，Activity和Application。当类或者方法需要Context对象的时候，开发者通常会用第一个作为参数。 
@Override 
protected void onCreate(Bundle state) { 
  super.onCreate(state); 
  
  TextView label = new TextView(this); 
  label.setText("Leaks are bad"); 
  
  setContentView(label); 
} 
这就意味着，View对象对整个activity保持引用，因此，也就保持对activity内的所有东西的引用；通常是整个View结构和它所有的资源。所以，如果你一直保持着对Activity的引用，你占用了很多内存。在你不注意的时候，你很容易就持有对activity的长期引用。 
当屏幕方向改变时，默认的，系统会摧毁当前的activity，然后创建一个新的activity，这个新的activity会显示刚才的状态。在这样做的过程中，Android系统会重新加载UI用到的资源。现在假设你的应用程序中有一个比较大的bitmap类型的图片，然而你不想每次旋转时都重新加载它。 
保持屏幕旋转，又不让它重新加载，最简单的方法是用静态变量的方法。 
private static Drawable sBackground; 
  
@Override 
protected void onCreate(Bundle state) { 
  super.onCreate(state); 
  
  TextView label = new TextView(this); 
  label.setText("Leaks are bad"); 
  
  if (sBackground == null) { 
    sBackground = getDrawable(R.drawable.large_bitmap); 
  } 
  label.setBackgroundDrawable(sBackground); 
  
  setContentView(label); 
} 
这样的代码执行起来是快速的，但是是错误的；这样写会一直保持着对activity的引用。当一个Drawable对象附属于一个View时，这个View就相当于drawable对象的一个回调（引用）。在上面的代码片段中，就意味着drawable和TextView存在着引用的关系，而TextView自己引用着activity（Context对象），这个activity又引用着相当多的东西。 
这个例子就是非常简单的泄露Context对象的一种情况，你可以在“ Home screen's source code（ unbindDrawables()方法）”中看到是如何做的，当activity被摧毁时，设置drawable的回调（引用）为null。令人感兴趣的是，有很多种情况，你会创建出一个泄露context对象的链，它们是糟糕的。它们会很快耗光内存，使你的内存溢出。 

有两种简单的方法可以避免由引用context对象造成的内存泄露。最明显的一个方法是，避免context对象超出它的作用范围。上面的例子显展示了静态引用的情况，但是在类的内部，隐式的引用外部的类同样的危险。第二种方法是，使用Application对象。这个context对象会随着应用程序的存在而存在，而不依赖于activity的生命周期。如果你打算对context对象保持一个长期的引用，请记住这个application对象。通过调用Context.getApplicationContext() 或者 Activity.getApplication().方法，你可以很容易的得到这个对象。 

总之，要避免由于引用context对象造成的内存泄露，记住以下几点： 

不要保持对activity的持久引用（对activity的引用应该和activity本身有相同的生命周期） 
尽量使用application代替activity 
如果不能控制非静态的内部类的生命周期，尽量在activity中避免有非静态的内部类，在activity中使用静态的类，要对activity保持弱引用。 
垃圾回收器并不能保证阻止内存泄露 

#10

[经验分享] 关于Java内存泄漏

http://www.opda.com.cn/thread-10343-1-1.html

1 引言
     Java的一个重要优点就是通过垃圾收集器GC （Garbage Collection）自动管理内存的回收，程序员不需要通过调用函数来释放内存。因此，很多程序员认为Java 不存在内存泄漏问题，或者认为即使有内存泄漏也不是程序的责任，而是GC 或JVM的问题。其实，这种想法是不正确的，因为Java 也存在内存泄漏，但它的表现与C++不同。如果正在开发的Java 代码要全天24 小时在服务器上运行，则内存漏洞在此处的影响就比在配置实用程序中的影响要大得多，即使最小的漏洞也会导致JVM耗尽全部可用内存。另外，在很多嵌入式系统中，内存的总量非常有限。在相反的情况下，即便程序的生存期较短，如果存在分配大量临时对象（或者若干吞噬大量内存的对象）的任何Java 代码，而且当不再需要这些对象时也没有取消对它们的引用，则仍然可能达到内存极限。


2 Java 内存回收机制
     Java 的内存管理就是对象的分配和释放问题。分配内存的方式多种多样，取决于该种语言的语法结构。但不论是哪一种语言的内存分配方式，最后都要返回所分配的内存块的起始地址，即返回一个指针到内存块的首地址。在Java 中所有对象都是在堆（Heap）中分配的，对象的创建通常都是采用new或者是反射的方式，但对象释放却有直接的手段，所以对象的回收都是由Java虚拟机通过垃圾收集器去完成的。这种收支两条线的方法确实简化了程序员的工作，但同时也加重了JVM的工作，这也是Java 程序运行速度较慢的原因之一。因为，GC 为了能够正确释放对象，GC 必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都需要进行监控。**对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。Java 使用有向图的方式进行内存管理，可以消除引用循环的问题，例如有三个对象，相互引用，只要它们和根进程不可达，那么GC 也是可以回收它们的。在Java 语言中，判断一块内存空间是否符合垃圾收集器收集标准的标准只有两个：一个是给对象赋予了空值null，以下再没有调用过，另一个是给对象赋予了新值，即重新分配了内存空间。

3 Java 中的内存泄漏

3.1 Java 中内存泄漏与C++的区别
    在Java 中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java 中的内存泄漏，这些对象不会被GC 所回收，然而它却占用内存。在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回来。在Java 中，这些不可达的对象都由GC 负责回收，因此程序员不需要考虑这部分的内存泄漏。通过分析，可以得知，对于C++，程序员需要自己管理边和顶点，而对于Java 程序员只需要管理边就可以了（不需要管理顶点
的释放）。通过这种方式，Java 提高了编程的效率。

3.2 内存泄漏示例
3.2.1 示例1
   在这个例子中，循环申请Object 对象，并将所申请的对象放入一个Vector 中，如果仅仅释放引用本身，那么Vector 仍然引用该对象，所以这个对象对GC 来说是不可回收的。因此，如果对象加入到Vector 后，还必须从Vector 中删除，最简单的方法就是将Vector对象设置为null。
Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{Object o = new Object();
v.add(o);
o = null;
}//

此时，所有的Object 对象都没有被释放，因为变量v 引用这些对象。实际上无用，而还被引用的对象，GC 就无能为力了（事实上GC 认为它还有用），这一点是导致内存泄漏最重要的原因。

(1)如果要释放对象，就必须使其的引用记数为0，只有那些不再被引用的对象才能被释放，这个原理很简单，但是很重要，是导致内存泄漏的基本原因，也是解决内存泄漏方法的宗旨；
(2)程序员无须管理对象空间具体的分配和释放过程，但必须要关注被释放对象的引用记数是否为0；
(3)一个对象可能被其他对象引用的过程的几种：
a.直接赋值，如上例中的A.a = E；
b.通过参数传递，例如public void addObject(Object E)；
c.其它一些情况如系统调用等。


3.3 容易引起内存泄漏的几大原因
3.3.1 静态集合类
      像HashMap、Vector 等静态集合类的使用最容易引起内存泄漏，因为这些静态变量的生命周期与应用程序一致，如示例1，如果该Vector 是静态的，那么它将一直存在，而其中所有的Object对象也不能被释放，因为它们也将一直被该Vector 引用着。
3.3.2 **器
     在java 编程中，我们都需要和**器打交道，通常一个应用当中会用到很多**器，我们会调用一个控件的诸如addXXXListener()等方法来增加**器，但往往在释放对象的时候却没有记住去删除这些**器，从而增加了内存泄漏的机会。
3.3.3 物理连接
         一些物理连接，比如数据库连接和网络连接，除非其显式的关闭了连接，否则是不会自动被GC 回收的。Java 数据库连接一般用DataSource.getConnection()来创建，当不再使用时必须用Close()方法来释放，因为这些连接是独立于JVM的。对于Resultset 和Statement 对象可以不进行显式回收，但Connection 一定要显式回收，因为Connection 在任何时候都无法自动回收，而Connection一旦回收，Resultset 和Statement 对象就会立即为NULL。但是如果使用连接池，情况就不一样了，除了要显式地关闭连接，还必须显式地关闭Resultset Statement 对象（关闭其中一个，另外一个也会关闭），否则就会造成大量的Statement 对象无法释放，从而引起内存泄漏。


3.3.4 内部类和外部模块等的引用
        内部类的引用是比较容易遗忘的一种，而且一旦没释放可能导致一系列的后继类对象没有释放。对于程序员而言，自己的程序很清楚，如果发现内存泄漏，自己对这些对象的引用可以很快定位并解决，但是现在的应用软件并非一个人实现，模块化的思想在现代软件中非常明显，所以程序员要小心外部模块不经意的引用，例如程序员A 负责A 模块，调用了B 模块的一个方法如：public void registerMsg(Object b);这种调用就要非常小心了，传入了一个对象，很可能模块B就保持了对该对象的引用，这时候就需要注意模块B 是否提供相应的操作去除引用。


4 预防和检测内存漏洞
    在了解了引起内存泄漏的一些原因后，应该尽可能地避免和发现内存泄漏。
(1)好的编码习惯。最基本的建议就是尽早释放无用对象的引用，大多数程序员在使用临时变量的时候，都是让引用变量在退出活动域后，自动设置为null。在使用这种方式时候，必须特别注意一些复杂的对象图，例如数组、列、树、图等，这些对象之间有相互引用关系较为复杂。对于这类对象，GC 回收它们一般效率较低。如果程序允许，尽早将不用的引用对象赋为null。另外建议几点：
在确认一个对象无用后，将其所有引用显式的置为null；
当类从Jpanel 或Jdialog 或其它容器类继承的时候，删除该对象之前不妨调用它的removeall()方法；在设一个引用变量为null 值之前，应注意该引用变量指向的对象是否被**，若有，要首先除去**器，然后才可以赋空值；当对象是一个Thread 的时候，删除该对象之前不妨调用它的interrupt()方法；内存检测过程中不仅要关注自己编写的类对象，同时也要关注一些基本类型的对象，例如：int[]、String、char[]等等；如果有数据库连接，使用try...finally 结构，在finally 中关闭Statement 对象和连接。
(2)好的测试工具。在开发中不能完全避免内存泄漏，关键要在发现有内存泄漏的时候能用好的测试工具迅速定位问题的所在。市场上已有几种专业检查Java 内存泄漏的工具，它们的基本工作原理大同小异，都是通过监测Java 程序运行时，所有对象的申请、释放等动作，将内存管理的所有信息进行统计、分析、可视化。开发人员将根据这些信息判断程序是否有内存泄漏问题。这些工具包括Optimizeit Profiler、JProbe Profiler、JinSight、Rational 公司的Purify 等。
[原文摘自]：沃达网-OPDA安卓论坛http://www.opda.com.cn/thread-10343-1-1.html请保留原文地址

#11

关于Android的内存泄漏:如何检测？
http://blog.sina.com.cn/s/blog_3e3fcadd0100m84z.html

Android下的内存泄漏很隐晦呀。

（1） 不同的引用类型：
Java2平台里面引入了java.lang.ref包，这个包中的类可以让我们引用对象，但这些对象可以不用停留在内存中。这些引用类和Java本身的垃圾回收器还存在一定的交互（在垃圾回收的不同阶段）。

Java对引用的分类（Strong reference, SoftReference, WeakReference, PhatomReference）： 级别
 什么时候被垃圾回收
 用途
 生存时间
 
强
 从来不会
 对象的一般状态
 JVM停止运行时终止
 
软
 在内存不足时
 对象简单？缓存
 内存不足时终止
 
弱
 在垃圾回收时
 对象缓存
 gc运行后终止
 
假象
 Unknown
 Unknown
 Unknown
 


（2）Android下怎样避免内存泄漏？
Refer: http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html
有人问：static的Drawable在被重新链入一个TextView后，其callback是否也被重置，即原来的callback被丢弃呢？如果不，Android的实现好像有问题哟！

（3）如何查找内存泄漏：
refer: http://www.cnblogs.com/lbeing/archive/2010/09/29/1838858.html

如何用Memory Analyzer Tool(MAT)来分析，前提是Android开发和测试的工具安装完整，SDK，Eclipse.

更多关于MAT的内容，refer:

   http://blog.csdn.net/studyvcmfc/archive/2010/06/05/5649431.aspx


   http://itnewsvendor.appspot.com/1780002-使用_memory_analyzer.html


1).打开Eclipse

2).选择 Help->Install New Software;

3).在Work with中添加站点：http://download.eclipse.org/mat/1.0/update-site/（这个地址可能会变化，但是新的地址可以在官方网站上找到：http://www.eclipse.org/mat/downloads.php ）

4).生成.hprof文件:插入SD卡（Android机器很多程序都需要插入SD卡），并将设备连接到PC，在Eclipse中的DDMS中选择要测试的进程，然后点击Update Heap 和Dump HPROF file两个Button。

.hprof 文件会自动保存在SD卡上，把 .hprof 文件拷贝到PC上的\ android-sdk-windows\tools目录下。这个由DDMS生成的文件不能直接在MAT打开，需要转换。

运行cmd打开命令行，cd到\ android-sdk-windows \tools所在目录，并输入命令hprof-conv xxxxx.hprof yyyyy.hprof，其中xxxxx.hprof为原始文件，yyyyy.hprof为转换过后的文件。转换过后的文件自动放在android-sdk-windows\tools 目录下。

OK，到此为止，.hprof文件处理完毕，可以用来分析内存泄露情况了。

5).打开MAT：

在Eclipse中点击Windows->Open Perspective->Other->Memory Analysis

6).导入.hprof文件

在MAT中点击 File->Open File,浏览到刚刚转换而得到的.hprof文件，并Cancel掉自动生成报告,点击Dominator Tree，并按Package分组，选择自己所定义的Package 类点右键，在弹出菜单中选择List objects->With incoming references。

这时会列出所有可疑类，右键点击某一项，并选择Path to GC Roots->exclude weak/soft references,会进一步筛选出跟程序相关的所有有内存泄露的类。据此，可以追踪到代码中的某一个产生泄露的类。

#12

Android内存泄漏检测及修复

http://hi.baidu.com/donghaozheng/blog/item/2bbac480830fefda9023d96e.html

最近在查Android系统上的一个内存泄漏的问题，发现利用Android ADT带的DDMS的Heap功能很好用（需要系统默认开放权限较高才行，否则DDMS无权限列出进程，也便不能查看heap的情况）。
利用此功能可监视任何一个进程的heap使用情况，如果有内存泄漏，那么heap使用量就会一直攀升，且能看出大约是什么类型的数据在泄漏。

后来，利用kill -10 加进程ID号的方式，获取了heapdump（data/misc目录下），此heapdump文件用android的工具hprof-conv转换后，可用MAT工具进行分析，从而找到更详细更准确的信息。（MAT非常强大）

在使用MAT时有一些概念不太明白，比如Shallow size, retained size,下面这篇文章蛮有帮助。

1. 使用Memory Analyzer tool(MAT)分析内存泄漏（一）

2.使用Memory Analyzer tool(MAT)分析内存泄漏（二）


另外，应好好读读MAT自带的帮助文件。

Shallow size就是对象本身占用内存的大小，不包含对其他对象的引用，也就是对象头加成员变量（不是成员变量的值）的总和。

Retained size是该对象自己的shallow size，加上只能从该对象直接或间接访问到对象的shallow size之和。换句话说，retained size是该对象被GC之后所能回收到内存的总和。

要理解GC roots的概念。

dominator_tree + group by class功能也蛮好用的。

使用Memory Analyzer tool(MAT)分析内存泄漏（一） 
http://www.blogjava.net/rosen/archive/2010/05/21/321575.html
使用Memory Analyzer tool(MAT)分析内存泄漏（二） 
http://www.blogjava.net/rosen/archive/2010/06/13/323522.html

#13

OPhone/Android应用程序内存泄漏确认与定位(转)---相当不错

http://www.j2megame.com/html/xwzx/ty/1103.html

#14

检查Android本地代码的内存泄漏（Detecting memory leak in Android native code）

http://blog.csdn.net/mayqlzu/archive/2010/07/27/5768126.aspx

#15

Android平台代码内存泄漏检查及Function性能检查

http://hi.baidu.com/glenwang1985/blog/item/d424afc6569371c739db49c6.html

A． 需要使用Eclipse上的一种工具Memory Analyzer (MAT)，官方网址：http://www.eclipse.org/mat/

可以在Eclipse上通过Help – Install New Soft，添加Update Site: http://download.eclipse.org/mat/1.0/update-site/ 进行安装。

B． 从DDMS工具中，Dump HPROF File。


下面以一个例子说明，判断程序是否存在内存泄漏的初步方法

1. 提取到hprof文件后，用MAT打开，首先看Problem Suspect 中 是否存在我们自己的代码类被举报 

2.   打开Histogram视图 ，输入包名的前2个单词，比如 com.***，可以看到所有包下的class类



我们可以发现一共6个类中只有2个存在objects，我们只要按照文档的方法对这2个方法分别运行如下






就会剩下为数不多的几个结果



这个时候我们需要判断剩下来的这个变量、对象是系统自己的还是我们代码未释放的，如上的ApplicationContext应该是基础的Activity，所以不是泄漏， 

但是如下结果



这时就应该评估是不是ArcVEUtils的引用存在泄漏。


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


还有一个部分是对于某个function执行的性能的检查，使用TraceView。

方法一：

Java 代码实现

// start tracing to "/sdcard/yourActivityTrace.trace"  

Debug.startMethodTracing("yourActivityTrace"); 

// ...  

// stop tracing  

Debug.stopMethodTracing(); 



方法二：

DDMS 实现



区别是，如果写在代码中可以指定某个方法，用ddms就是全部了。


接着，以图形方式查看程序跟踪文件

------Inclusive :方法及所有调用函数花费的时间

------Exclusive:方法单独花费时间



 

类别：Android | 浏览(258) | 评论 (0)  上一篇：iPhone和Android的WEB应用开发详...    下一篇：Android下tcpdump-arm的使用说明 最近读者： 登录后，您就出现在这里。       

#16

android内存泄露的问题 

http://www.cnblogs.com/lbeing/archive/2010/09/29/1838858.html

#17

J2ME中的内存泄漏问题

http://blog.sina.com.cn/s/blog_4b8ab89701009n5k.html

J2ME中最常使用的资源无非是图片和声音。为了提高游戏的运行速度，我们通常把它们声明为全局变量，又由于手机的内存的关系，我们不能把这些资源同时加载进内存，所以我们会在使用的时候导入资源（创建对象），而把暂时不需要的资源（图片或声音）对象赋值为null（当然这是我的做法，不知道是否和大家一样）。在这期间如果处理不好，就会有些资源对象的在内存中没有清除干净，就会造成内存泄漏，结果就是可用内存越来越小。下面我就举例说明。
?n u M+|$c;t5j0　　Android J2ME u(U@1| u%FIz-a!B
　　1.图片资源Android J2ME ` V(B;b d2KU
　　要点：要为每一个图片资源声明一个对象变量
x sZ7L�ts[3E~2m0　　假设在一个程序声明了2个图片对象：
8j;db7S!S ^.BV�l0　　　　　　Image pic1,pic2;
os&E+Q\"M#B6x0　　如果在某一时刻要使用pic1和pic2则：
/T ov3x0u){ l0　　　　　　if(pic1==null)pic1=Image.createImage("/1.png");Android J2ME !dk3n[D$J!@#Q
　　　　　　if(pic2==null)pic2=Image.createImage("/2.png");Android J2ME )S'O�e0p3l{'S#L
　　当这些图片用完后，就应当：
(b{6wQU3u0　　　　　　pic1=null;
.iWl3R,~%d0　　　　　　pic2=null;
%A7o VR+m@H0　　如果需要使用另外两个图片3.png和4.png，则最好另声明两个变量对象pic3,pic4来导入它们，不要使用pic1,pic2变量来导入这两个图片，如：Android J2ME (oQ @,m_
　　　　　　if(pic1==null)pic1=Image.createImage("/3.png");//不要这样做Android J2ME "vI"b9UJm s
　　　　　　if(pic2==null)pic2=Image.createImage("/4.png");//不要这样做Android J2ME 3_*L\ eFEl__
　　因为这样做会影响垃圾收集器对pic1,pic2对象的回收工作，从而造成内存回收不干净。
.q8lz-[(lj0　　Android J2ME ;]G*D4m:Bh\.@_
　　2.声音资源（不同的平台对声音的处理方式不同）Android J2ME m8H2C QK@B
　　Android J2ME /I{(j]@
　　要点：和图片资源一样，另外在回收声音资源一定要停止声音的播放；还有在每次开始播放声音前，也要先判断一下声音的状态（简单点，直接调用stop,先让声音停下来，然后再播放），如果不先停止声音的播放，再调用其运行播放，可能会生成无法回收的对象（这是本人猜测的）造成内存的泄漏。
r o,OSS0　　
&YP;k6Z0H i0　　如：
+d{K[jFcB0　　假设sound为声音对象jAndroid J2ME 3V.}4KTw1F!j+h�L.q!R%KN
　　释放sound资源：
9d8J6HY Ne$s{D4K;I0　　　　　　 if(sound!=null)
!V]S0X.m#}3c#f0　　　　　　 {Android J2ME :O6C$L c 

#18

android显示图片内存溢出问题
http://d.187000.com/d_android_tupian_neicun_wenti.html

最近在做一个应用，要循环显示图片，可是图片很大，每个5M左右，如果按图片原来大小显示，在显示两个图片之后必会内存溢出，谁能给个图片压缩显示方法，谢谢！！！
--------------------------------------------------------------------------------
 
以下为可能性最大的答案：
........5M
这个就算recycle也没用了...
我觉得你可以这样，创建一张全局的bitmap（当然要按最大的创建），然后每个图片读取都按照字节的方式读出来，之后set个体这个全局的bitmap，显示的时候就显示这个全局的，一个用完就清空一下，在读取另一张，这样保证只有一个bitmap在占用内存....
--------------------------------------------------------------------------------
recycle并不能及时回收图片，只是告诉虚拟机我需要回收该图片资源，Java中没有手工回收资源的方法。。
1、修改android底层的内存限制。。。放开内存
2、用楼上的做法进行缩放， opts.inSampleSize = 2;表明缩放为原图的长宽各一半。。。用弱引用引用图片，保证及时的回收。。


--------------------------------------------------------------------------------
执行了bitmap.recycle()后，直接让bitmap对象赋予null，这样可以立即释放的。不过要说的是android处理大图片很愁人的，ram太小了，没办法，vm限制也大，哈哈

#19

android 加载图片 内存溢出的问题

我的代码如下

    is = new FileInputStream(new File(baseMagazinePath + this.bookId + "/" + fileList[currentImgNo] + ".png"));
    iv.setImageDrawable(Drawable.createFromStream(is, "myStream"));

有时候出现内存溢出

改为 
    is = new FileInputStream(new File(baseMagazinePath + this.bookId + "/" + fileList[currentImgNo] + ".png"));
    BitmapFactory.Options opts = new BitmapFactory.Options(); 
    opts.inSampleSize = 4;
    Bitmap bitmap = BitmapFactory.decodeStream(is, null, opts); 
    iv.setImageBitmap(bitmap);

就好了。

#20

android显示图片内存溢出问题
http://topic.csdn.net/u/20101112/12/b2a7e85d-56fe-4d00-9ab7-73b7da061129.html

#21

解决Gallery载入大图片导致OutOfMemoryError内存溢出问题
http://www.pocketdigi.com/20101029/138.html

在使用Gallery控件时，如果载入的图片过多，过大，就很容易出现OutOfMemoryError异常，就是内存溢出。这是因为Android默认分配的内存只有8M，而载入的图片如果是JPG之类的压缩格式，在内存中展开时就会占用大量的空间，也就容易内存溢出。这时可以用下面的方法解决：

1
2
3
4
5
6
7
8
9
10
 	      ImageView i = new ImageView(mContext);
	      BitmapFactory.Options options=new BitmapFactory.Options();
          options.inSampleSize = 10;
          //貌似这个options的功能是返回缩略图，10即表示长和宽为原来的1／10，即面积为原来的1／100
          //缩略图可以减少内存占用
	      Bitmap bm = BitmapFactory.decodeFile(lis.
	                            get(position).toString(),options);
	      i.setImageBitmap(bm);
	      bm.recycle();
	      //资源回收 

#22

有效解决android加载大图片内存泄露的问题 

http://zhiweiofli.javaeye.com/blog/905066

#23

Android Bitmap内存限制

http://www.7dot9.com/2010/08/android-bitmap%E5%86%85%E5%AD%98%E9%99%90%E5%88%B6/

#24

[经验分享] bitmap 设置图片尺寸，避免 内存溢出 OutOfMemoryError的优化方法


http://www.devdiv.com/thread-33418-1-1.html

#25

(转)内存溢出的解决办法 Android 
http://www.cppblog.com/iuranus/archive/2010/08/23/124394.html

昨天在模拟器上给gallery放入图片的时候，出现java.lang.OutOfMemoryError: bitmap size exceeds VM budget 异常，图像大小超过了RAM内存。
      模拟器RAM比较小，只有8M内存，当我放入的大量的图片（每个100多K左右），就出现上面的原因。由于每张图片先前是压缩的情况。放入到Bitmap的时候，大小会变大，导致超出RAM内存，具体解决办法如下：

//解决加载图片 内存溢出的问题
                    //Options 只保存图片尺寸大小，不保存图片到内存
                BitmapFactory.Options opts = new BitmapFactory.Options();
                //缩放的比例，缩放是很难按准备的比例进行缩放的，其值表明缩放的倍数，SDK中建议其值是2的指数值,值越大会导致图片不清晰
                opts.inSampleSize = 4;
                Bitmap bmp = null;
                bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);                              
                ...               
               //回收
                bmp.recycle();

通过上面的方式解决了，但是这并不是最完美的解决方式。

通过一些了解，得知如下：

优化Dalvik虚拟机的堆内存分配

对于Android平台来说，其托管层使用的Dalvik Java VM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体 原理我们可以参考开源工程，这里我们仅说下使用方法:   private final static float TARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate时就可以调用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。 

Android堆内存也可自己定义大小

    对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，目前手机厂商对RAM都比较吝啬，对于软件的流畅性来说RAM对 性能的影响十分敏感，除了 优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:

private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;

VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理 

#26

Android 中用 bitmap 内存溢出处理 （一）

http://www.androidegg.com/portal.php?mod=view&aid=1275

Android 中用 bitmap 内存溢出处理 （二）

http://www.androidegg.com/portal.php?mod=view&aid=1274

#27

Android内存泄漏问题的排查.pdf

也是一篇不错的文章

#28

我最近也在查这个问题，MAT不是很好用。有些引用找不到是谁的。
不知道还有没有更好的方法

#29

很好的帖子，帮顶

#30

太好了，总结的很全！！

#31

Java内存也泄露？

#32

有没简单的监控内存泄露的工具?

#33

http://wenku.baidu.com/view/bf788a02b52acfc789ebc9c4.html

#34

我想说，LZ的本意很好，但是这种排版，一般人看不起来。。。

#35

Mark

#36

引用 31 楼 hawkofwinter 的回复:

Java内存也泄露？

确切地说是加速回收，防止溢出。因为android限定app使用大小。

#37

该回复于2012-03-08 08:39:55被版主删除

#38

主要是bitmap 容易内存溢出 这是我的解决方案

http://blog.csdn.net/w237or45/article/details/7333782

#39

收藏了，这个真的很有用！

#40

我定制的系统运行越来越慢，原来存在吃内存的情况。监视可用内存是越来越少。


ActivityManager.MemoryInfo

public long availMem The total available memory on the system. 
public boolean lowMemory Set to true if the system considers itself to currently be in a low memory situation. 
public long threshold The threshold of availMem at which we consider memory to be low and start killing background services and other non-extraneous processes. 

#41

在 JNI 编程中避免内存泄漏
http://www.ibm.com/developerworks/cn/java/j-lo-jnileak/index.html?ca=drs-

#42

Android内存管理  
http://tianhe945.blog.163.com/blog/static/2017531222012417134797/

6.Android框架，每一个进程都有内存限制,可以采用以下方法来躲开这个问题

每一个程序可以通过android.os.Debug.getNativeHeapAllocatedSize（）查看进程可以使用的内存。

一种方法是从本机代码分配内存。使用NDK的（本地开发工具包）和JNI，它可以从C级（如的malloc / free或新/删除），这种分配的内存分配，不计入内存的限制。

另一种方法，效果很好，图像，是使用OpenGL纹理 - 纹理内存同样不被计入内存的限制

据说可以达到300M的内存使用，哪位朋友测试了可以告诉我，这个方法的可行性。