快手线上 OOM 监控方案 - KOOM 分析

作者：Stan_z
链接：https://juejin.cn/post/6991374693403983886

快手在2020年中旬开源了一个线上OOM监控上报的框架：KOOM，这里简单研究下。

项目地址：https://github.com/KwaiAppTeam/KOOM/tree/v1.0.5

一、官方项目介绍

1.1 描述：

KOOM是快手性能优化团队在处理移动端OOM问题的过程中沉淀出的一套完整解决方案。其中Android Java内存部分在LeakCanary的基础上进行了大量优化，解决了线上内存监控的性能问题，在不影响用户体验的前提下线上采集内存镜像并解析。从 2020 年春节后在快手主APP上线至今解决了大量OOM问题，其性能和稳定性经受住了海量用户与设备的考验，因此决定开源以回馈社区。

1.2 特点：

• 比leakCanary更丰富的泄漏场景检测；

• 比leakCanary更好的检测性能；

• 功能全面的支持线上大规模部署的闭环监控系统；

1.3 KOOM框架

image.png

1.4 快手KOOM核心流程包括：

• 配置下发决策；

• 监控内存状态；

• 采集内存镜像；

• 解析镜像文件(以下简称hprof)生成报告并上传；

• 问题聚合报警与分配跟进。

1.5 泄漏检测触发机制优化：

泄漏检测触发机制leakCanary做法是GC过后对象WeakReference一直不被加入 ReferenceQueue，它可能存在内存泄漏。这个过程会主动触发GC做确认，可能会造成用户可感知的卡顿，而KOOM采用内存阈值监控来触发镜像采集，将对象是否泄漏的判断延迟到了解析时，阈值监控只要在子线程定期获取关注的几个内存指标即可，性能损耗很低。

image.png

1.6 heap dump优化：

传统方案会冻结应用几秒，KOOM会fork新进程来执行dump操作，对父进程的正常执行没有影响。暂停虚拟机需要调用虚拟机的art::Dbg::SuspendVM函数，谷歌从Android 7.0开始对调用系统库做了限制，快手自研了kwai-linker组件，通过caller address替换和dl_iterate_phdr解析绕过了这一限制。

image.png

随机采集线上真实用户的内存镜像，普通dump和fork子进程dump阻塞用户使用的耗时如下：

image.png

而从官方给出的测试数据来看，效果似乎是非常好的。

二、官方demo演示

这里就直接跑下官方提供的koom-demo

点击按钮，经过dump heap -> heap analysis -> report cache/koom/report/三个流程(heap analysis时间会比较长，但是完全不影响应用的正常操作),最终在应用的cache/koom/report里生成json报告：

1cepheus:/data/data/com.kwai.koom.demo/cache/koom/report # ls
22020-12-08_15-23-32.json
3复制代码

