内存优化-进阶篇
内存优化分为：
内存抖动、内存泄露、内存溢出 OOM
1、优秀的架构设计
1.1 MVVM 设计模式
MVC 中 Controller 的生命周期远大于 View。
MVP 中 View 会持有 Presenter 引用，二者生命周期也不同步。
Jepact 框架 MVVM 中 ViewModel 跟 View 是完全独立的，当 Activity 销毁时，ViewModel 中未执行完的数据处理不会导致内存泄露。Lifecycle 也能感知 Activity 的生命周期，根据 Activity 的生命周期进行相应的回调。
1.2 统一管理
统一缓存管理：监听OnTrimMemory回调，当系统内存不足时，根据不同的状态释放内存
统一图片加载库
统一的网络请求库
......
2、设备分级
同一个应用在4G以上的内存手机运行流程，但是在2G以下的低端机卡顿。
2.1 设备分级
根据设备的年限-内存-Android版本号进行分级。
对于低端机用户关闭复杂动画，或者某些功能；使用RGB 565格式的图片，使用更小的缓存内存等。
2.2 合理使用进程
合理管理App的进程，一个空的进程也会占用10MB左右的内存，为了进程保活，启动了很多进程进行相互拉活。
对于低端机来说，减少应用启动进程数目、减少常驻进程、有节操的保活。
2.3 安装包的大小
针对低端机用户推出轻量的极速版APk，例如今日头条极速版、QQ轻聊版。
3、 Bitmap优化
Bitmap内存在Android 3.0以下放在native中，3.0-8.0放到Java内存中，8.0以上又放到native中。
3.1 统一图片库
项目所有的moudel中使用统一的图片管理机制，收拢图片的调用。
低端机使用565格式、更加严格的缩放算法、Glide使用low模式的内存加载。
使用webp图片，webp图片跟png图片相比减少了至少四分之一的内存占用。
3.2 统一图片监控
-
大图片监控
如果图片的尺寸远大于view的尺寸，或者不合规的图片使用，开发过程中弹出dialog提示。
在灰度和线上环境下可以将异常信息上报到后台，我们可以计算有多少比例的图片会超过屏幕的大小，也就是图片的“超宽率”。
-
重复图片监控
Bitmap 的像素数据完全一致，但是有多个不同的对象存在。
解决重复图片，减少内存占用。
-
图片总内存
通过收拢图片的使用，可以统计出应用所有图片内存占用，线上可以根据不同的系统、屏幕分辨率等维度去分析图片的内存占用情况。
在OOM奔溃时，将图片的总内存都写到奔溃日志中了，帮助排查问题。
4、监控
4.1 Java 内存泄漏
-
内存泄露监控
LeakCanary 自动化检测方案，至少做到 Activity 和 Fragment 的泄漏检测。
-
开发过程规避
四大块：集合类导致、单例/静态变量导致、匿名内部类/非静态内部类、页面销毁未注销导致
4.2 OOM 监控
暂时找不到合适的方法，待学习。
3.3 线上监控
抽取线上部分用户，应用在前台时，可以每 5 分钟采集一次 PSS、Java 堆、图片总内存。
4.4 Native 内存泄漏监控
不懂，待学习。
4.5 GC 监控
5、兜底方案
5.1 BaseActivity 的 onDestory() 统一兜底
在Activity onDestory的时候，遍历View树，清空 backGround、Drawable、EditText 的 TextWatcher 等
private void traverse(ViewGroup root) {
final int childCount = root.getChildCount();
for (int i = 0; i < childCount; ++i) {
final View child = root.getChildAt(i);
if (child instanceof ViewGroup) {
child.setBackground(null);
traverse((ViewGroup) child);
} else {
if (child != null) {
child.setBackground(null);
}
if (child instanceof ImageView) {
((ImageView) child).setImageDrawable(null);
} else if (child instanceof EditText) {
((EditText) child).cleanWatchers();
}
}
}
}
5.2 Handler 定时监控
后台监控内存，起一个HandlerThread，一直在后台拿内存使用的状态，如果应用内存占用超过总内存的 80%，及时释放一些内存。
具体代码：MemoryHandler.java
5.3 特定情况重启
如果短时间上不会造成 OOM，但在长时间的使用中，会使得应用占用内存越积越大，最终也会造成 OOM 情况发生。
在用户无感知的情况下，在接近触发系统异常前，选择合适的场景杀死进程并将其重启，使得应用的内存占用回到正常情况。
主要考虑了几种条件：
- 是否在主界面退到后台 且 位于后台的时间超过 30 分钟
- 当前时间为凌晨 2～5 点
- 不存在前台服务（存在通知栏，音乐播放栏等情况）
- java heap 必须大于当前进程最大可分配的 85% || native 内存大于 800M || vmsize 超过了 4G的 85%
- 非大量的流量消耗（每分钟不超过 1M） && 进程无大量 CPU 调度情况
