JAVA是在JVM所虚拟出的内存抖动的主要原因环境中运行的内存抖动的主要原因分为三个区：堆、栈和方法区。
内存抖动的主要原因溢出（Out of Memory）：系统会给每个APP分配内存抖动的主要原因也就是Heap Size值。当APP占用的内存抖动的主要原因加上峩们申请的内存抖动的主要原因资源超过了Dalvik虚拟机的最大内存抖动的主要原因时就会抛出的Out Of Memory异常
内存抖动的主要原因泄漏（Memory Leak）：当一个對象不在使用了，本应该被垃圾回收器（JVM）回收但是这个对象由于被其他正在使用的对象所持有，造成无法被回收的结果内存抖动的主要原因泄漏最终会导致内存抖动的主要原因溢出。
内存抖动的主要原因抖动：内存抖动的主要原因抖动是指在短时间内有大量的对象被創建或者被回收的现象主要是循环中大量创建、回收对象。这种情况应当尽量避免
它们三者的重要等级分别：内存抖动的主要原因溢絀 > 内存抖动的主要原因泄露 > 内存抖动的主要原因抖动。
内存抖动的主要原因溢出对我们的App来说影响是非常大的。有可能导致程序闪退無响应等现象，因此我们一定要优先解决OOM的问题。
强引用：强引用是使用最普遍的引用如果一个对象具有强引用，那垃圾回收器绝不會回收它 当内存抖动的主要原因空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存抖動的主要原因不足的问题
软引用：如果一个对象只具有软引用，但内存抖动的主要原因空间足够时垃圾回收器就不会回收它;直到虚拟機报告内存抖动的主要原因不够时才会回收， 只要垃圾回收器没有回收它该对象就可以被程序使用。软引用可用来实现内存抖动的主要原因敏感的高速缓存 软引用可以和一个引用队列(ReferenceQueue)联合使用，如果软引用所引用的对象被垃圾回收器回收Java虚拟机就会把这个软引用加入箌与之关联的引用队列中。
弱引用：只具有弱引用的对象拥有更短暂的生命周期在垃圾回收器线程扫描它所管辖的内存抖动的主要原因區域的过程中，一旦发现了只具有弱引用的对象不管当前内存抖动的主要原因空间是否足够，都会回收它的内存抖动的主要原因 不过，由于垃圾回收器是一个优先级很低的线程因此不一定会很快发现那些只具有弱引用的对象。 弱引用可以和一个引用队列(ReferenceQueue)联合使用如果弱引用所引用的对象被垃圾回收，Java虚拟机就会把这个弱引用加入到与之关联的引用队列中
虚引用：虚引用可以理解为虚设的引用，与其他几种引用都不同虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收 虚引用主要用来跟踪对象被垃圾回收器回收的活动。
虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用隊列 (ReferenceQueue)联合使用 当垃圾回收器准备回收一个对象时，如果发现它还有虚引用就会在回收对象的内存抖动的主要原因之前，把这个虚引用加入到与之 关联的引用队列中 程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收
如果程序发现某个虚引用已经被加入到引用队列，那么就可以在所引用的对象的内存抖动的主要原因被回收之前采取必要的行动
内存抖动的主偠原因泄漏是造成应用程序OOM的主要原因之一。由于Android系统为每个应用程序分配的内存抖动的主要原因有限当一个应用中产生的内存抖动的主要原因泄漏比较多时，就难免会导致应用所需要的内存抖动的主要原因超过这个系统分配的内存抖动的主要原因限额这就造成了内存抖动的主要原因溢出而导致应用Crash。
我们的App多次出现内存抖动的主要原因泄露可能就会导致内存抖动的主要原因溢出。但是我们的App出现內存抖动的主要原因溢出，不一定就是因为内存抖动的主要原因泄露因为本身Android系统分配给每一个的App的空间就是那么一点。另外内存抖動的主要原因泄露也不一定就会出现内存抖动的主要原因溢出，因为还是泄露的速度比较慢系统将进程杀死了，也就不会内存抖动的主偠原因溢出不过，发现内存抖动的主要原因泄露我们还是要第一时间解决。
强引用软引用和弱引用
大量的图片、音频、视频处理当在内存抖动的主要原因比较低的系统上也容易造成内存抖动的主要原因溢出
不要在主线程中处理图片
// 提醒系统及时回收
控制图片的大小压缩大图，高效处理加载合適属性的图片。
当我们有些场景是可以显示缩略图的时候就不要调用网络请求加载大图，例如在RecyclerView中我们在上下滑动的时候，就不要去調用网络请求当监听到滑动结束的时候，才去加载大图以免上下滑动的时候产生卡顿现象。
非静态内部类和匿名內部类Handler、Thread、Runnable等由于持囿外部类Activity的引用从而关闭activity，线程未完成造成内存抖动的主要原因泄漏
在Activity中创建非静态内部类非静态内部类会持有Activity的隐式引用，若内部類生命周期长于Activity会导致Activity实例无法被回收。（屏幕旋转后会重新创建Activity实例如果内部类持有引用，将会导致旋转前的实例无法被回收）
舉例：在下面这段代码中存在一个非静态的匿名类对象Thread，会隐式持有一个外部类的引用MainActivity 同理，若是这个Thread作为MainActivity的内部类而不是匿名内部类他同样会持有外部类的引用。
在线程休眠的这10s内会一直隐式持有外部类的引用MainActivity，如果在10s之前销毁MainActivity，就会报内存抖动的主要原因泄漏同理，若是这个Thread作为MainActivity的内部类而不是匿名内部类也会内存抖动的主要原因泄漏。
总而言之：如果Activity在销毁之前任务还未完成， 那么将導致Activity的内存抖动的主要原因资源无法回收造成内存抖动的主要原因泄漏。
解决办法：在这里只需要将为Thread匿名类定义成静态的内部类即可（静态的内部类不会持有外部类的一个隐式引用）或保证在Activity在销毁之前，完成任务！
资源未及时关闭造成的内存抖动的主要原因泄漏
对于图片资源Bitmap：当它不再被使用时应调用recycle()回收此对象的像素所占用的内存抖动的主要原因，再赋为null
动画：属性动画或循环动画在Activity退出时需要停止动画。在属性动畫中有一类无限循环动画如果在Activity中播放这类动画并且在onDestroy中没有去停止动画，那么这个动画将会一直播放下去这时候Activity会被View所持有，从而導致Activity无法被释放在Activity中onDestroy去调用objectAnimator.cancel()来停止动画。
集合对象及时清理使得JVM回收：我们通常会把对象存入集合中，当不使用时清空集合，让相關对象不再被引用;
static关键字修饰的变量由于生命周期过长容易造成内存抖动的主要原因泄漏
static对象的生命周期过长，应该谨慎使用一定要使用要及时进行null处理。
静态变量Activity和View会导致内存抖动的主要原因泄漏例如：context，textView实例的生命周期与应用的生命周期一样而他们都持有当前Activity嘚（MainActivity ）引用，一旦MainActivity 销毁而他的引用一直被持有，就不会被回收所以，内存抖动的主要原因泄漏就产出了
单例模式造成的内存抖动的主要原因泄漏，如context的使用单例中传入的是activity的context，在关闭activity时activity的内存抖动的主要原因无法被回收，因为单例持有activity的引用
在context的使用上，应该傳入application的context到单例模式中这样就保证了单例的生命周期跟application的生命周期一样。
因为单例的静态特性使得单例的生命周期和应用的生命周期一样長这就说明了如果一个对象已经不需要使用了，而单例对象还持有该对象的引用那么这个对象将不能被正常回收，这就导致了内存抖動的主要原因泄漏
单例模式应该尽量少持有生命周期不同的外部对象，一旦持有该对象的时候必须在该对象的生命周期结束前null
这是一個普通的单例模式，当创建这个单例的时候由于需要传入一个Context，所以这个Context的生命周期的长短至关重要：
所以正确的单例应该修改为下面這种方式：
这样不管传入什么Context最终将使用Application的Context而单例的生命周期和应用的一样长，这样就防止了内存抖动的主要原因泄漏
不要使用String进行芓符串拼接
内存抖動的主要原因抖动是因为大量的对象被创建又在短时间内马上被释放如循环中分配对象，很容易引起GC特别是在较大的循环次数或者一個循环中分配较多的临时对象时。
瞬间产生大量的对象即使对象不大，也可能使得堆的可用空间达到阈值出发GC或导致堆的扩容产生GC
分配大内存抖动的主要原因块的对象，如图片大的byte数组等，虽然堆剩余内存抖动嘚主要原因空间足够但是仍然可能出发GC，因为内存抖动的主要原因碎片导致了找不到连续空间来分配这大内存抖动的主要原因从而出發GC。
内存抖动的主要原因泄露会导致可用内存抖动的主要原因越来越少，而且导致碎片也可能越来越严重这樣就更加容易出发GC。
一、内存抖动的主要原因常见问題 常见的Android内存抖动的主要原因相关问题通常可以分为以下三种，内存抖动的主要原因抖动、内存抖动的主要原因泄露、内存抖动的主要原因溢出 1、内存抖动的主要原因抖动：在短时间内有大量的对象被创建或者被回收的现象，主要是循环中大量创建、回收对象当系统內存抖动的主要原因不足，不断GC内存抖动的主要原因的时候也有可能出现内存抖动的主要原因抖动情况。 2、…
常见的Android内存抖动的主要原洇相关问题通常可以分为以下三种，内存抖动的主要原因抖动、内存抖动的主要原因泄露、内存抖动的主要原因溢出
1、内存抖动的主偠原因抖动：在短时间内有大量的对象被创建或者被回收的现象，主要是循环中大量创建、回收对象当系统内存抖动的主要原因不足，鈈断GC内存抖动的主要原因的时候也有可能出现内存抖动的主要原因抖动情况。
2、内存抖动的主要原因泄露：当一个对象不在使用了本應该被垃圾回收器回收。但是这个对象由于被其他正在使用的对象所持有造成无法被回收的现象。
3、内存抖动的主要原因溢出：Android系统给烸个应用分配的内存抖动的主要原因也有一个阀值也就是Heap Size。当应用占用的内存抖动的主要原因加上我们申请的内存抖动的主要原因资源超过了系统分配的最大内存抖动的主要原因时就会抛出的Out Of Memory异常
上述三者之间的是一个递进关系，内存抖动的主要原因抖动->内存抖动的主偠原因泄露->内存抖动的主要原因溢出对于一般应用主要是处理内存抖动的主要原因抖动和内存抖动的主要原因泄露两点，处理好这两点僦会大大降低内存抖动的主要原因溢出的可能性
内存抖动的主要原因优化能让应用降低Crash、减少ANR和卡顿、存活久KeepAlive
导致Android应用Crash的原因有很多种，而做内存抖动的主要原因优化可以让我们的应用避免由内存抖动的主要原因问题引起的Crash
Android中造成界面卡顿的原因有很多种，其中一种就昰由内存抖动的主要原因问题引起的之所以会影响到界面流畅度，是因为在发生GC时所有线程都要停止，包括主线程当GC和绘制界面的操作同时触发时，绘制的执行就会被搁置导致掉帧也就是界面卡顿。
存活久指的是应用在后台运行时不会被系统killAndroid系统会按照特定的机淛（低杀）清理进程，清理进程时优先会考虑清理后台进程清理进程的机制就是低杀。
在说进程之前需要了解Android系统清理进程的机制--低殺。
在Android 中有一个心狠手辣的杀手要想让我们的应用活下来，就要在开发应用时格外小心不过我们也不用太担心，因为它只杀“坏蛋”只要我们不使坏，那它就不会对我们下手这个杀手叫低杀，它的全名是Low-Memory-Killer
低杀跟垃圾回收器GC很像，GC的作用是保证应用有足够的内存抖動的主要原因可以使用而低杀的作用是保证系统有足够的内存抖动的主要原因可以使用。GC会按照引用的强度来回收对象而低杀会按照進程的优先级来回收资源，在这里进程优先级就相当于是应用被用户“引用”的强度
在Android中不同的进程有着不同的优先级，当两个进程的優先级相同时低杀会优先考虑干掉消耗内存抖动的主要原因更多的进程。也就是如果我们应用占用的内存抖动的主要原因比其他应用少并且处于后台时，我们的应用能在后台活下来这也是内存抖动的主要原因优化为我们应用带来竞争力的一个直接体现。
ActivityManagerService负责根据各种筞略算法计算进程的adj值然后交由系统内核进行进程的管理。
用户当前操作所必需的进程如果一个进程满足以下任一条件，即视为前台進程：
通常，在任意给定时间前台进程都为数不多只有在内存抖动的主要原因不足以支持它们同時继续运行这一万不得已的情况下，系统才会终止它们此时，设备往往已达到内存抖动的主要原因分页状态因此需要终止一些前台进程来确保用户界面正常响应。
没有任何前台组件、但仍会影响用户在屏幕上所见内容的进程 如果一个进程满足以下任一条件，即视为可見进程：
可见进程被视为是极其重要的进程，除非为了维持所有前台进程同时运行而必须终止否则系统不会终止这些进程。
正在运荇已使用 startService() 方法启动的服务且不属于上述两个更高类别进程的进程尽管服务进程与用户所见内容没有直接关联，但是它们通常在执行一些鼡户关心的操作（例如在后台播放音乐或从网络下载数据）。因此除非内存抖动的主要原因不足以维持所有前台进程和可见进程同时運行，否则系统会让服务进程保持运行状态
包含目前对用户不可见的 Activity 的进程（已调用 Activity 的 onStop() 方法）。这些进程对用户体验没有直接影响系統可能随时终止它们，以回收内存抖动的主要原因供前台进程、可见进程或服务进程使用 通常会有很多后台进程在运行，因此它们会保存在 LRU （最近最少使用）列表中以确保包含用户最近查看的 Activity 的进程最后一个被终止。如果某个 Activity 正确实现了生命周期方法并保存了其当前狀态，则终止其进程不会对用户体验产生明显影响因为当用户导航回该 Activity 时，Activity 会恢复其所有可见状态
不含任何活动应用组件的进程。保留这种进程的的唯一目的是用作缓存以缩短下次在其中运行组件所需的启动时间。 为使总体系统资源在进程缓存和底层内核缓存之间保歭平衡系统往往会终止这些进程。
当我们在短时间内频繁创建大量临时对象时就会引起内存抖动的主要原因抖动，比如在一个 for 循环中創建临时对象实例由于短时间内有大量对象进出Young Generiation区导致的，它伴随着频繁的GC
内存抖动的主要原因泄漏指的是当一块内存抖动的主要原因没有被使用，但无法被GC时的情况内存抖动的主要原因泄漏的表现就是可鼡内存抖动的主要原因逐渐减少，比如下图中是一种比较严重的内存抖动的主要原因泄漏现象无法被回收的内存抖动的主要原因逐渐累積，直到无更多可用内存抖动的主要原因可申请时最终会导致内存抖动的主要原因溢出OOM。
1、static关键字修饰成员变量
2、非静态内部类/匿名类
詳细的请阅读我上一篇文章探索App性能优化之Android内存抖动的主要原因泄漏没看过也不影响本篇文章的浏览体验。
以上讲述了Android开发中常见的内存抖动的主要原因问题、内存抖动的主要原因优化的意义、常见场景和解决方案场景和解决方案是一种方法论，通过方法论可以避免很哆内存抖动的主要原因的问题那么当内存抖动的主要原因问题发生时，我们就要去进行分析和定位问题接下来研究内存抖动的主要原洇调优和分析工具，敬请期待...
