程序出现了内存不足的问题。经过DDMS的监控，发现作为一个apk才十来M的程序，竟然把系统最多分配的128M内存占光光。经过一系列曲折的过程，基本查明了所有的问题所在。

内存泄露

为了便于理解，这里把一个对象里引用另一个对象的现象，称为“持有”；把垃圾回收器及其动作，统称为GC；如果A对象持有B对象，B对象又持有C对象，形成一个链条样结构，称为一个持有链。

GC的一个基本方法是“标记-清扫”，就是从堆栈和静态存储区出发，遍历所有的对象和它们所持有的对象，形成一个树形结构(称为引用树)，对于被遍历到的对象进行标记，最后释放掉那些没有被标记的对象。

堆栈和静态存储区里的对象，在这里通常被称为GC Roots。根据这篇文章，静态存储区存保存的对象通常有以下几类：

Class - 由系统类加载器(system class loader)加载的对象

Thread - 活着的线程

Stack Local - Java方法的local变量或参数

JNI Local - JNI方法的local变量或参数

JNI Global - 全局JNI引用

Monitor Used - 用于同步的监控对象

Held by JVM - 用于JVM特殊目的由GC保留的对象，但实际上这个与JVM的实现是有关的。

如果一个对象，直接或者间接地被上面这些GC Roots所持有的话，即使已经没有用了，也不会被GC清理掉，内存泄漏就这样产生了。

这种不合理的持有链通常有以下这些类型：

Android特有的隐式持有

与Java不同地，Android中会发生一些隐式的持有。比如，在一个Activity里，通过调用findById()、getDrawable()等函数的方式，获取到一个画面元素，那么这个元素就会隐式地持有当前的Activity作为mContext。一般情况下，这样并没有问题；但如果这个元素是作为静态对象定义在Activity的类中，就不会被释放，从而导致Activity也不能释放。

Android内存泄漏排查工具：Leak Canary

这个工具引用到项目中后，在程序运行过程中，如果出现了内存泄露，就会自动提示在手机屏幕上；点击通知区域中的相应条目，就可以看到泄露的Activity和相应的持有链，对于分析内存泄漏十分有效。

需要注意的是，因为需要以DebugCompile的方式编译到程序中去，所以这个库只有在Gradle构建的项目中才可以引用，基于Ant的项目就请先迁移到Gradle上去吧。

不合理的图片-DPI对应

现在手机屏幕的效果越来越细腻，除了颜色越来越鲜艳之外，像素密度——DPI也越来越高(所谓的视网膜屏)。Android为了正确处理不同DPI下图片显示的效果，规定了程序的图片按不同的DPI设计多套，分别分别存放在各自的目录下的方法。在程序运行时，由系统挑选最合适的目录进行显示。

按DPI从小到大，这些目录分别为： drawable-ldpi(低)→ drawable-mdpi(中)→ drawable-hdpi(高)→ drawable-xhdpi(超高)→ drawable-xxhdpi(超超高)→ ……

DPI并不等同于屏幕分辨率，也不等同于屏幕尺寸，它们之间的关系简单来说就是： DPI×屏幕尺寸=分辨率。

但是由于这几年的手机尺寸大部分都在5寸上下(需要两只手抱着打电话的那种奇葩没法说)，所以剩下的两个变量，DPI和分辨率之间是有一个粗略的对应关系的，如下表：

在设计图片的时候，如果能按照上面这几种尺寸分别设计好图片，一般来说在分辨率上就不会有太大的偏差。

以上内容其实有点跑题了，那么图片DPI和内存占用之间有什么关系呢？

非常有关系！经过dump heap，找到一些占用内存比较凶狠(5M起)的BitMap对象，对其中mData对象进行保存，并用 XXXXXXX打开(显示出来)，找到这张图片后大吃一惊：一个10KB左右的图片，在内存中竟然占到7MB！

上面这一系列操作的详细方法点这里XXXXXXXXXX和这里XXXXXXXXX(待补充)。 顺便吐槽下，IntelliJ比起Android Studio要先进好几个版本，但是只要程序稍稍多占用点内存的时候，用IntelliJ dump heap完全不行，直接卡死，耽误了好长时间，最后换了Android才完成。

言归正传，为什么一张图片会占用这么大的内存空间？有些老旧的项目，最初不注意DPI的问题，甚至就直接把所有的图片放在drawable下。这种情况下，其实是当作mdpi来处理的。但现在的手机屏幕，动辄都是xhdpi起，和mdpi之间相差两三个档次。