Android工业气罐监控系统,Android性能监控（三）：“头号顽疾OOM”监测方案的实践...

背景

业务日益复杂，尤其接入音视频业务后，在视频流、视频编辑、音视频编解码等高内存需求场景中，出现了一些OOM问题，难以复现和定位，而高强度的迭代开发又使得这些OOM问题难以预防和管理，因此急需一种高可用的内存监测方案。

经典的LeakCanary内存泄漏检测工具我们很早就引入到项目中使用，但是很早又去掉了，不好用的原因有以下几点：

经常弹出通知报警，误点击跳转，影响开发体验

dump内存会造成应用冻结，期间不能操作，“卡顿”感严重。而且分析速度很慢且影响本身系统内存占用

不适应多人协作的大项目，问题无优先级，消费困难，历史问题一直累积

大厂怎么做的

其中开源可用的只有快手的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长时间冻结的问题

-不主动触发，通过无性能损耗的内存阈值监控来触发镜像采集。将对象是否泄漏的判断延迟到了解析时。

其他好文