模拟一个最简单的单例CommonUtils持有LeakActivity实例的内存泄漏，看下json最终上报的内容是个啥：

 1{
 2   "analysisDone":true,
 3   "classInfos":[
 4       {
 5           "className":"android.app.Activity",
 6           "instanceCount":4,
 7           "leakInstanceCount":3
 8       },
 9       {
10           "className":"android.app.Fragment",
11           "instanceCount":4,
12           "leakInstanceCount":3
13       },
14       {
15           "className":"android.graphics.Bitmap",
16           "instanceCount":115,
17           "leakInstanceCount":0
18       },
19       {
20           "className":"libcore.util.NativeAllocationRegistry",
21           "instanceCount":1513,
22           "leakInstanceCount":0
23       },
24       {
25           "className":"android.view.Window",
26           "instanceCount":4,
27           "leakInstanceCount":0
28       }
29   ],
30   "gcPaths":[
31       {
32           "gcRoot":"Local variable in native code",
33           "instanceCount":1,
34           "leakReason":"Activity Leak",
35           "path":[
36               {
37                   "declaredClass":"java.lang.Thread",
38                   "reference":"android.os.HandlerThread.contextClassLoader",
39                   "referenceType":"INSTANCE_FIELD"
40               },
41               {
42                   "declaredClass":"java.lang.ClassLoader",
43                   "reference":"dalvik.system.PathClassLoader.runtimeInternalObjects",
44                   "referenceType":"INSTANCE_FIELD"
45               },
46               {
47                   "declaredClass":"",
48                   "reference":"java.lang.Object[]",
49                   "referenceType":"ARRAY_ENTRY"
50               },
51               {
52                   "declaredClass":"com.kwai.koom.demo.CommonUtils",
53                   "reference":"com.kwai.koom.demo.CommonUtils.context",
54                   "referenceType":"STATIC_FIELD"
55               },
56               {
57                   "reference":"com.kwai.koom.demo.LeakActivity",
58                   "referenceType":"instance"
59               }
60           ],
61           "signature":"378fc01daea06b6bb679bd61725affd163d026a8"
62       }
63   ],
64   "runningInfo":{
65       "analysisReason":"RIGHT_NOW",
66       "appVersion":"1.0",
67       "buildModel":"MI 9 Transparent Edition",
68       "currentPage":"LeakActivity",
69       "dumpReason":"MANUAL_TRIGGER",
70       "jvmMax":512,
71       "jvmUsed":2,
72       "koomVersion":1,
73       "manufacture":"Xiaomi",
74       "nowTime":"2020-12-08_16-07-34",
75       "pss":32,
76       "rss":123,
77       "sdkInt":29,
78       "threadCount":17,
79       "usageSeconds":40,
80       "vss":5674
81   }
82}
83复制代码

这里主要分三个部分：类信息、gc引用路径、运行基本信息。这里从gcPaths中能看出LeakActivity被CommonUtils持有了引用。

框架使用这里参考官方接入文档即可，这里不赘述：github.com/KwaiAppTeam…

三、框架解析

3.1 类图

image.png

3.2 时序图

KOOM初始化流程

image.png

KOOM执行初始化方法，10秒延迟之后会在threadHandler子线程中先通过check状态判断是否开始工作，工作内容是先检查是不是有未完成分析的文件，如果有就就触发解析，没有则监控内存。

heap dump流程

image.png

HeapDumpTrigger

• startTrack：监控自动触发dump hprof操作。开启内存监控，子线程5s触发一次检测，看当前是否满足触发heap dump的条件。条件是由一系列阀值组织，这部分后面详细分析。满足阀值后会通过监听回调给HeapDumpTrigger去执行trigger。

• trigger:主动触发dump hprof操作。这里是fork子进程来处理的，这部分也到后面详细分析。dump完成之后通过监听回调触发HeapAnalysisTrigger.startTrack触发heap分析流程。

heap analysis流程

image.png

HeapAnalysisTrigger

• startTrack 根据策略触发hprof文件分析。

• trigger 直接触发hprof文件分析。由单独起进程的service来处理，工作内容主要分内存泄漏检测（activity/fragment/bitmap/window）和泄漏数据整理缓存为json文件以供上报。

四、核心源码解析

经过前面的分析，基本上对框架的使用和结构有了一个宏观了解，这部分就打算对一些实现细节进行简单分析。

4.1 内存监控触发dump规则

