内存检测问题
1.如何检测内存问题
内存泄漏:在基于Java的运行中,内存泄漏是一种编程错误,它会导致应用程序对已经不需要再使用对象的引用。所以，无法回收该系统给该对象分配的内存。最终导致OOM(OutOfMemoryError 内存泄漏) 崩溃。
简单来说就是:一些对象有着有限的生命周期。当这些对象所要做的事情完成了，我们希望他们会被回收掉。但是如果有一系列对这个对象的引用，那么在我们期待这个对象生命周期结束的时候被收回的时候，它是不会被回收的。它还会占用内存，这就造成了内存泄露。持续累加，内存很快被耗尽。
通过工具来检测是否错在内存泄漏的问题:
1. 通过Android Studio 自带的工具 Android Profilter 找到MEMORY这个栏目 进行检测
2.LeakCanary
第一步使用LeakCanary 我们需要先导入两个依赖
debugImplementation'com.squareup.leakcanary:leakcanary-android:1.5.4'
releaseImplementation'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'
第二步在我们自定义继承Application类的onCreate()方法里面
如果需要具体的检查内存泄漏的时候：
完成以上操作之后会在我们的手机或者模拟器上生成此应用
LeakCanary会找到并修复 多个内存泄漏问题 将OOM崩溃的几率降低94%。
详解:
https://blog.csdn.net/qq_20280683/article/details/77964208
https://www.cnblogs.com/fuyaozhishang/p/7753013.html
2.内存溢出和泄漏的区别及常见内存问题
1.内存泄漏 memory leak
指程序在申请内存后,被某个对象一直持有,无法释放已申请的内存空间 一次内存泄漏危害可以忽略，但是内存泄漏堆积后果是很严重的。无论你有多少内存，迟早被占光。
内存泄漏又分好几种情况：内存泄漏的分类：以发生的方式来分类，内存泄漏可
以分为 4 类：
1. 常发性内存泄漏。
发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄
漏。
2. 偶发性内存泄漏。
发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发
性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境
和测试方法对检测内存泄漏至关重要。
3. 一次性内存泄漏。
发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块
仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没
有释放该内存，所以内存泄漏只会发生一次。
4. 隐式内存泄漏。
程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说
这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个
服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终
耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏
内存泄漏出现的一些实例：
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 中停止动画。
2.内存溢出 out of memory
指程序在申请内存时，没有足够的内存空间供其使用，出现 out of memory；
比如申请了一个 integer,但给它存了 long 才能存下的数，那就是内存溢出。
内存溢出就是你要求分配的内存超出了系统能给你的，系统不能满足需求，于是
产生溢出。
内存溢出出现的情况：
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 最大的内存大小。
但是这个东西需要慎用，不建议使用
3.内存优化的方案
1.对象引用。强引用、软引用、弱引用、虚引用四种引用类型，根据业务需求合
理使用不同，选择不同的引用类型。
2. 减少不必要的内存开销。注意自动装箱，增加内存复用，比如有效利用系统自
带的资源、视图复用、对象池、Bitmap 对象的复用。
3. 使用最优的数据类型。比如针对数据类容器结构，可以使用 ArrayMap 数据结
构，避免使用枚举类型，使用缓存 Lrucache 等等。
4. 图片内存优化。可以设置位图规格，根据采样因子做压缩，用一些图片缓存方
式对图片进行管理等等
