内存溢出（out of memery）
定义：APP运行时占用的内存超出系统分配给该APP的内存，就会出现内存溢出。
原因：
递归（解决方法：增加条件），
死循环（解决方法：增加循环时间）
图片加载（主要原因）超大图片（利用压缩工具压缩图片，裁剪，Glide，LRU算法）大量加载图片并没有及时做回收或销毁处理
Fragment大量加载，未做好回收、解除绑定的处理（用replace方法）
大量的内存泄漏
内存泄漏
定义：当activity销毁后，gc在回收该实例的时候，发现该activity被其他对象持有引用，导致该activity不能被回收，出现内存泄漏。
检测：
1，在Android studio3.0以前，在下边有一个Android Monitor,在Android studio3.0以后，将其改为了Android profiler，里边可以分析CPU使用率，内存、包括网络状态，一般检测内存泄漏，只需要点击memory，然后确保移动端启动的程序和studio工具正确连接，如果要检测当前页面是否存在泄漏问题，只需要将该activity finish，然后底部有一个小垃圾桶，他是起到手动触发gc的功能，通过手动回收，然后再去包下查看该应用当前存留的实例，如果刚刚finish并且gc的activity仍然存在，证明在这个activity当中存在内存泄漏。点击额外生成的activity（一般是后边带有$这个符号），一般在studio右边会有泄漏原因的提示，当然具体位置还需要程序员通过经验判断，主动到项目业务中查询。
2，可以使用leakcanary框架，这个相对比较简单，只需要添加依赖，在application启动的时候，判断是否有leakcanary对该进程泄漏的监听，如果没有，在程序启动的时候安装leakcanary即可。
常见案例
1，handler耗时引发的内存泄漏
当activity当中存在handler接收耗时的消息时，比如我们一般在网络请求切换线程时，经常使用到handler，假设消息还没有发送完成，但是页面已经被关闭，也就说activity已经执行了ondestroy方法。当gc回收时，会出现该activity不能被回收的情况，导致内存泄漏。
解决办法：当activity销毁的时候，调用handler的removeCallbacksAndMessages方法，移除消息任务，然后将handler对象及线程置空。
2，内部类引发的内存泄漏（当然handler或子线程一般也作为内部类使用）
因为java当中，内部类默认持有外部类的引用，当外部类销毁后，一旦gc回收该实例，发现内部类持有他的引用而导致不能回收该实例，出现内存泄漏的情况。
解决方法：将内部类改为静态内部类，因为静态内部类生命周期和应用一样长，所以当退出程序的时候会一同回收该实例，并不会影响外部类的回收。
3，单例导致的内存泄漏
因为在使用单例的时候，经常会传入一个本类的上下文对象，而单例是静态的，生命周期和application一样长，当activity销毁的时候，该单例持有activity的引用导致其不能被回收，出现内存泄漏。
解决方法：在使用上下文的时候，传全局上下文。
4，资源未关闭
Cursor，stream，database，Butterknife，broadcastreciver，bindservice，eventBus
比如这些东西在使用完成后，需要进行close或者Unbind处理，以节省内存
5，Bitmap对象不在使用时调用recycle()释放内存
6，Timer计时器、动画，
因为这些涉及耗时问题，如果activity销毁，而该任务并未执行完成，会导致内存泄漏，所以一般在activity中如果使用到这些耗时任务，需要在activity销毁时，做对应处理，比如调用timer的cancel方法，或者动画的cancel方法并将对象置空
7，一些监听器的内存泄漏
比如说我们给edittext设置输入文字监听时，当监听到文字发生变化，我们通过获取变化后的文字执行了耗时任务（比如获取到edittext里的内容上传服务器），当耗时任务未执行完成activity销毁了，会引发内存泄漏，所以在onDestory时，取消注册，比如说editText调用removeTextChangedListener方法
8，Rxjava的内存泄漏：
因为rxjava采用的是观察者模式，当请求到数据后会根据订阅关系将数据发送到订阅者，而如果这时订阅者已经销毁，就会出现引用该对象导致其不能被回收的情况，出现内存泄漏，rxjava2发布的时候也发现了这个问题，所以在回调当中，新增加了onSubcribe回调，同时返回了一个disposable对象，可以通过判断disposable里的isDisposed来确定当前的订阅关系，如果订阅关系中的订阅者已经不存在且当前订阅关系存在，解除订阅关系，并终止数据的发送。
9，webView引发的内存泄漏：
因为webview在使用的时候一般持有activity的引用，我们一般在activity的onDestroy方法中调用mWebView.destroy();来释放webview。如果在onDetachedFromWindow之前调用了destroy那就肯定会无法正常反注册了，也就会导致内存泄漏。所以在销毁webview前一定要先在onDetachedFromWindow中将webview从它的父view中移除，再调用destroy方法中调用webview的destroy，我开发的时候在5.1以上的手机上发现这种问题比较多，因为现在5.1以下适配的比较少了，基本没咋注意。
10，线程导致的内存泄漏：
一般使用子线程都会创建一个内部类对象，而创建线程一般执行耗时任务，所以这个内部类默认持有外部类的引用，如果耗时任务在activity销毁的时候未执行完成，会因为持有外部类引用导致外部类不能被回收
11，MVP内存泄漏：
MVP实现了view层和model层的彻底分离，P层作为view层和model层的中间层，view层需要通过P层执行耗时任务，P层一般持有view的引用，如果m层的耗时任务还没有执行完成，这时候view层被销毁了，会出现由于p持有view的引用导致view不能被回收，出现内存泄漏的问题