前言

Flutter 项目开发到一定阶段后经常会遇到一些看起来很像“玄学”的问题：

• 页面反复进入退出后内存继续增长
• 长列表滑动几次后内存明显升高
• 加载几张图片，内存突然上涨几十 MB
• 页面已经退出，但控制器、定时器和页面对象仍然存在
• 手动触发 GC 后内存曲线没有明显下降
• 内存上涨了却不知道这是正常缓存、临时峰值。还是实际泄漏

这些问题如果只靠经验猜，很容易陷入两个极端：

• 看到内存上涨就认为发生了泄漏
• 认为 Dart 有 GC，业务代码不需要主动释放资源

这两个判断都不准确。

说到痛点一，无从判断是缓存还是泄漏？

很多开发者在看到 DevTools 的内存曲线飙升时一头雾水。话说回来，到底是暂时的缓存导致峰值？还是某个对象一直被强引用导致真正泄漏？话说回来，这正是排查的主要痛点。

说到痛点二，GC 与 dispose 的混淆导致资源得不到及时释放。

Dart 的垃圾回收机制并不会主动“杀死”对象； 只有出现资源残留，老实说，

Flutter 内存管理并不是只记住一句话“控制器需要在 dispose 中释放”。真正需要学会一套完整思路：

1. Dart GC 会回收哪些对象
2. 对象为什么仍然可达
3. dispose 和 GC 分别负责什么
4. 内存峰值、缓存和内存泄漏有什么区别
5. 图片为什么特别容易造成高内存
6. d 长列表为什么要使用懒加载

为了把这些知识串起来我整理了一个可以直接运行的 Flutter 内存管理实验室 Demo。

运行环境与 Demo 下载地址

- Flutter SDK：stable - Dart SDK：stable - DevTools：latest - 开发程序：macOS - 第三方插件：无

Demo 地址：

git clone https://gitee.com/TTGF/flutter_memory_lab.git
cd flutter_memory_lab
flutter pub get
flutter run
# 验证命令：
flutter analyze
flutter test
# 图片缓存实验默认使用网络图片，也支持切换到本地图片。即使网络请求失败，页面也会自动回退到本地资源。

Demo 包含哪些实验？

基础原理

- GC 回收验证 - 内存峰值与泄漏

常见泄漏

- 控制器释放 - 定时器与订阅 - 闭包持有页面引用 - 页面生命周期

高内存场景

- 图片缓存 - 图片像素内存估算 - 长列表建立方式

项目结构示例：

lib/
├── main.dart
├── pages/
│ ├── gc_lab_page.dart
│ ├── memory_peak_lab_page.dart
│ ├── controller_lab_page.dart
│ ├── timer_lab_page.dart
│ ├── reference_lab_page.dart
│ ├── lifecycle_lab_page.dart
│ ├── image_cache_lab_page.dart
│ ├── image_memory_lab_page.dart
│ └── list_lab_page.dart
├── store/
│ ├── gc_probe_store.dart
│ ├── memory_peak_store.dart
│ ├── memory_lab_store.dart
│ ├── lifecycle_lab_store.dart
│ └── lab_cleanup_service.dart
└── widgets/
└── lab_scaffold.dart

首页还提供统一清理入口，可释放：

 - 控制器 - 定时器 - 闭包引用 - 持续占用内存 - GC 实验记录 - 生命周期计数 - 图片缓存

Flutter 内存管理的主要模型

Dart 使用垃圾回收机制管理堆上的对象。目标是回收已不可达对象：