时间戳

首页 > 解决方案 > 我应该在 Qt 中尽可能多地使用信号/插槽吗？

c++ - 我应该在 Qt 中尽可能多地使用信号/插槽吗？

问题描述

从关于性能注意事项和建议的 Qt 文档中，我得到了以下信息：

use asynchronous, event-driven programming wherever possible

我不确定这意味着什么，所以想问一下。这是否意味着我应该尽可能使用信号/插槽（因为它们是异步的？）？

标签： c++performanceqtqt5c++17

解决方案

Qt 信号/槽不一定是异步的。来自https://doc.qt.io/qt-5/threads-qobject.html：

直接连接：在发出信号时立即调用插槽。槽在发射器的线程中执行，不一定是接收器的线程。

Queued Connection：当控制返回到接收者线程的事件循环时调用槽。插槽在接收者的线程中执行。

Blocking Queued Connection：slot 的调用与 Queued Connection 一样，但当前线程阻塞，直到 slot 返回。

由具有直接连接的插槽订阅的信号本质上是一个方法调用，您可以在运行时“连接”它。

另外，是的，您可能应该使用“尽可能”“尽可能”的“异步，事件驱动编程”来定义“尽可能”的合理定义。

显然，不要用信号和槽替换对象之间的所有方法调用。当你使用信号和槽时，不要总是让它们异步（排队） - 有时你会希望订阅你的信号的对象在发射函数继续之前完成它们对你的信号的“反应”。

通常，当您并不真正关心信号的订阅者是否立即或稍后调用其插槽时，只需将它们连接起来而不指定连接类型，Qt 将使用自动连接，这将做正确的事情（线程-明智的）。当您关心时，只需指定您想要的连接类型。

如果您一开始对此感到困惑，一个合理的做法也可能是让所有连接默认排队 - 您不会真正注意到任何性能差异，这可能会阻止您意外编写依赖于插槽执行的代码“直接”，当那不是你的意图时。

链接中的建议主要针对在主线程上生成的任何事件，最有可能是由 UI 元素 - 按钮等。主要思想是您希望尽快处理任何输入事件，以保持主线程线程空闲用于接受任何以后的事件并呈现您的 UI，并且，如果事件导致完成任何重要工作，则将该工作移至另一个线程，并让您的主线程等待完成信号，以便您的主线程保持“反应灵敏”。如果您希望您的 UI 立即响应任何事件，例如，通过启动“加载微调器”或显示进度条，您当然可以直接执行此操作。这当然，

推荐阅读