背景
业务日益复杂,尤其接入音视频业务后,在视频流、视频编辑、音视频编解码等高内存需求场景中,出现了一些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长时间冻结的问题
-不主动触发,通过无性能损耗的内存阈值监控来触发镜像采集。将对象是否泄漏的判断延迟到了解析时。
其他好文