内存泄漏 Memory Leak
对象在内存heap堆中中分配的空间，进程中某些对象已经没有使用价值了，但还是可以直接/间接的引用到GcRoot,导致无法回收，总结一句话就是：本该回收的对象不能被回收而停留在堆内存中，从而产生了内存泄漏。
内存溢出 Out Of Memory
内存溢出是指APP向系统申请超过最大阀值的内存请求，系统不会再分配多余的空间，从而造成内存溢出。总结起来就是，当应用的heap资源超过了Dalvik虚拟机分配的内存就会内存溢出。
关于Android APP的所能申请的最大内存大小是多少， google原生OS的默认值是16M，但是各个厂家的OS会对这个值进行修改。由于Android是开源系统， 不同的手机厂商其实是拥有修改这部分权限能力的，所以就造成了不同品牌和不同系统的手机，对于APP的内存支持也是不一样的，和IOS的恒久100MB是 不同的。一般来说，手机内存的配置越高，厂商也会调大手机支持的内存最大阀值，Oppo find7实测最大内存分配为192MB；小米也有100MB。我们自己可以通过Runtime rt=Runtime.getRuntime();long maxMemory=rt.maxMemory();测试看看不同机型的内存限制。
ANR Application Not Responding
应用无响应
---------------------分割线
（接下来具体分析这三个的产生原因、典型场景、解决或避免的方法）
【Android内存泄漏出现的典型场景】
1.单例--生命周期
分析：因为单例的生命周期和应用程序一样，如果单例对象持有了某个不再需要的对象的引用，（比如Activity的context），那么这个Activty在单例没有被释放前将不会被释放。
解决：我们可以让单例的引用为Application的context
2.Handler
我们经常会在activity中这样使用handler：
class MyHandler extends Handler{
...
}
//使用
MyHandler mHandler=new MyHandler(this);
分析：由于myHandler是Handler的非静态匿名内部类的实例，所以它持有外部类Activity的引用，Looper线程不断轮询处理消息，Activity退出时如果消息队列里还有未处理的消息，消息队列的Message持有mHandler的引用，mHandler又持有Activity的引用，所以导致Activity无法及时被GC回收。从而造成内存泄漏
解决方法：
1.创建静态Handler的匿名内部类 static class MyHandler extends Handler
2.把对Handler持有的对象的使用弱引用 WeakReference context;
3.在Activity销毁时移除消息队列中的任务或消息 handler.removeCallbacksAndMessages(null);取消所有的消息的处理
3.非静态内部类创建静态实例
分析:非静态内部类可以自由使用外部类的所有变量和方法，非静态内部类，它默认持有外部类的引用，此时如果在外部类创建静态static的内部类的实例，或是声明为static静态成员变量，这样就导致内部类的生命周期和应用程序一样长，导致Activity无法正常销毁。
解决方法：将非静态内部类转为静态内部类，这样就不会隐式持有外部类。
4.线程造成的内存泄漏
分析：我们常用的异步任务(如:AsyncTask)和Runnable都是匿名内部类，所以它们对当前的Activity都有一个隐式引用，若Activity销毁，但是线程的任务还没有完成，就会造成Activity的gc无法回收。
解决方法：
1.使用静态内部类 将Runnable内部类、AsyncTask内部类声明为静态。
2.销毁时取消相应的任务。
5.资源未关闭
BroadcastReceiver、File、Cursor、Stream、Bitmap 及时关闭和注销、否则不会被回收造成内存泄漏。
6.系统服务、监听器未注销/移除
有一些系统服务或监听器在不需要使用的时候再及时移除或注销
7.动画
对于有一些属性动画，属性为无限循环，这时候我们可以在onStop中停止动画。
【什么导致内存溢出OOM】
1.对象内存过大(图片、Bitmap、XML)造成内存超出
2.布局重复加载（比如列表控件adapter中没有复用view等）、界面横竖屏切换。应用资源过多，来不及加载。
3.还有我们上面介绍的内存泄漏，过多的内存泄漏，也会导致虚拟机可分配的内存越来越少，这样也是容易出现OOM。
关于避免OOM：
A：减少OOM最重要的就是要尽量减少新分配出来的对象占用内存的大小，尽量使用更加轻量的对象。
避免内存泄漏，见上面我们总结的一些情况（比如：善用static、避免无关引用无法释放、善用SoftReference/WeakReference/LruCache、谨慎handler、线程等、及时关闭无用服务、监听。）
如果代码中有大量字符串拼接操作，使用StringBuilder代替"+"。
Bitmap的不当处理极可能造成OOM，其实很多OOM的原因都来源于此，所以一定要十分重视对Bitmap的优化。
B：一直说OOM的出现是因为应用占用的内存（主要是指的heap）超出了系统给我们分配内存的最大值，那有没有可能增加系统为我们的App分配的内存大小。--->使用largeHeap，会请求系统为Dalvik虚拟机分配更大的内存空间。使用起来也很方便，只需在manifest文件application节点加入android:largeHeap=“true”即可。作为验证，可以通过打印两者的值。ActivityManager.getMemoryClass()获得应用正常情况下内存的大小，ActivityManager.getLargeMemoryClass()可以获得使用largeHeap最大的内存大小。
慎用largeHeap：天下没有免费的午餐，当内存很大的时候，对GC的时间也会有一些影响，性能相比下降，对于本身对内存要求过大的图片或者视频应用，我们可以使用largeHeap。除上面的情况，如果仅仅是为了解OOM这样的问题，而尝试使用largeHeap分配更大内存的这种指标不治本的方法不可取。作为程序员的我们应该努力减少内存的使用，避免内存泄漏，多优化，考虑各种回收和复用，而不是想方设法的增大内存。
【关于ANR】
备注：只有在主线程才会产生ANR，ANR的直观体验是用户在操作App的过程中，感觉界面卡顿，出现ANR对话框。
ANR的产生原因主要为以下三点：
1.主线程View的点击事件或者触摸事件在特定的时间（5s）内无法得到响应。
2.BroadcastReceiver的onReceive()函数运行在主线程中，在特定的时间（10s）内无法完成处理。
3.Service的各个生命周期函数在特定时间（20s）内无法完成处理。
典型的ANR问题场景
应用程序UI线程存在耗时操作。例如在UI线程中进行联网请求，数据库操作或者文件操作等。
应用程序的UI线程等待子线程释放某个锁，导致UI线程等待超时，从而无法处理用户的输入。
耗时的动画需要大量的计算工作，可能导致CPU负载过重。
ANR的避免
主线程避免耗时操作（网络或数据库操作，或者高耗时的计算如改变位图尺寸）把耗时操作放在子线程
主线程不能阻塞，等待子线程的完成——也不是调用 Thread.wait()或是Thread.sleep()。替代的方法是，主线程应该为子线程提供一个Handler，以便完成时能够提交给主线程。
应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。如果响应Intent广播需要执行一个耗时的动作的话，应用程序应该启动一个 Service。
如果你的应用程序在响应Intent广 播时需要向用户展示什么，你应该使用Notification Manager来实现。
【最后】
欢迎大家补充开发中遇见的内存泄漏、内存溢出、ANR的问题场景。
❤️❤️然后给个小心心鼓励一下吧❤️❤️