java虚拟机执行一般都有一个内存界限，超过这个界限，就会报outofmemory。这个时候一般都是存在内存泄漏。解决内存泄漏问题，窃以为分为两个步骤：分析应用程序是否真的有内存泄漏，找到内存泄漏的地方。这两个步骤都不是一般意义上的调试，直接打log，断点调试都不是太给力。动脑筋想一想，内存问题应该在非常多地方上都会出现，这么常见的问题应该是有工具的。android如今更能够说是一个生态系统，当然也有非常多开发辅助工具。在前面的两个步骤中都有非常强大的武器，熟练的掌握这些利器，分析问题就会事半功倍。

        分析是否有内存泄漏一：adb shell dumpsys meminfo package_name（adb shell dumpsys meminfo pid）

        

如上图所看到的，能够直接看出当前应用的内存占用情况。大多数情况下，我们都是关心第一二两行的一二两列。假设我们怀疑某个界面有内存泄漏的情况，就能够通过下面方法来推断。反复的运行这个步骤多次，然后看一下运行前后内存占用情况。假设内存有明显的增长，而且一段时间内没有恢复，基本就能够确认代码中有内存泄漏的地方。
        分析是否有内存泄漏二：DDMS实时查看，注意要在DDMS上显示系统全部进程，这个须要手机有root权限。
选中要分析的进程，进入heap界面，点击Cause GCbutton，之后这个界面会定时刷新。一般仅仅要关注data Object这一行，这个也就是我们的对象占用的内存。java的内存泄漏就是对象使用完没有及时释放导致不能被GC。关注data Object一般直接关注total Size，依据这个值的大小增长来推断当前是否有内存泄漏。相同在一段时间内反复操作某个动作，观察data Object的total Size有木有明显的增长。
        上面的两个方法都是分析应用有木有内存泄漏的问题，主要思想都是反复某一个操作，看看内存有没有明显增长，而且没有恢复。正常的应用都会稳定在一个小的范围内，有问题的应用一般都是持续增长，非常难恢复。两个工具中，一个是手动刷新，一个是自己主动刷新，相比較而言，笔者推荐第一个方法。人工控制，感觉更好。
       发现应用存在内存泄漏是不够的，我们终于目的是解决这个问题。这个时候就须要找到内存泄漏的地方。Eclipse已经为我们提供了强大的内存分析工具MAT,下载地址是：http://www.eclipse.org/mat/。使用这个工具之前，先要生成一个记录进程内存分部情况的HPROF文件，然后使用MAT来分析内存的占用情况。DDMS上有个DUMP HPROF FILE的button，这个就能够直接生成HPROF文件。
        假设eclipse上已经安装了MAT插件，生成的同一时候也就打开了这个文件。只是个人喜欢将MAT单独使用，感觉更快捷更方便。MAT打开了HPROF文件之后，就能显示当前内存占用图。

        

从这个图中的圆形图片就能看出当前哪些地方占用的内存最多。一般内存泄漏都是在这几个地方。图中有个leak suspects的链接，点击就能查看详情了，能看到哪些对象占用了内存。假设某个类有太多的对象，基本上就这个类产生的内存泄漏，找到分配对象的地方，非常快就能找到哪里逻辑不健壮，使用完之后没有及时释放内存。

        分析内存泄漏，找到改动地方都是一剂良药，能一開始就就注意避免兴许的分析才是最好的。