QT跨线程的信号与槽

QT程序是由主线程更新界面

若在主线程做一些耗时的操作,会导致界面暂时卡死

所以要把耗时的操作放到一个后台线程中去做

最好的方式是主线程发出信号,后台线程去干活

当后台线程干完活时发出信号,主线程进行处理

但一般来说当一个对象发出信号时

响应的槽函数的运行环境不会改变

也就是说不会进行线程的切换

查到有个moveToThread函数,但有人说不推荐,有人说推荐

最后找到了一个综合的方式来解决问题

逻辑上是两个类相互通信(信号/槽),实际上是三个类

假设AB两个类通信,正常模式下不会跨线程,所以还需要一个线程类C

这样B依托于C来执行代码,AB的执行环境就不在同一个线程了

自己封装了一下,先贴上来

XBackgroundWorker.h

#pragma once
#include <QObject>
#include <QThread>

class CXBackgroundWorkerThread : public QThread
{
	Q_OBJECT
public:
	explicit CXBackgroundWorkerThread()
	{
	}
	virtual ~CXBackgroundWorkerThread()
	{

	}
private:
protected:
	virtual void run()
	{
		this->exec();
	}
public:
};

class CXBackgroundWorker : public QObject
{
	Q_OBJECT
public:
	explicit CXBackgroundWorker()
	{
		m_BkWorker = new CXBackgroundWorkerThread();
		thi
### QT跨线程信号槽机制失效的原因及解决方案 #### 构造函数中实例化定时器不当 如果在构造函数中过早地实例化定时器或其他需要在线程启动之后使用的资源,可能会导致这些对象未能正确初始化。这通常发生在子线程尚未完全准备好接收消息之前就尝试发送信号或调用函数的情况[^1]。 为了防止此类错误发生,在确保目标线程已经成功启动并进入运行状态后再执行相关联的操作是非常重要的。可以通过监听`QThread::started()`信号来确认这一点,并在此基础上安排后续的任务逻辑。 #### 正确设置信号槽连接模式 当涉及到不同线程间的通信时,默认情况下Qt会自动选择合适的连接类型(Direct Connection, Queued Connection)。然而对于某些特定场景来说显式指定连接方式可能是必要的。特别是针对跨线程情况下的信号槽链接建议采用QueuedConnection以确保安全性: ```cpp connect(senderObject, &SenderClass::signalName, receiverObject, &ReceiverClass::slotMethod, Qt::QueuedConnection); ``` 这种方式可以有效避免直接跨越线程边界访问数据结构所带来的风险,因为所有请求都会被放入事件循环队列等待适当时候处理[^2]。 #### 避免从非GUI线程更新界面组件 由于Qt不允许除主线程外其他任何地方直接操控UI控件,所以在设计应用程序架构之初就要特别注意区分哪些部分应该放在哪个线程里完成工作。一旦违反这条原则就会触发未定义行为甚至造成程序崩溃。因此应当遵循最佳实践——仅允许主线程负责绘制图形用户接口而把耗时计算交给后台工作者去做[^3]。 具体实现上可通过发射自定义信号携带所需信息回传给主窗口类中的相应方法来进行间接控制;也可以利用`QMetaObject::invokeMethod()`配合`Qt::BlockingQueuedConnection`参数达到同步效果而不阻塞当前上下文环境。 综上所述,要解决QT跨线程信号槽不起作用的问题需关注以上几个方面:调整对象创建顺序、合理配置连接属性以及严格遵守单一线程管理视图的原则。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值