Qt5 Embedded+framebuffer高CPU负载下屏幕停止绘制是已知问题吗

这不是Qt的已知Bug，是主线程事件调度优先级机制导致的典型问题。

你对信号槽调度的猜测基本正确。跨线程使用默认队列连接（QueuedConnection）的信号，发送时会往接收线程的事件队列插入类型为QEvent::MetaCall的信号事件，这类事件的默认优先级高于绘制相关的QEvent::UpdateRequest、QEvent::Paint事件。主线程负载高时，如果信号槽事件持续产生，主事件循环每次取事件都会优先处理MetaCall事件，绘制事件长期拿不到调度资源，就会出现你观察到的主循环还在跑、但屏幕停止更新的现象。

• 重写QCoreApplication的notify方法，统计单位时间内主线程处理的事件类型、耗时和优先级，确认是否绘制事件长时间未被调度
• 用嵌入式平台的perf工具或者Qt Creator自带的CPU Profiler抓主线程的调用栈占比，确认信号槽关联的业务逻辑是否占用了主线程绝大多数CPU时间
• 监控主线程事件队列的待处理事件分布，高负载时查看队列中是否存在大量待处理的QEvent::MetaCall（信号槽）事件

根治方案（推荐） #

• 严格遵循Qt开发规范，将所有非UI的业务逻辑（数据处理、日志输出、计算逻辑等）全部迁移到独立工作线程，主线程仅保留UI绘制、用户输入响应逻辑，从根源上避免主线程负载过高
• 优化跨线程信号发送逻辑：对高频信号做合并（比如10ms内多次触发的相同数据更新信号合并为一次发送），减少主线程的事件队列压力
• 调整非紧急业务信号的优先级：使用QMetaObject::invokeMethod发送信号时指定Qt::LowEventPriority，将其优先级降到低于绘制事件

临时强制刷新方案（仅应急使用，不建议长期落地） #

你之前尝试的方案未生效，是因为调用processEvents时仍然会优先处理队列中已有的高优先级信号槽事件，轮不到绘制事件。可使用以下逻辑强制触发绘制：

// 先清空队列中所有待处理的信号槽事件（注意：该操作会丢失未处理的信号，仅应急使用）
qApp->removePostedEvents(nullptr, QEvent::MetaCall);
// 同步触发当前控件的绘制，不需要走事件队列调度
this->repaint();
// 仅处理绘制相关事件，跳过其他高优先级事件
qApp->processEvents(QEventLoop::PaintEventLevel);

内容的提问来源于stack exchange，提问作者Kingsley