程序出现了内存不足的问题。经过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之间相差两三个档次。
