获课：shanxueit.com/12099/

曲线要顺，线程要分，界面要稳

第一次做运动控制工控软件的时候，我犯了一个新手很容易犯的错——把数据采集、数据处理、曲线绘制全部塞在同一个线程里。设备刚启动的时候一切正常，但运行时间一长，界面就开始卡顿，鼠标点击半天没反应，曲线也断断续续的。当时的我一度以为是QT5的性能不行，直到导师一句话点醒了我："你让CEO去前台接待客人，让保洁去开董事会，能不出乱子吗？ "

工控软件里的实时曲线绘制，本质上是一个"数据生产-数据消费"的问题。设备不断产生数据，界面需要把这些数据实时展示出来。如果生产和消费在同一个线程里，任何一个环节卡住，整个系统都会跟着卡。多线程并发的核心思路，就是把"干活"和"展示"彻底分开。

第一条认知：分工要清晰，主线程只负责画，不负责算。

QT5的GUI线程是单线程的，所有界面更新都必须在主线程里执行，这是框架的铁律。很多人把数据处理也放在主线程里，一旦数据量大了或者计算复杂了，主线程就被堵住了，界面自然就卡了。正确的做法是主线程只做最轻量级的绘制操作，所有涉及计算、I/O、数据搬运的工作，全部丢到工作线程里去。

运动控制场景里，设备通常以毫秒级的频率输出数据——位置、速度、电流、力矩，每个参数都在实时变化。工作线程负责接收这些数据、做必要的滤波或换算、缓存到队列里。主线程只管每隔几十毫秒从队列里取一帧数据，然后调用绘图API画出来。各司其职，互不干扰。

第二条认知：数据队列是连接生产者和消费者的"传送带"。

工作线程产生的数据怎么安全地交给主线程？直接用全局变量共享会有数据竞争，用互斥锁频繁加解锁又会影响性能。QT5的"信号槽+队列"机制是一条很顺的路——工作线程发射信号把数据传出来，主线程的槽函数接收后更新绘图。

但这里面有个坑要注意：如果工作线程产生的数据速度太快，主线程绘制不过来，队列里的数据会越积越多，内存占用不断上升，界面也跟不上真实数据的变化。这时候需要在工作线程里做"帧率节制"，不是所有数据都要画出来，而是按固定的刷新率采样绘制。数据可以全收，但绘制只取其中一部分。用户的眼睛不需要看到每一毫秒的变化，看到足够流畅的曲线就够了。

第三条认知：绘图对象要复用，别反复创建销毁。

刚开始做曲线绘制的时候，每次刷新数据我都重新创建QPen和QBrush对象，循环里频繁的new和delete导致内存碎片，GC一来界面就抖。后来改成在类的初始化阶段就创建好所有的绘图工具，不同的曲线用不同的颜色和线宽，但每个曲线对象只有一份，绘制的时候直接拿来用。

这个改动没有涉及任何算法层面的优化，但性能提升非常明显。QT的绘图API本身已经足够快了，真正拖慢速度的往往是频繁的对象创建和销毁。

第四条认知：静态背景和动态轨迹要分层绘制。

运动控制的曲线图通常有一个固定的坐标网格和刻度标签，这些元素每帧都不变。如果每次绘制都重新画一遍网格，浪费了大量的CPU时间。比较实用的做法是用一个QPixmap把静态背景缓存起来，绘制的时候先贴背景图，再在它上面画动态的曲线数据。

这种方式让每次重绘需要计算的图形元素大幅减少，绘制速度提升在百分之五十左右。工控场景下用户需要的是实时反馈，而不是让界面把时间花在反复画网格上。静态的固定下来，动态的实时更新，分层处理互不影响。

第五条认知：加一个"防抖"机制，不要让界面频繁刷新。

工控设备的数据有时候会抖动，相邻两帧之间可能只有微小的差异，但界面每帧都刷新的话，CPU的占用率会居高不下。可以在工作线程里加一个简单的"变化检测"——如果当前帧的数据跟上一次绘制时的数据差异小于设定阈值，这帧数据就跳过不绘制，等积累到一定变化量再触发重绘。

这个机制在信号相对平稳的阶段可以大幅降低界面的刷新频率，系统负载下来了，设备长时间运行的稳定性也会更好。

第六条认知：异常要处理得优雅，不能卡死界面。

设备偶尔会出现数据断流或者异常值，如果工作线程因为读数据报错而崩溃，整个程序就跟着挂了。每条线程都该有自己的异常捕获和处理逻辑——读不到数据就重试几次，重试失败就记录日志并通知用户，但主线程的绘制不该受任何影响。曲线画面可以暂停更新、可以显示"信号中断"的提示，但界面本身不能僵住。用户需要看到的是"设备停了我能看到它停了"，而不是"设备停了程序也停了"。

最后总结一下QT5多线程并发绘制实时曲线的核心心法：主线程当"画师"，工作线程当"搬运工"，队列当"传送带"，背景缓存当"底稿"，防抖机制当"节流阀"。 画师只管按底稿描线，不亲自搬货；搬工只管把货运到传送带上，不关心画师怎么描。两条线互不堵车，曲线才能画得顺，界面才能稳得住。

工控软件的曲线画得顺不顺，本质上是线程分工清不清楚的问题。线程分明白了，剩下的都是调优细节。线程分不明白，再好的硬件也救不了界面卡成PPT的命运。