框框内是我们当前记录的操作区间，当我们点击停止按钮的时候， 在Class Name这个框内，会生成当前记录区间(操作过程)的堆信息。

我们发现我们的曲线有一个向上的陡坡，说明我们的操作造成了大量的内存分配，通过下面堆信息我们来找一下是什么造成了大量的内存分配。

我们发现堆信息是从大到小排列的，而第一条是系统的imageView，明显这里有问题，点击进去发现有大量的imageView对象，点击其中的一个，右下角的框框会显示该对象的具体位置信息。至此我们找到了造成内存抖动的罪魁祸首，

当然，这里的内存抖动是我人为加上去的，比较明显，但是原理是一样的。

集合类如果仅仅有添加元素的机制，而没有相应删除元素机制，这样就会造成内存被占用，如果这个类是全局性变量（比如类中有静态属性，全局性的map等即有静态引用或final一直指向它）。那么没有相应删除机制，很可能导致集合所占内存只增不减。 解决办法：在使用集合类时，增加删除元素机制，并适当调用减少集合所占内存。

不正确使用单例模式，也会引起内存泄漏单例对象在初始化后将在JVM的整个生命周期存在（以静态变量方式），如果单例对象持有外部对象的引用，那么这个外部对象就会一直占用着内存，可能导致内存泄漏（取决于这外部对象是否一致有用）。 解决办法：单例对象中避免含有不是一直都有用的外部对象引用。

BraodcastReceiver ,ContentObserver,fileObserver,Cursor,Callback等在Activity onDestory或者某类生命周期结束之后一定要unregistere或者close掉，否则这个Activity类会被system强引用，不会被回收。不要直接对Activity进行直接引用作为成员变量，如果不得不这么做，调用private WeakPeferense mActivity 来做，相同的，对与Service等其他有自己生命周期的对象来说，直接引用都需要考虑是否会存在内存泄露的可能。

要知道，只要Handler 发送的Message尚未被处理，则该Message及发送它的Handler对象将被线程MessageQueue一直持有。由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的。因此这种实现方式一般很难保证跟view或者Activity的生命周期保持一致，故很容易导致无法正确释放。如上所述，Handler使用要特别小心，否则很可能内存泄漏。 解决办法：在view 或者Activity生命周期结束前，确保Handler已没有未处理的消息（特别是延时消息）。

线程也是造成内存泄露的一个重要源头，线程产生内存泄露的主要原因在于线程生命周期不可控，比如线程是Activity的内部类，则线程对象中保存了Activity的一个引用，当线程的run函数耗时较长没有结束时，线程对象是不会被销毁的，因此它所引用的老的Activity就出现了内存泄漏问题。解决办法：1.简化线程run函数执行的任务，使他在Activity生命周期结束前，任务运行完。2.为Thread增加撤销机制，当Activity生命周期结束时，将Thread的耗时任务撤销（笔者推荐这种）。

有些代码并不造成内存泄漏，但是他们是对没使用的内存没进行有效及时的释放，或是没有有效的利用已有的对象而是频繁的申请新内存。

Bitmap 对象在不使用时，我们应该先调用recycle（）释放内存，然后才置空，因为加载bitmap对象的内存空间，一部分是java的，一部分是c的（因为Bitmap分配的底层是通过jni调用的，Android的Bitmap底层是使用skia图形库实现，skia是用c实现的）。这个recycle（）函数就是针对c部分的内存释放。

这样到这里内存抖动和内存泄漏的发现，定位以及解决方法以说明完毕。

内存抖动一直是Android性能优化的重要环节，Android的性能优化除了内存抖动导致的卡顿外，还有布局优化、卡顿优化、启动优化等等。Android性能优化也是大厂面试的必备技术，面试也是被常常问及到的问题。本文可能介绍的不够完全，更多Android性能优化技术可私信：“手册”获取阿里专家特备整理出的《Android性能优化技术手册》，有这方面需求的，想挑战大厂的性能优化是必不可少的技能。

【私信：“手册”获取】Android性能优化解析

重点关注：循环或者频繁调用的地方！！ 因为内存抖动就是 内存在被不断地回收及分配， 这种情况的话经常是 出现在 循环或者频繁调用的地方