背景

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

具体参考快手开源自研 OOM 解决方案 KOOM

其他好文

Android OOM案例分析
经典 OOM 问题｜pthread_create (吹爆系列：OOM 不是你们想的那么简单！)
Android性能优化盘点 - 内存优化