这里主要是研究HeapMonitor中isTrigger规则，每隔5S都会循环判断该触发条件。

 1com/kwai/koom/javaoom/monitor/HeapMonitor.java
 2@Override
 3public boolean isTrigger() {
 4  if (!started) {
 5   return false;
 6  }
 7  HeapStatus heapStatus = currentHeapStatus();
 8  if (heapStatus.isOverThreshold) {
 9   if (heapThreshold.ascending()) {
10     if (lastHeapStatus == null || heapStatus.used >= lastHeapStatus.used) {
11       currentTimes++;
12     } else {
13       currentTimes = 0;
14     }
15   } else {
16     currentTimes++;
17   }
18  } else {
19   currentTimes = 0;
20  }
21  lastHeapStatus = heapStatus;
22  return currentTimes >= heapThreshold.overTimes();
23}
24private HeapStatus lastHeapStatus;
25private HeapStatus currentHeapStatus() {
26  HeapStatus heapStatus = new HeapStatus();
27  heapStatus.max = Runtime.getRuntime().maxMemory();
28  heapStatus.used = Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();
29  heapStatus.isOverThreshold = 100.0f * heapStatus.used / heapStatus.max > heapThreshold.value();
30  return heapStatus;
31}
32
33com/kwai/koom/javaoom/common/KConstants.java
34
35public static class HeapThreshold {
36  public static int VM_512_DEVICE = 510;
37  public static int VM_256_DEVICE = 250;
38  public static int VM_128_DEVICE = 128;
39  public static float PERCENT_RATIO_IN_512_DEVICE = 80;
40  public static float PERCENT_RATIO_IN_256_DEVICE = 85;
41  public static float PERCENT_RATIO_IN_128_DEVICE = 90;
42
43  public static float getDefaultPercentRation() {
44   int maxMem = (int) (Runtime.getRuntime().maxMemory() / MB);
45   if (maxMem >= VM_512_DEVICE) {
46     return KConstants.HeapThreshold.PERCENT_RATIO_IN_512_DEVICE;
47   } else if (maxMem >= VM_256_DEVICE) {
48     return KConstants.HeapThreshold.PERCENT_RATIO_IN_256_DEVICE;
49   } else if (maxMem >= VM_128_DEVICE) {
50     return KConstants.HeapThreshold.PERCENT_RATIO_IN_128_DEVICE;
51   }
52   return KConstants.HeapThreshold.PERCENT_RATIO_IN_512_DEVICE;
53  }
54
55  public static int OVER_TIMES = 3;
56  public static int POLL_INTERVAL = 5000;
57}
58复制代码

这里就是针对不同内存大小做了不同的阀值比例：

• 应用内存>512M 80%

• 应用内存>256M 85%

• 应用内存>128M 90%

• 低于128M的默认按80%

应用已使用内存/最大内存超过该比例则会触发heapStatus.isOverThreshold。连续满足3次触发heap dump，但是这个过程会考虑内存增长性，3次范围内出现了使用内存下降或者使用内存/最大内存低于对应阀值了则清零。

因此规则总结为：3次满足>阀值条件且内存一直处于上升期才触发。这样能减少无效的dump。

4.2 fork进程执行dump操作实现

这里先对比下目前市面上三方框架的主流实现方案：

image.png

LeakCanaray、Matrix、Probe采用的方案：
直接执行Debug.dumpHprofData()，它执行过程会先挂起当前进程的所有线程，然后执行dump操作，生成完成hprof文件之后再唤醒所有线程。整个过程非常耗时，会带来比较明显的卡顿，因此这个痛点严重影响该功能带到线上环境。

KOOM采用的方案:
主进程fork子进程来处理hprof dump操作，主进程本身只有在fork 子进程过程会短暂的suspend VM, 之后耗时阻塞均发生在子进程内，对主进程完全不产生影响。suspend VM本身过程时间非常短，从测试结果来看完全可以忽略不计

接下来详细分析下fork dump方案的实现：目前项目中默认使用ForkJvmHeapDumper来执行dump。

 1com/kwai/koom/javaoom/dump/ForkJvmHeapDumper.java
 2@Override
 3public boolean dump(String path) {
 4  boolean dumpRes = false;
 5  try {
 6   int pid = trySuspendVMThenFork();//暂停虚拟机，copy-on-write fork子进程
 7   if (pid == 0) {//子进程中
 8     Debug.dumpHprofData(path);//dump hprof
 9     exitProcess();//_exit(0) 退出进程
10   } else {//父进程中
11     resumeVM();//resume当前虚拟机
12     dumpRes = waitDumping(pid);//waitpid异步等待pid进程结束
13   }
14  } catch (Exception e) {
15   e.printStackTrace();
16  }
17  return dumpRes;
18}
19复制代码

