1. 性能监控概述：为什么需要性能监控？

说实话，我刚开始做 Flutter 开发那会儿，对性能监控这事并不上心。

总觉得「App 能跑就行，卡不卡用户自己会适应」。直到有一次，我负责的一个电商项目上线后，用户反馈说「滑动商品列表像在泥巴里走路」—— 嗯，那感觉真不好受。

从那以后，我养成了一个习惯：性能监控不是可选项，而是必选项。

1.1 为什么需要性能监控？

你想想看，一个 App 从开发到上线，中间要经历多少环节？

• 开发阶段：你写的代码可能埋了性能坑
• 测试阶段：低端机上的表现可能完全不一样
• 线上阶段：用户设备千奇百怪，网络环境复杂

没有监控，就等于闭着眼睛开车。我个人习惯是：从项目第一天就把监控工具搭好。这样出了问题，能立刻定位到是哪个版本、哪个模块、甚至哪行代码导致的。

1.2 性能监控的核心指标

做性能监控，你得知道该看什么。我把它总结为四个核心指标：FPS、CPU、内存、GPU。

指标	含义	健康值	危险值
FPS	每秒帧数，衡量界面流畅度	≥55 FPS	<30 FPS
CPU	处理器占用率	<60%	>80% 持续
内存	App 占用的 RAM	稳定，无持续增长	OOM 或接近系统上限
GPU	图形渲染负载	无明显掉帧	频繁掉帧或渲染超时

FPS 是最直观的指标。用户说「卡」，其实就是 FPS 低了。我见过不少团队只盯着 FPS 看，觉得只要 FPS 高就万事大吉 —— 其实不然。

CPU 和 内存 是「隐形杀手」。CPU 过高会导致手机发热、耗电快；内存泄漏会让 App 越用越卡，最后闪退。我在项目中遇到过一个问题：一个列表页面，滑动 10 分钟后内存涨了 200MB，用户反馈「用久了就闪退」。查了半天，发现是某个图片缓存没释放。

GPU 这块，Flutter 开发者尤其要注意。Flutter 自己渲染 UI，GPU 负载比原生 App 更重。如果布局层级太深，或者用了太多复杂的阴影、裁剪效果，GPU 很容易扛不住。

1.3 Flutter 与原生性能差异

很多人问我：「Flutter 性能到底行不行？」

我的回答是：大部分场景下，Flutter 性能不输原生。但有几个关键差异，你得心里有数。

渲染机制不同

原生 Android 用的是系统自带的 Skia 引擎，Flutter 也用的是 Skia —— 但 Flutter 是自己控制渲染管线，不经过系统 View 体系。这意味着：

• Flutter 的 UI 线程和渲染线程是分开的
• Flutter 的布局计算更高效（没有原生 View 的层级嵌套开销）
• 但 Flutter 的 GPU 渲染压力更大（因为所有 UI 都是自己画的）

内存管理差异

原生 Android 有系统级的 GC（垃圾回收），Flutter 用的是 Dart 的 GC。Dart 的 GC 是分代式的，小对象回收很快，但大对象回收时会有停顿。

我曾经遇到过一个问题：Flutter 页面里加载了一张 4K 大图，GC 触发时界面卡了 200ms。这在原生里可能不会发生，因为原生可以复用系统级的 Bitmap 缓存。

线程模型差异

原生 Android 有主线程（UI 线程）和子线程之分。Flutter 也有主 Isolate 和子 Isolate，但 Isolate 之间不共享内存，通信靠消息传递。

说白了，Flutter 的线程模型更安全（不会出现多线程数据竞争），但也更「重」—— 创建 Isolate 的开销比原生线程大得多。

性能监控工具差异

原生 Android 有 Profiler、Systrace、Perfetto 等工具。Flutter 有 DevTools、Flutter Performance 面板、Dart Observatory。

我个人习惯是：Flutter 项目用 DevTools 做日常监控，遇到疑难杂症再用 Android Profiler 看底层。两者结合，基本能覆盖所有场景。

1.4 本章知识体系

下面这张图，是我自己梳理的「性能监控知识体系」。你可以把它当作一个地图，后续章节都会围绕这些点展开。

这张图里，中心是「性能监控核心体系」，四个方向分别对应：为什么需要、核心指标、Flutter vs 原生差异、监控工具。后续章节会逐一深入。

---

公众号:蓝海资料掘金营，微信deep3321