我有两个（可选）函数处理传感器提供的数据。这些函数在它们自己的线程中运行，并在结果准备就绪时发出一个信号。该信号连接到UI小部件的插槽，显示结果。 有了其中的一个功能，这个效果很好。然而，当使用另一个时，GUI开始滞后并很快冻结。Qt：使用线程和信号/插槽时GUI有时会冻结
QDebug显示数据仍在处理中。
在GUI线程中运行代码时，没有问题。
也许问题是工人线程由于Qt的:: QueuedConnection产生数据的速度比用户界面可以借鉴它，导致有些滞后？如果是这样，我有什么替代方案？如果没有，我还能检查什么？
这样看来，工作线程垃圾邮件UI线程，填补了主事件循环，使GUI事件有得到处理的困难时期。
没有看到一些在工作线程的代码，也难以推荐的解决方案。在一天结束时，您只希望以指定的时间间隔发出信号。
你可能有一些运气的QTime类。每次发出信号时，请致电QTime::start，然后检查QTime::elapsed的值。只有当它高于某个阈值时才会发出信号并重置计时器。
如果您可以丢弃中间传感器值，那就很理想。如果你需要他们，你将不得不将他们添加到QVector或其他东西，并立即在信号中发送它们。
更妙的是，如果你只能轮询定期传感器本身。在这种情况下，QTimer类可能很有用 - 每次它“滴答”时都要轮询传感器（并发出信号）。
其实我好不容易才找到一个解决方案：数据处理，在一个单独的线程中完成了投票的传感器类的方式来频繁。因此，对于来自传感器的每个样本，发送到UI线程的信号多次。
通过包括QWaitCondition到处理线程，我设法降低到一个更合理的刷新率。
尽管如此，非常感谢您的回答。
我们真的需要一些代码来帮助你解决这个问题。我唯一的猜测是，工作线程以比它可能处理的结果更多的结果发送UI线程垃圾邮件。你可以加一个油门进行测试，看看它是否有所作为？ –
包括一个大的不必要的循环后，它运行得更顺畅。所以是的，这似乎表明工作线程速度太快，因为你和我都怀疑存在问题。我现在能做什么？ – user1041903
我正在将讨论移至答案，因为看起来我们已经确认了根本原因.... –