为什么需要先suspendVM然后再fork?
起初我理解主要是让fork前后的内存镜像保存一致性，但是对于内存泄漏来说这个造成的影响并不大，demo直接fork好像也没有什么问题，何况这块做了大量工作绕过Android N的限制去suspendVM肯定是有其必要性的。
最终才发现，单线程是没问题的，因为线程已经停了，demo加多线程dump会卡在suspendVM。因此需要先suspendVM，再fork，最后resumeVM。

好，确认工作流之后，来尝试实现：

native层：

这里fork、waitPid 、exitProcess都比较简单，直接忽略，重点看vm相关操作：

正常操作就应该是：

1void *libHandle = dlopen("libart.so", RTLD_NOW);//打开libart.so, 拿到文件操作句柄
2void *suspendVM = dlsym(libHandle, LIBART_DBG_SUSPEND);//获取suspendVM方法引用
3void *resumeVM = dlsym(libHandle, LIBART_DBG_RESUME);//获取resumeVM方法引用
4dlclose(libHandle);//关闭libart.so文件操作句柄
5复制代码

这在Android N以下的版本这么操作是OK了，但是谷歌从Android 7.0开始对调用系统库做了限制，基于此前提，快手自研了kwai-linker组件，通过caller address替换和dl_iterate_phdr解析绕过了这一限制，官方文档对限制说明，那么接下来就分析下KOOM是如何绕过此限制的。

源码参考：Android 9.0

 1/bionic/libdl/libdl.cpp
 202__attribute__((__weak__))
 3103void* dlopen(const char* filename, int flag) {
 4104  const void* caller_addr = __builtin_return_address(0);//得到当前函数返回地址
 5105  return __loader_dlopen(filename, flag, caller_addr);
 6106}
 7
 8/bionic/linker/dlfcn.cpp
 9152void* __loader_dlopen(const char* filename, int flags, const void* caller_addr) {
10153  return dlopen_ext(filename, flags, nullptr, caller_addr);
11154}
12
13131static void* dlopen_ext(const char* filename,
14132                        int flags,
15133                        const android_dlextinfo* extinfo,
16134                        const void* caller_addr) {
17135  ScopedPthreadMutexLocker locker(&g_dl_mutex);
18136  g_linker_logger.ResetState();
19137  void* result = do_dlopen(filename, flags, extinfo, caller_addr);//执行do_dlopen
20138  if (result == nullptr) {
21139    __bionic_format_dlerror("dlopen failed", linker_get_error_buffer());
22140    return nullptr;
23141  }
24142  return result;
25143}
26
27/bionic/linker/linker.cpp
282049void* do_dlopen(const char* name, int flags,
292050                const android_dlextinfo* extinfo,
302051                const void* caller_addr) {
312052  std::string trace_prefix = std::string("dlopen: ") + (name == nullptr ? "(nullptr)" : name);
322053  ScopedTrace trace(trace_prefix.c_str());
332054  ScopedTrace loading_trace((trace_prefix + " - loading and linking").c_str());
342055  soinfo* const caller = find_containing_library(caller_addr);
352056  android_namespace_t* ns = get_caller_namespace(caller);
36...
372141  return nullptr;
382142}
39复制代码

这里dlopen最终执行是通过__loader_dlopen，只不过默认会传入当前函数地址，这个地址其实就是做了caller address校验，如果检测出是三方地址则校验不通过，这里传入系统函数地址则能通过校验，例如dlerror。

那么KOOM的做法是：

大于N小于Q的Android版本

1using __loader_dlopen_fn = void *(*)(const char *filename, int flag, void *address);
2void *handle = ::dlopen("libdl.so", RTLD_NOW);//打开libel.so
3//这里直接调用其__loader_dlopen方法，它与dlopen区别是可以传入caller address
4auto __loader_dlopen = reinterpret_cast<__loader_dlopen_fn>(::dlsym(handle,"__loader_dlopen"));
5__loader_dlopen(lib_name, flags, (void *) dlerror);//传入dlerror系统函数地址，保证caller address校验通过，绕过Android N限制。
6复制代码

