概述
主要介绍了内存泄漏的关注点是对象，对内存问题进行了分类并且确定本文关注点是内存泄漏，15种内存泄漏判断方式，hprof文件的用法和分析过程，以及memory profiler工具一些基本概念，最后提到了如何触发内存泄漏问题
内存泄漏的关注点——对象占据的内存
- 本该回收的对象，无法被垃圾处理器回收；
- 程序不再使用的对象，无法被垃圾处理器回收；
- 在页面生命周期销毁后，页面持有、创建过的对象无法被垃圾处理器回收；
- 在任务（线程、Service、广播）结束后，任务持有、创建过的对象无法被垃圾处理器回收
Android内存问题概述
内存抖动的表现形式：
- 忽高忽低，锯齿状
内存泄漏的表现形式：
- 页面或任务已经结束，相关的对象仍然被GC root索引，导致垃圾回收器无法回收，内存片段仍然存在
内存溢出的表现形式：
- App可用内存已到达系统规定的上限，如X型号手机规定单个App最大可分配内存为196mb
- 系统能为App分配的内存不足，系统可分配内存已经到达上限，如系统可用只有1mb，app需要20mb
Android中内存泄漏的判断方式
判断一个对象是否无法被回收，最佳的判断方式是定义清楚这个对象预期的生命周期，通常对象是随着页面、任务的生命周期产生和消亡的，Android中可以借此机制判断是否存在泄漏现象：
PS：“是否存在于hporf文件里”，是笔者用于等价替换原文“未被回收”的字样
- Activity:通过查看Activity#mDestroyed属性来判断Activity是否已经销毁，如果为true，表明该Activity已经被标记为销毁状态，此时hprof文件中若仍然存在此Activity，则表明这个Activity占据的内存处于泄漏状态；
- Fragment：通过Fragment#mFragmentManager属性来判断该Fragment是否处于无用状态，如果mFragmentManager为空，且hprof文件中若仍然存在此Fragment，则表明Fragment占据的内存处于泄漏状态；
- View：通过un wrapper#mContext获得Activity，如果Activity不为空，则按照判断Activity的方式判断Activity是否泄漏
- ContextWrapper：通过unwrapper ContextWrapper获得Activity，如果Activity不为空，则按照判断Activity的方式判断Activity是否泄漏
- Dialog，通过判断mDecor是否为空。mDecor为空，表明Dialog处于不被引用的状态，mDecor仍然存在在hporf里且为空，则表明Dialog泄漏了
- MessageQueue：通过判断MessageQueue#mQuitting或mQuiting是否退出，如果该值是true且未被回收，则认为是泄漏。
- ViewRootImpl：通过ViewRootImpl是否为空来判断，为空表明处于无用状态，为空且未被回收则被认为是泄漏
- Window：通过Window#mDestroyed来判断window是否处于无用状态，mDestroyed为true且未被回收，则认为是泄漏
- Toast：拿到mTN，通过mTN#mView是否为空来判断当前Toast是否已经hide，如果mView为空，表明Toast已经hide，此时Toast未被回收则认为是泄漏
- Editor：Editor是用于TextView处理editable text的辅助类，通过ditor#mTextView为空来判断Ediator是否处于无用状态；如果mTextView为空且未被回收则认为Editor泄漏了
内存泄漏的典型 场景 - 非静态内部类、匿名内部类持有外部类对象的引用：常见的如Listener、CallBack、Handler、Dialog
- 非静态的Handler，持有Activity，Message持有Handler，Message被MessageQueue持有，MessageQueue持久存在，导致Activity不会被释放
- 资源对象未关闭：数据库连接、Cursor、IO流使用完后未close
- 属性动画：未及时使用cancel关闭；Animator持续存在，导致Animator持有的Activity、Fragment、View泄漏（Animator#updateListener一般都是匿名内部类，匿名内部类的问题参考场景1）
- 逻辑问题：广播监听后未及时解注册；
Hprof文件
Hprof文件导出
- 通过调用Debug.dumpHprofData(String filePath)方法来生成hprof文件
- 通过执行shell命令adb shell am dumpheap pid /data/local/tmp/x.hprof来生成指定进程的hprof文件到目标目录
Heap分区：
- app heap：当前App在堆中占据的内存
- image heap：系统启动镜像，包括启动期间预加载的类
- zygote heap：所有App的父进程，所有App共享zygote的内存空间，zygote预加载了许多资源和代码，供所有App读取
Instance View：
- depth：从gc root到当前对象的引用链最短深度。被gc root引用到的对象不会被回收。
- 个人收获：depath = 0，表示不被gc root引用，即会被垃圾回收器回收。
- 个人收获：常见gc root有5种——局部变量、Activity threads、静态变量、JNI引用、类加载器
- native size：native对象占据的内存大小
- shallow size：对象本身占用的内存，何为对象本身？不包括它引用的其他实例
- 个人收获：shallow size = 类定义+ 父类变量所占空间大小 + 类成员变量所占空间 + [ alignment]
- 类定义：固定为8Byte
- 父类变量所占空间大小：当前类继承了其他类的成员变量，显然这些变量是占用空间的
- 自身变量：当前类的成员变量，如果是基本数据类型，则按基本类型计算；如果是引用数据类型，则固定为4byte，当前类仅持有变量名，
- alignment：指位数对齐，目的是让shallow zie的值为8的倍数，如某个类A，前三项计算结果未15byte，则shallo size为了达到8的倍数，会设置一个alignment值，凑够16byte。
- retained size：Retained Size是指, 当实例A被回收时, 可以同时被回收的实例的Shallow Size之和
Instance View易混淆概念：
shallow size：
Shallow Size是指实例自身占用的内存, 可以理解为保存该’数据结构’需要多少内存, 注意不包括它引用的其他实例
retained size：
实例A的Retained Size是指, 当实例A被回收时, 可以同时被回收的实例的Shallow Size之和
图中A, B, C, D四个实例, 为了方便计算, 我们假设所有实例的Shallow Size都是1kb
删除D实例：垃圾回收期会移除D实例;D实例的Retained Size=Shallow Size=1kb
删除C实例：垃圾回收器会移除C和D实例;C实例的Retained Size = C实例的Shallow Size + D实例的Shallow Size = 2kb
删除B实例：垃圾回收器会移除B实例，因为C仍然被A引用，所以C不会被移除，同理D也不会被移除;B实例的Retained Size=Shallow Size=1kb
删除A实例：垃圾回收器会移除B、C、D实例;A实例的Retained Size=4kb
怎么从prof文件内分析内存泄漏？
熟能生巧——memory profiler
实时预览功能区：
Hprof文件预览区：
怎么触发泄漏
- 旋转屏幕
在不同的 activity 状态下，先将设备从竖屏旋转为横屏，再将其旋转回来，这样反复旋转多次。旋转设备经常会使应用泄漏 Activity、Context 或 View 对象，因为系统会重新创建 Activity，而如果应用在其他地方保持对这些对象其中一个的引用，系统将无法对其进行垃圾回收。 - 切换App至前台
在不同的 Activity 状态下，在应用与其他应用之间切换（导航到主屏幕，然后返回到您的应用）。 - 断开后链接网络
- 锁屏后亮屏
- 频繁操作
- 频繁点击按钮，如编辑用户信息，点击保存按钮，触发保存业务
- 频繁进入页面，如重复进入-退出某个页面
- 频繁刷新页面，如重复下拉加载更多
