1. 地面站性能瓶颈分析：为什么你的 Mission Planner 卡成 PPT？

做飞控调试最怕什么？不是飞机掉下来，是地面站先掉下来。

我见过不少朋友，飞着飞着 Mission Planner 突然卡死，日志丢了一堆，最后只能靠猜来调参。说实话，这种体验很糟糕。你想想看，地面站卡成 PPT，你连实时姿态都看不清，还谈什么调参？

这一章，我们就来彻底扒一扒 GCS 卡顿的根源。我会从 CPU 占用、内存泄漏、串口缓冲区溢出到绘图线程阻塞，一个一个拆开来看。

1.1 CPU 占用过高：谁在抢你的算力？

先说说最常见的 CPU 问题。Mission Planner 默认会以 50Hz 甚至更高频率刷新数据。你想想看，每秒 50 次解析 MAVLink 报文、更新 UI 控件、重绘地图——这可不是小开销。

我在项目中遇到过一台老笔记本，跑 Mission Planner 时 CPU 直接飙到 90%。一开始以为是电脑不行，后来发现是某个第三方插件在后台疯狂轮询。说白了，很多卡顿都是自己给自己挖的坑。

1.2 内存泄漏：看不见的杀手

内存泄漏这个问题，说实话，在 .NET 应用里太常见了。Mission Planner 用 C# 写的，虽然 GC 能自动回收，但你要是事件没注销、委托没清理，内存照样只增不减。

我记得有一次调试一个客户的问题，Mission Planner 跑了 2 小时后内存占用从 200MB 涨到了 1.2GB。最后定位到是一个日志列表控件，每次收到新数据就 new 一个对象，但旧对象的事件绑定没解绑，GC 根本收不回来。

常见的泄漏点有这些：

• 事件订阅未注销——订阅了 SerialPort.DataReceived，但关闭连接时没 -=
• 缓存无限增长——日志列表、航点列表只加不减
• GDI 对象泄漏——创建了 Pen、Brush 没 Dispose
• Timer 残留——窗口关闭了 Timer 还在跑

1.3 串口缓冲区溢出：数据来了，你接得住吗？

串口这块，很多人容易忽略。ArduPilot 默认 115200 波特率，每秒能传大约 11.5KB 数据。如果地面站读取不及时，缓冲区就会积压。

你想想看，串口缓冲区满了会怎样？新数据进不来，旧数据被覆盖，CRC 校验失败，重传请求又占带宽——恶性循环。

我见过最夸张的情况：有人用 USB 转串口线质量太差，驱动层缓冲区只有 4096 字节，飞控一发 HEARTBEAT + ATTITUDE + GPS 三连包，直接撑爆。

串口缓冲区溢出的典型症状：

• MAVLink 报文频繁丢包
• 地面站显示的数据跳变、不连续
• 日志里出现大量 "bad CRC" 或 "sequence gap"
• 串口读取线程 CPU 占用异常高

1.4 绘图线程阻塞：UI 卡死的真凶

最后说说绘图线程。Mission Planner 的主线程既要处理用户交互，又要负责所有控件的重绘。一旦某个操作卡住了主线程，整个界面就冻住了。

为什么会这样？因为 Windows 的 GDI+ 不是线程安全的。所有绘图操作必须在主线程执行。如果你在后台线程里更新了数据，然后通过 Invoke 通知主线程重绘——Invoke 本身是同步的，主线程忙的时候就得排队。

我遇到过最离谱的一次：一个用户开了 3D 地图视图，同时还在记录日志，结果主线程被 Invoke 调用淹没了，鼠标点一下要等 5 秒才有反应。

绘图阻塞的常见原因：

1. Invoke 调用过于频繁——每秒几十次 Invoke，主线程根本忙不过来
2. 重绘区域过大——每次刷新都重绘整个窗口，而不是只更新变化区域
3. 地图控件加载缓慢——GMap.NET 在加载新瓦片时会阻塞主线程
4. 日志写入占用主线程——同步写入文件时，磁盘 I/O 会卡住 UI

1.5 如何快速定位瓶颈？

说了这么多，怎么快速找到问题在哪？我一般按这个顺序排查：

嗯，这套流程我用了好几年，基本能覆盖 90% 的卡顿场景。下一节我们会深入每个瓶颈的具体优化方案，包括代码级别的改动。

记住一句话：地面站卡顿不是玄学，是可测量、可复现、可修复的工程问题。