Android Q及其以上的版本

因为Q引入了runtime namespace，因此__loader_dlopen返回的handle为nullptr

这里通过dl_iterate_phdr在当前进程中查询已加载的符合条件的动态库基对象地址。

 1int DlFcn::dl_iterate_callback(dl_phdr_info *info, size_t size, void *data) {
 2    auto target = reinterpret_cast<dl_iterate_data *>(data);
 3   if (info->dlpi_addr != 0 && strstr(info->dlpi_name, target->info_.dlpi_name)) {
 4        target->info_.dlpi_addr = info->dlpi_addr;
 5       target->info_.dlpi_phdr = info->dlpi_phdr;
 6       target->info_.dlpi_phnum = info->dlpi_phnum;
 7       // break iterate
 8       return 1;
 9   }
10
11    // continue iterate
12   return 0;
13}
14
15dl_iterate_data data{};
16data.info_.dlpi_name = "libart.so";
17dl_iterate_phdr(dl_iterate_callback, &data);
18CHECKP(data.info_.dlpi_addr > 0)
19handle = __loader_dlopen(lib_name, flags, (void *) data.info_.dlpi_addr);
20复制代码

这里dl_iterate_callback会回调当前进程所装载的每一个动态库，这里过滤出libart.so对应的地址：data.info_.dlpi_addr，再通过__loader_dlopen尝试打开libart.so。

附：

1struct dl_phdr_info {
2  ElfW(Addr) dlpi_addr;//基对象地址
3  const ElfW(Phdr)* dlpi_phdr;//指针数组
4  ElfW(Half) dlpi_phnum;//
5...
6};
7复制代码

这便是快手自研的kwai-linker组件通过caller address替换和dl_iterate_phdr解析绕过Android 7.0对调用系统库做的限制的具体实现。也是fork dump方案的核心技术点。

4.3 内存泄漏检测实现

内存泄漏检测核心代码在于SuspicionLeaksFinder.find

 1public Pair<List<ApplicationLeak>, List<LibraryLeak>> find() {
 2  boolean indexed = buildIndex();
 3  if (!indexed) {
 4   return null;
 5  }
 6  initLeakDetectors();
 7  findLeaks();
 8  return findPath();
 9}
10复制代码

4.3.1 buildIndex()

 1private boolean buildIndex() {
 2  Hprof hprof = Hprof.Companion.open(hprofFile.file());
 3  //选择可以作为gcroot的类类型
 4  KClass<GcRoot>[] gcRoots = new KClass[]{
 5     Reflection.getOrCreateKotlinClass(GcRoot.JniGlobal.class),
 6     //Reflection.getOrCreateKotlinClass(GcRoot.JavaFrame.class),
 7     Reflection.getOrCreateKotlinClass(GcRoot.JniLocal.class),
 8     //Reflection.getOrCreateKotlinClass(GcRoot.MonitorUsed.class),
 9     Reflection.getOrCreateKotlinClass(GcRoot.NativeStack.class),
10     Reflection.getOrCreateKotlinClass(GcRoot.StickyClass.class),
11     Reflection.getOrCreateKotlinClass(GcRoot.ThreadBlock.class),
12     Reflection.getOrCreateKotlinClass(GcRoot.ThreadObject.class),
13     Reflection.getOrCreateKotlinClass(GcRoot.JniMonitor.class)};
14
15  //解析hprof文件为HeapGraph对象
16  heapGraph = HprofHeapGraph.Companion.indexHprof(hprof, null,
17     kotlin.collections.SetsKt.setOf(gcRoots));
18  return true;
19}
20
21fun indexHprof(
22   hprof: Hprof,
23   proguardMapping: ProguardMapping? = null,
24   indexedGcRootTypes: Set<KClass<out GcRoot>> = setOf(
25       JniGlobal::class,
26       JavaFrame::class,
27       JniLocal::class,
28       MonitorUsed::class,
29       NativeStack::class,
30       StickyClass::class,
31       ThreadBlock::class,
32       ThreadObject::class,
33       JniMonitor::class
34   )
35): HeapGraph {
36  //确认对应的record的index
37  val index = HprofInMemoryIndex.createReadingHprof(hprof, proguardMapping, indexedGcRootTypes)
38  //HprofHeapGraph是HeapGraph的实现类
39  return HprofHeapGraph(hprof, index)
40}
41复制代码

