1. 内存问题
内存抖动（锯齿状、GC导致卡顿）
内存泄漏：可用内存减少、频繁GC
内存溢出：OOM、程序异常
2.工具
2.1 Memory Profiler（方便直观、线下平时使用）
1）实时图表展示应用内存使用量
2）识别内存泄漏、抖动等
3）提供捕获堆转储（信息转成文件）、强制GC以及跟踪内存分配的能力。
Allocations 代表分配了多少对象。
Shallow Size 是自己的大小。
Retained Size 受我支配的体积大小。
BitmapPreview 可以看到内存中有哪些图片。点击Record 记录内存分配的情况。
Allocation Call stack，知道目标对象在哪里创建的。
2.2 Memory Analyzer
1）强大的Java Heap 分析工具，查找内存泄漏以及内存占用。
2）生成整体报告、分析问题等。
3）线下深入使用。
2.3 LeakCanary
自动内存泄漏检测。线下集成。
3. Android内存管理机制
3.1Java内存分配
| 内存区域 | 描述 |
|---|---|
| 方法区 | 类信息、常量、静态变量等。所有线程共享的。 |
| 虚拟机栈 | 局部变量表、操作数栈等 只是引用。 （为java方法服务） |
| 本地方法栈 | （为native方法服务） |
| 堆 | 所有线程共享。对象实际内存分配。（GC主要作用区域） |
| 程序计数器 | 存储当前方法执行代码执行到了第几行 |
3.2 内存回收算法：
1）标记-清除算法
（标记和清除效率并不高、产生大量不连续的内存碎片）
标记出所有需要回收的对象。
统一回收所有被标记的对象。
2）复制算法
（实现简单、运行相对高效。浪费一半空间，代价大）
将内存划分为大小相等的两块。
一块内存用完之后 复制存活对象到另一块。
清理另一块内存。
3）标记-整理算法
（避免标记-清除导致的内存碎片、避免复制算法的空间浪费）
标记过程与“标记-清除”算法一样
存活对象往一端进行移动
清理其余内存
4）分代收集算法
结合多种收集算法优势
新生代对象存活率低，复制（可以根据比例复制）
老年代对象存活率高，标记-整理
3.4 Android内存管理
内存弹性分配，分配值与最大值受具体设备影响
OOM场景：内存已真正不足、可用内存不足
Dalvik与Art区别
Dalvik仅固定一种回收算法
Art回收算法可运行期选择
Art具备内存整理能力，减少内存空洞
Low Memory Killer
进程分类：前台、可见、服务、后台、空
回收收益：30M还是300M
4. 内存抖动解决实战
内存抖动：内存频繁分配和回收导致内存不稳定
表现：频繁GC、内存曲线呈锯齿状
危害：导致卡顿、OOM
频繁创建对象，导致内存不足及碎片（不连续）
不连续的内存片无法被分配，导致OOM
4.1 实战
使用Memory Profiler 初步排查
使用Memory Profiler或CPU Profiler结合代码排查
找循环或者频繁调用的地方！
5. 内存泄露解决实战
内存泄漏：内存中存在已经没有用的对象
表现：内存抖动、可用内存逐渐变少
危害：内存不足、GC频繁、严重可能导致OOM
内存阶梯状上升。
Memory Analyzer（MAT）
下载链接：https://www.eclipse.org/downloads/download.php
转换：hprof-conv 原文件路径 转换后文件路径
实战：
通过Memory Profiler 初步观察
通过Memory Analyzer结合代码确认
Actions当中点击Histogram，搜索MemoryLeak，查看Object数量
List Object - with incoming reference（被哪些类引用）
- with incoming reference（引用了哪些类）
Path to GC roots all references。左下角有圆圈的对象，找到强引用到底是哪个
5. 全面理解MAT
可被回收但是仍然在内存中的 unreachable_objects
Histogram
donimator_tree 。 percentage 占总共对象的百分比
OQL：SELECT * FROM MemoryLeakActivity
Top consumer 占用内存较多的内存对象
Leak Suspects
6. ARTHook优雅检测不合理图片
Bitmap内存模型
6.1 发展历史
API10之前Bitmap在Dalvik Heap中，像素在Native中。Java层中 Bitmap回收掉了，Native中的像素回收时机不确定。
API10后二者放在了一起。
API26之后像素放在Native当中，让Bitmapjava层回收后很方便地通知Native层。
获取Bitmap占用内存
getByteCount
宽 * 高 * 一像素占用内存
常规方式
背景：图片对内存优化至关重要、图片宽高大于控件宽高。
实现：集成ImageView，覆写实现计算大小。
侵入性强、不通用。
ARTHook实战
轻量级hook的方式
优雅的实现方案。
挂钩，将额外的代码钩住原有的方法，修改执行逻辑。
运行时插桩
性能分析
Epic：一款虚拟机层面、以Java Method为粒度的运行时Hook框架。支持4.0——9.0
https://github.com/tiann/epic
继承 XC_MethodHook,实现响应逻辑。
注入Hook：DexposedBridge.findAndHookMethod
兼容问题大，开源方案不能带到线上环境。通用性好，侵入性低。
7. 线上内存监控方案
常规实现一：
设定场景线上Dump：Debug.dumpHprofData()
超过最大内存80% ——> 内存Dump ——> 回传文件 ——> MAT手动分析
总结：Dump文件太大，和对象数正相关，可裁剪。几十MB大小
上传失败率高、分析困难
配合一定策略，有一定效果
常规实现二：
LeakCanary带到线上：
预设泄漏怀疑点
发现泄漏回传
总结：不适合所有场景，必须预设怀疑点。
问题：分析比较耗时、也容易OOM
Leakcanary原理：
监控生命周期，onDestroy添加RefWatcher检测。
二次确认断定发生内存泄漏。
分析泄漏，找引用链。
监控组件 + 分析组件
LeakCanary 定制：
预设怀疑点 ——> 自动找怀疑点，内存大的对象
分析泄漏链路慢 ——> 改为分析Retain size 大的对象
分析OOm ——> 对象裁剪，不全部加载到内存
完整线上监控方案：
待机内存、重点模块内存、OOM率
整体及重点模块GC次数、GC时间
增强的LeakCanary自动化内存泄漏分析
8. 内存优化技巧总结
优化大方向：优化见效快的地方。内存泄漏、内存抖动、Bitmap
1）Bitmap缓存池不要太大。
2）LargeHeap属性：申请到更多的内存。
3）onTrimMemory时候，主动释放图片内存。
4）使用优化过的集合：SparseArray
5）谨慎使用SharedPreference，第一次加载SharedPreferece会把所有数据load到内存中去。如果内容多的话会影响本地。
6）谨慎使用外部库。
7）业务架构设计合理。比如不要一次将省市县全部拿出，分步拉取。
10 内存优化相关一些问题
1）你们内存优化项目的过程是怎么做的？
- 分析现状、确认问题
- 针对性优化
- 效率提升。工作效率上的提升。
2）你做了内存优化最大的感受是什么？
- 磨刀不误砍柴工。学习google 工具文档。在项目中很快排查定位进行解决。
- 技术优化必须结合业务代码。重点模块进行内存监控。数据上报。监控没有完全结合业务代码
多个图片库，内存缓存不共用，bitmap使用量很高。必须结合业务代码，否则发现不了很多问题。 - 系统性的完善解决方案。
传到服务器。不仅android端，整个回路都参与了设计
3） 如何检测所有不合理的地方？
- ARTHook
- 重点强调区别。继承ImageView 覆写preOnDraw方法。
