近两年来，无论是创新型应用还是老牌旗舰型应用，都在或多或少地使用 Flutter 技术。然而，目前 Flutter 业务团队反馈最普遍的问题是，Flutter 内存占用过高。
Flutter 内存占用过高原因比较复杂，需另开一个主题才能说清楚。简单总结下我们调研的结论：Dart Heap 内存管理以及 Flutter Widget 设计综合导致业务内存较高，其最核心的问题引擎设计使开发者容易踩中内存泄漏。开发过程中，内存泄漏常见且难以定位，总结主要 2 点原因：
Flutter 渲染三棵树的设计，以及 Dart 各种异步编程的特点，导致对象引用关系比较绕，分析困难
Dart “闭包”，“实例方法”可赋值传递，导致所在的类被方法上下文持有，不经意就会发生泄漏。典型例如注册一个 listener 没有反注册，导致 listener 所在的类对象泄漏
开发者享受了 Flutter 开发的便利性，却不知不觉中承受了内存泄漏的苦果。因此，我们迫切需要一套高效的内存泄漏检测工具来摆脱这种困境。
盘点我了解到的几种内存泄漏检测方案：
监控 State 是否泄漏：针对 State 的泄漏检测。但 State 是 Flutter 内存泄漏中占比最大的对象吗？StatelessWidget 的对象也是可以引用很大内存的
监控 Layer 个数：对比 正在使用，内存中的 Layer 个数来判定是否存在内存泄漏。方案对内存泄漏判定是否准确？Layer 对象离业务 Widget 太远，溯源太困难
Expando 弱引用泄漏判定：判定特定对象是否泄漏并返回引用链 。但我们不知道 Flutter 中最应该监控的对象是哪个，哪个对象泄漏是主要问题？
基于 Heap Snapshot 内存泄漏检测：对比不同两个时间点的 Dart 虚拟机 Heap 对象的增长，以“class 内存增量”，“对象内存个数” 2 个指标检测发生泄漏的可疑对象。这是个通用的解决方案，但要做到高效定位到泄漏对象（Image, Layer）才比较有价值。目前“确定检测对象”和“检测时机”这 2 个问题都不好解决，所以还需要人工逐一排查确认，效率不高。
总之，我们觉得方案 1，2 逻辑上不够完备，方案 3，4 效率有待提高。
更好的方案是？
参考 Android，LeakCanary 能够准确、高效检测 Activity 内存泄漏，解决内存泄漏的主要问题。那我们能不能在 Flutter 中也实现一套这样的工具呢？这应该是一套更好的方案。
在回答这个问题之前，先思考下为什么 LeakCanary 要挑选 Activity 作为内存泄漏监控的对象，并且能够解决主要的内存泄漏问题？
我们总结其至少满足了下面 3 个条件：
泄漏对象引用的内存足够大：Activity 对象引用的内存是非常大，是内存泄漏的主要问题
能够完备定义内存泄漏：Activity 具有明确的生命周期和确切回收时机，泄漏定义完备，可实现自动化，提高效率
泄漏的风险高：Activity 基类为 Context，作为参数传递，使用非常频繁，存在较高的泄漏风险
3 个条件反映了监控对象的必要性，监控工具的可操作性。
顺着这个思路，如果我们能够在 Flutter 中找到满足上面 3 个条件的对象，将其监控起来，那就可以做一套 Flutter 的 LeakCanary 工具，用来解决 Flutter 中内存泄漏的主要问题。
从实际项目中回顾近期解决的内存泄漏问题，内存飙升体现在 Image, Picture 对象，如下图所示。
虽然 Image, Picture 内存占用高，是泄漏内存的主要贡献者，但它们不能作为我们监控的目标，因为它们明显不符合上面列出的 3 个条件：
内存占用大，是其对象个数多，累加起来的，并不是由某一个 Image 引用而导致
无法定义什么时候是泄漏的，没有明确的生命周期
并不会作为一个常用的参数传递，使用地方都比较固定，例如 RawImage Widget
深入 Flutter 渲染分析，总结到 Image, Picture 泄漏的根本原因是 BuildContext 发生泄漏。而 BuildContext 恰恰满足上面列的 3 个条件（后面详述），似乎是我们要找的那个对象，实现一套监控 BuildContex 泄漏的方案似乎不错。
请记住这 3 个条件，后面我们在说明的时候会经常用到。
BuildContext 引用的内存有哪
