背景
业务日益复杂，尤其接入音视频业务后，在视频流、视频编辑、音视频编解码等高内存需求场景中，出现了一些OOM问题，难以复现和定位，而高强度的迭代开发又使得这些OOM问题难以预防和管理，因此急需一种高可用的内存监测方案。
经典的LeakCanary内存泄漏检测工具我们很早就引入到项目中使用，但是很早又去掉了，不好用的原因有以下几点：
- 经常弹出通知报警，误点击跳转，影响开发体验
- dump内存会造成应用冻结，期间不能操作，“卡顿”感严重。而且分析速度很慢且影响本身系统内存占用
- 不适应多人协作的大项目，问题无优先级，消费困难，历史问题一直累积
大厂怎么做的
抖音 Android 性能优化系列：Java 内存优化篇
Probe：Android线上OOM问题定位组件
快手开源自研 OOM 解决方案 KOOM
西瓜视频稳定性治理体系建设一：Tailor 原理及实践
其中开源可用的只有快手的KOOM和西瓜的Tailor。其开源地址：
KOOM: https://github.com/KwaiAppTeam/KOOM
Tailor:https://github.com/bytedance/tailor
其中KOOM是直接进行线上OOM监控的方案，Tailor只是一种获取内存快照工具，需还需要根据快照进行分析。所以我们选用了使用简单高效的KOOM方案，并且将监控结果上报给AppDump后台（内部bug平台）。
我们的项目实践
使用入口
1.自动上传OOM分析报告
if(BuildConfig.DEBUG){
KoomWrapper.setDebug();
}
KoomWrapper.start(app, new KoomUploader() {
@Override
public void upload(File file) {
if(NTCrashHunterKit.sharedKit().isInit()){
Log.e("KOOM","appDump postFile："+file.getPath());
//上传内部bug平台 ，内部api略
...
}
}
});
那么何时会触发自动OOM分析和上传呢，根据KOOM的设计，“当监测内存RAM占用达到某一阈值且连续升高时”，自动触发。我们调用AppDump接口将这份报告（json文件）上传到AppDump后台。
其中KoomWrapper是对KOOM库的一层封装，关于“当监测内存RAM占用达到某一阈值且连续升高时”在下面“KOOM原理”中说明。
2.手动触发OOM分析。在设置页连续点击N次唤起的线下调试界面入口。
rlKoom.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
KoomWrapper.manualReport();
ToastUtil.showToast(DebugMainActivity.this,"koom正在主动分析，请查看本地cache目录或appDump后台");
}
});
使用环境
该OOM监控工具目前在测试环境接入。测试环境即测试服环境，一般开发测试多数在这个环境，可覆盖开发、各功能分支测试、mtl测试的绝大部分线下场景。后期稳定后，可迁移到线上进行灰度。
if (app_configs.test || app_configs.test.equals("true")) {
implementation("com.xxx.gllib:goldenPin:${GOLDENPIN_VERSION}")
} else {
implementation("com.xxx.gllib:goldenPin-no:${GOLDENPIN_VERSION}")
}
为了使非测试环境的包（线上包）不引入KOOM，不导入无关代码，测试服包和正式服包分别依赖两个不同的库，goldenPin封装了KOOM库，而goldenPin-no库只有一个类KoomWrapper，其start、setDebug等均为空方法，所以正式服相当于只多了一个类的几个空方法，，无任何变量和实现。
KOOM原理
1.何时自动触发OOM分析并上传报告
-RAM占用达到最大阈值，默认95%
-RAM占用达到设定阈值，默认80%，且连续升高N（默认值为3）次，触发逻辑如下
@Override
public boolean isTrigger() {
if (!started) {
return false;
}
HeapStatus heapStatus = currentHeapStatus();
if (heapStatus.isOverMaxThreshold) {
// 已达到最大阀值，强制触发trigger，防止后续出现大内存分配导致OOM进程Crash，无法触发trigger
KLog.i(TAG, "heap used is over max ratio, force trigger and over times reset to 0");
currentTimes = 0;
return true;
}
if (heapStatus.isOverThreshold) {
KLog.i(TAG, "heap status used:" + heapStatus.used / KConstants.Bytes.MB
+ ", max:" + heapStatus.max / KConstants.Bytes.MB
+ ", last over times:" + currentTimes);
if (heapThreshold.ascending()) {
if (lastHeapStatus == null || heapStatus.used >= lastHeapStatus.used || heapStatus.isOverMaxThreshold) {
currentTimes++;
} else {
KLog.i(TAG, "heap status used is not ascending, and over times reset to 0");
currentTimes = 0;
}
} else {
currentTimes++;
}
} else {
currentTimes = 0;
}
lastHeapStatus = heapStatus;
return currentTimes >= heapThreshold.overTimes();
}
3.为何高性能
-使用Copy-on-write机制fork子进程dump，解决了内存镜像dump过程中app长时间冻结的问题
-不主动触发，通过无性能损耗的内存阈值监控来触发镜像采集。将对象是否泄漏的判断延迟到了解析时。
其他好文
Android OOM案例分析
经典 OOM 问题｜pthread_create (吹爆系列：OOM 不是你们想的那么简单！)
Android性能优化盘点 - 内存优化