HprofInMemoryIndex.createReadingHprof核心逻辑：读取hprof文件，将不同内容封装为不同的record，然后将record转为索引化的index封装，之后查找内容可以通过index去索引到。

HprofReader.readHprofRecords() 封装record

• LoadClassRecord

• InstanceSkipContentRecord

• ObjectArraySkipContentRecord

• PrimitiveArraySkipContentRecord

HprofInMemoryIndex.onHprofRecord() 封装index：

• classIndex

• instanceIndex

• objectArrayIndex

• primitiveArrayIndex

 1class HprofHeapGraph internal constructor(
 2   private val hprof: Hprof,
 3   private val index: HprofInMemoryIndex
 4) : HeapGraph {
 5...
 6  override val gcRoots: List<GcRoot>
 7   get() = index.gcRoots()
 8  override val objects: Sequence<HeapObject>
 9   get() {
10     return index.indexedObjectSequence().map {wrapIndexedObject(it.second, it.first)}
11   }
12  override val classes: Sequence<HeapClass>
13   get() {
14     return index.indexedClassSequence().map {val objectId = it.first
15           val indexedObject = it.second
16           HeapClass(this, indexedObject, objectId)
17         }
18   }
19  override val instances: Sequence<HeapInstance>
20   get() {
21     return index.indexedInstanceSequence().map {val objectId = it.first
22           val indexedObject = it.second
23           val isPrimitiveWrapper = index.primitiveWrapperTypes.contains(indexedObject.classId)
24           HeapInstance(this, indexedObject, objectId, isPrimitiveWrapper)
25         }
26   }
27
28  override val objectArrays: Sequence<HeapObjectArray>
29   get() = index.indexedObjectArraySequence().map {val objectId = it.first
30     val indexedObject = it.second
31     val isPrimitiveWrapper = index.primitiveWrapperTypes.contains(indexedObject.arrayClassId)
32     HeapObjectArray(this, indexedObject, objectId, isPrimitiveWrapper)
33   }
34
35  override val primitiveArrays: Sequence<HeapPrimitiveArray>
36   get() = index.indexedPrimitiveArraySequence().map {val objectId = it.first
37     val indexedObject = it.second
38     HeapPrimitiveArray(this, indexedObject, objectId)
39   }
40复制代码

Hprof 经过层层转换最终封装为HprofHeapGraph。

简而言之，这部分功能主要是将Hrpof文件按照扫描的格式解析为结构化的索引关系图，索引化后的内容封装为HprofHeapGraph，由它去通过对应的起始索引去定位每类数据。没有细抠这部分的实现细节，实现这个功能的库之前是squere的HAHA，现在改为shark,但是提供的功能大同小异。

4.3.2 initLeakDetectors() 与findLeaks()

初始化泄漏检测者：

 1private void initLeakDetectors() {
 2  addDetector(new ActivityLeakDetector(heapGraph));
 3  addDetector(new FragmentLeakDetector(heapGraph));
 4  addDetector(new BitmapLeakDetector(heapGraph));
 5  addDetector(new NativeAllocationRegistryLeakDetector(heapGraph));
 6  addDetector(new WindowLeakDetector(heapGraph));
 7  ClassHierarchyFetcher.initComputeGenerations(computeGenerations);
 8  leakReasonTable = new HashMap<>();
 9}
10复制代码

初始化各类型泄漏的检测者，主要包含Activity、Fragment、Bitmap+NativeAllocationRegistry、window的泄漏检测。

其次是梳理以上几类对象类继承关系串，检测覆盖到他们的子类。

 1public void findLeaks() {
 2  KLog.i(TAG, "start find leaks");
 3  //从HprofHeapGraph中获取所有instance
 4  Sequence<HeapObject.HeapInstance> instances = heapGraph.getInstances();
 5  Iterator<HeapObject.HeapInstance> instanceIterator = instances.iterator();
 6  while (instanceIterator.hasNext()) {
 7    HeapObject.HeapInstance instance = instanceIterator.next();
 8   if (instance.isPrimitiveWrapper()) {
 9      continue;
10   }
11    ClassHierarchyFetcher.process(instance.getInstanceClassId(),
12       instance.getInstanceClass().getClassHierarchy());
13   for (LeakDetector leakDetector : leakDetectors) {
14      //是检测对象的子类&满足对应泄漏条件
15      if (leakDetector.isSubClass(instance.getInstanceClassId())
16          && leakDetector.isLeak(instance)) {
17        ClassCounter classCounter = leakDetector.instanceCount();
18       if (classCounter.leakInstancesCount <=
19            SAME_CLASS_LEAK_OBJECT_GC_PATH_THRESHOLD) {
20          leakingObjects.add(instance.getObjectId());
21         leakReasonTable.put(instance.getObjectId(), leakDetector.leakReason());
22       }
23      }
24    }
25  }
26
27  //关注class和对应instance数量，加入json
28  HeapAnalyzeReporter.addClassInfo(leakDetectors);
29  findPrimitiveArrayLeaks();
30  findObjectArrayLeaks();
31}
32复制代码

这里重点看看各类型对象是如何判断泄漏的：

 1ActivityLeakDetector:
 2
 3private static final String ACTIVITY_CLASS_NAME = "android.app.Activity";
 4private static final String FINISHED_FIELD_NAME = "mFinished";
 5private static final String DESTROYED_FIELD_NAME = "mDestroyed";
 6public boolean isLeak(HeapObject.HeapInstance instance) {
 7  activityCounter.instancesCount++;
 8  HeapField destroyField = instance.get(ACTIVITY_CLASS_NAME, DESTROYED_FIELD_NAME);
 9  HeapField finishedField = instance.get(ACTIVITY_CLASS_NAME, FINISHED_FIELD_NAME);
10  assert destroyField != null;
11  assert finishedField != null;
12  boolean abnormal = destroyField.getValue().getAsBoolean() == null
13     || finishedField.getValue().getAsBoolean() == null;
14  if (abnormal) {
15   return false;
16  }
17  boolean leak = destroyField.getValue().getAsBoolean()
18      || finishedField.getValue().getAsBoolean();
19  if (leak) {
20    activityCounter.leakInstancesCount++;
21  }
22  return leak;
23}
24复制代码

mDestroyed和mFinish字段为true，但是实例还存在的Activity是疑似泄漏对象。

 1FragmentLeakDetector:
 2
 3  private static final String NATIVE_FRAGMENT_CLASS_NAME = "android.app.Fragment";
 4// native android Fragment, deprecated as of API 28.
 5  private static final String SUPPORT_FRAGMENT_CLASS_NAME = "android.support.v4.app.Fragment";
 6// pre-androidx, support library version of the Fragment implementation.
 7  private static final String ANDROIDX_FRAGMENT_CLASS_NAME = "androidx.fragment.app.Fragment";
 8// androidx version of the Fragment implementation
 9private static final String FRAGMENT_MANAGER_FIELD_NAME = "mFragmentManager”;
10private static final String FRAGMENT_MCALLED_FIELD_NAME = "mCalled”;//Used to verify that subclasses call through to super class.
11
12public FragmentLeakDetector(HeapGraph heapGraph) {
13  HeapObject.HeapClass fragmentHeapClass =
14      heapGraph.findClassByName(ANDROIDX_FRAGMENT_CLASS_NAME);
15  fragmentClassName = ANDROIDX_FRAGMENT_CLASS_NAME;
16  if (fragmentHeapClass == null) {
17    fragmentHeapClass = heapGraph.findClassByName(NATIVE_FRAGMENT_CLASS_NAME);
18   fragmentClassName = NATIVE_FRAGMENT_CLASS_NAME;
19  }
20
21  if (fragmentHeapClass == null) {
22    fragmentHeapClass = heapGraph.findClassByName(SUPPORT_FRAGMENT_CLASS_NAME);
23   fragmentClassName = SUPPORT_FRAGMENT_CLASS_NAME;
24  }
25
26  assert fragmentHeapClass != null;
27  fragmentClassId = fragmentHeapClass.getObjectId();
28  fragmentCounter = new ClassCounter();
29}
30
31public boolean isLeak(HeapObject.HeapInstance instance) {
32  if (VERBOSE_LOG) {
33    KLog.i(TAG, "run isLeak");
34  }
35  fragmentCounter.instancesCount++;
36  boolean leak = false;
37  HeapField fragmentManager = instance.get(fragmentClassName, FRAGMENT_MANAGER_FIELD_NAME);
38  if (fragmentManager != null && fragmentManager.getValue().getAsObject() == null) {
39    HeapField mCalledField = instance.get(fragmentClassName, FRAGMENT_MCALLED_FIELD_NAME);
40   boolean abnormal = mCalledField == null || mCalledField.getValue().getAsBoolean() == null;
41   if (abnormal) {
42      KLog.e(TAG, "ABNORMAL mCalledField is null");
43     return false;
44   }
45    leak = mCalledField.getValue().getAsBoolean();
46   if (leak) {
47      if (VERBOSE_LOG) {
48        KLog.e(TAG, "fragment leak : " + instance.getInstanceClassName());
49     }
50      fragmentCounter.leakInstancesCount++;
51   }
52  }
53  return leak;
54}
55复制代码

这里分了三种fragment:

• android.app.Fragment

• android.support.v4.app.Fragment

• androidx.fragment.app.Fragment

对应的FragmentManager实例为null（这表示fragment被remove了）且满足对应的mCalled为true,即非perform状态，而是对应生命周期被回调状态（onDestroy），但是实例还存在的Fragment是疑似泄漏对象。

 1BitmapLeakDetector
 2
 3private static final String BITMAP_CLASS_NAME = "android.graphics.Bitmap”;
 4public boolean isLeak(HeapObject.HeapInstance instance) {
 5  if (VERBOSE_LOG) {
 6    KLog.i(TAG, "run isLeak");
 7  }
 8  bitmapCounter.instancesCount++;
 9  HeapField fieldWidth = instance.get(BITMAP_CLASS_NAME, "mWidth");
10  HeapField fieldHeight = instance.get(BITMAP_CLASS_NAME, "mHeight");
11  assert fieldHeight != null;
12  assert fieldWidth != null;
13  boolean abnormal = fieldHeight.getValue().getAsInt() == null
14     || fieldWidth.getValue().getAsInt() == null;
15  if (abnormal) {
16    KLog.e(TAG, "ABNORMAL fieldWidth or fieldHeight is null");
17   return false;
18  }
19
20  int width = fieldWidth.getValue().getAsInt();
21  int height = fieldHeight.getValue().getAsInt();
22  boolean suspicionLeak = width * height >= KConstants.BitmapThreshold.DEFAULT_BIG_BITMAP;
23  if (suspicionLeak) {
24    KLog.e(TAG, "bitmap leak : " + instance.getInstanceClassName() + " " +
25        "width:" + width + " height:" + height);
26   bitmapCounter.leakInstancesCount++;
27  }
28  return suspicionLeak;
29}
30复制代码
31

这里是针对Bitmap size做判断，超过768*1366这个size的认为泄漏。

另外，NativeAllocationRegistryLeakDetector和WindowLeakDetector两类还没做具体泄漏判断规则，不参与对象泄漏检测，只是做了统计。

总结：整体看下来，KOOM有两个值得借鉴的点：

• 1.触发内存泄漏检测，常规是watcher activity/fragment的onDestroy，而KOOM是定期轮询查看当前内存是否到达阀值；

• 2.dump hprof，常规是对应进程dump，而KOOM是fork进程dump。

推荐阅读