内存抖动概念
在程序里，每创建一个对象，就会有一块内存分配给它；每分配一块内存，程序的可用内存也就少一块；当程序被占用的内存达到一定临界程度，GC 也就是垃圾回收器（Garbage Collector）就会出动，来释放掉一部分不再被使用的内存。
Android 里的 View.onDraw() 方法在每次需要重绘的时候都会被调用，这就意味着，如果你在 onDraw() 里写了创建对象的代码，在界面频繁刷新的时候，你就也会频繁创建出一大批只被使用一次的对象，这就会导致内存占用的迅速攀升；然后很快，可能就会触发 GC 的回收动作，也就是这些被你创建出来的对象被 GC 回收掉。
[垃圾内存]太多了就被清理掉，这是 Java 的工作机制，这不是问题。问题在于，频繁创建这些对象会造成内存不断地攀升，在刚回收了之后又迅速涨起来，那么紧接着就是又一次的回收，对吧？这么往复下来，最终导致一种循环，一种在短时间内反复地发生内存增长和回收的循环。
这种循环往复的状态就像是水波纹的颤动一样，它的专业称呼叫做 Memory Churn，Android 的官方文档里把它翻译做了内存抖动。
简单来说就是： 在程序需要对象的时候，在堆当中分配出来一块空间，使用完毕以后， GC 帮我们清理掉这片内存空间,如果频繁的一直持续上述操作，就会引起内存抖动。
内存抖动原因分析
Android Studio提供了一个 profile的工具，可以帮助我们分析内存情况，在studio的上不有一个表盘的图标
点击红框图标，然后就会运行当前项目，选中连接的手机，然后在studio的底部就会出现一个Android Profile的工具项(如下图)。
我们会看到有CPU,MEMORY,NETWORK三个选项，我们要监控的是内存，所以点击MEMORY，会进入下图
在这张图中我们可以看到我们当前应用所占的内存total，我们这里重点说一下左上角的三个按钮分别是：
- GC手动垃圾回收
- 收集当前页面的内存情况并生成hprof文件
- 记录当前操作的内存情况 首先我们调用GC是当前内存处于稳定状态，然后点击红色按钮开始记录内存状况，然后我们开始在手机上进行操作(一般这个时候会发现平稳的曲线开始波动)，然后我们点击停止按钮，回出现下图的情况。
框框内是我们当前记录的操作区间，当我们点击停止按钮的时候， 在Class Name这个框内，会生成当前记录区间(操作过程)的堆信息。
我们发现我们的曲线有一个向上的陡坡，说明我们的操作造成了大量的内存分配，通过下面堆信息我们来找一下是什么造成了大量的内存分配。
我们发现堆信息是从大到小排列的，而第一条是系统的imageView，明显这里有问题，点击进去发现有大量的imageView对象，点击其中的一个，右下角的框框会显示该对象的具体位置信息。至此我们找到了造成内存抖动的罪魁祸首。
当然，这里的内存抖动是我人为加上去的，比较明显，但是原理是一样的。
内存抖动方案解决
1.集合类
集合类如果仅仅有添加元素的机制，而没有相应删除元素机制，这样就会造成内存被占用，如果这个类是全局性变量（比如类中有静态属性，全局性的map等即有静态引用或final一直指向它）。那么没有相应删除机制，很可能导致集合所占内存只增不减。 解决办法：在使用集合类时，增加删除元素机制，并适当调用减少集合所占内存。
2.单例模式
不正确使用单例模式，也会引起内存泄漏单例对象在初始化后将在JVM的整个生命周期存在（以静态变量方式），如果单例对象持有外部对象的引用，那么这个外部对象就会一直占用着内存，可能导致内存泄漏（取决于这外部对象是否一致有用）。 解决办法：单例对象中避免含有不是一直都有用的外部对象引用。
3.Android组件或特殊集合对象的使用
BraodcastReceiver ,ContentObserver,fileObserver,Cursor,Callback等在Activity onDestory或者某类生命周期结束之后一定要unregistere或者close掉，否则这个Activity类会被system强引用，不会被回收。不要直接对Activity进行直接引用作为成员变量，如果不得不这么做，调用private WeakPeferense mActivity 来做，相同的，对与Service等其他有自己生命周期的对象来说，直接引用都需要考虑是否会存在内存泄露的可能。
4.Handler
要知道，只要Handler 发送的Message尚未被处理，则该Message及发送它的Handler对象将被线程MessageQueue一直持有。由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的。因此这种实现方式一般很难保证跟view或者Activity的生命周期保持一致，故很容易导致无法正确释放。如上所述，Handler使用要特别小心，否则很可能内存泄漏。 解决办法：在view 或者Activity生命周期结束前，确保Handler已没有未处理的消息（特别是延时消息）。
5.Thread 内存泄漏
线程也是造成内存泄露的一个重要源头，线程产生内存泄露的主要原因在于线程生命周期不可控，比如线程是Activity的内部类，则线程对象中保存了Activity的一个引用，当线程的run函数耗时较长没有结束时，线程对象是不会被销毁的，因此它所引用的老的Activity就出现了内存泄漏问题。解决办法：1.简化线程run函数执行的任务，使他在Activity生命周期结束前，任务运行完。2.为Thread增加撤销机制，当Activity生命周期结束时，将Thread的耗时任务撤销（笔者推荐这种）。
6.一些不良代码造成的内存压力
有些代码并不造成内存泄漏，但是他们是对没使用的内存没进行有效及时的释放，或是没有有效的利用已有的对象而是频繁的申请新内存。
(1) Bitmap 没调用recycle()
Bitmap 对象在不使用时，我们应该先调用recycle（）释放内存，然后才置空，因为加载bitmap对象的内存空间，一部分是java的，一部分是c的（因为Bitmap分配的底层是通过jni调用的，Android的Bitmap底层是使用skia图形库实现，skia是用c实现的）。这个recycle（）函数就是针对c部分的内存释放。
（2）构造Adapter时，没有使用缓存的convertView。 解决办法：使用静态holdview的方式构造Adapter。
这样到这里内存抖动和内存泄漏的发现，定位以及解决方法以说明完毕。
内存抖动一直是Android性能优化的重要环节，Android的性能优化除了内存抖动导致的卡顿外，还有布局优化、卡顿优化、启动优化等等。Android性能优化也是大厂面试的必备技术，面试也是被常常问及到的问题。
内存抖动的解决技巧
重点关注：循环或者频繁调用的地方！！ 因为内存抖动就是 内存在被不断地回收及分配， 这种情况的话经常是 出现在 循环或者频繁调用的地方
作者：Coolbreeze
链接：https://juejin.cn/post/7152861867113709605
来源：稀土掘金