Qt跨线程修改UI控件属性或操作

问题

在编写一个控制器控制UI界面时，由于在控制器中使用到了开线程单独循环执行某个执行函数，这个执行函数回调了UI界面中QLabel控件的修改背景色函数，导致会运行报错，“ASSERT failure in QCoreApplication::sendEvent: “Cannot send events to objects owned by a different thread””，在我的理解中，这就是由于sendEvent不能跨线程出现的。

解决办法

查阅网上的各种解决办法后，发现只有信号与槽这一种实现方式。
在这里就需要补充点信号与槽的使用方式。
connect用于连接qt的信号和槽，在qt编程过程中不可或缺。它其实有第五个参数，只是一般使用默认值，在满足某些特殊需求的时候可能需要手动设置。

• Qt::AutoConnection： 默认值，使用这个值则连接类型会在信号发送时决定。如果接收者和发送者在同一个线程，则自动使用Qt::DirectConnection类型。如果接收者和发送者不在一个线程，则自动使用Qt::QueuedConnection类型。
• Qt::DirectConnection：槽函数会在信号发送的时候直接被调用，槽函数运行于信号发送者所在线程。效果看上去就像是直接在信号发送位置调用了槽函数。这个在多线程环境下比较危险，可能会造成奔溃。
• Qt::QueuedConnection：槽函数在控制回到接收者所在线程的事件循环时被调用，槽函数运行于信号接收者所在线程。发送信号之后，槽函数不会立刻被调用，等到接收者的当前函数执行完，进入事件循环之后，槽函数才会被调用。多线程环境下一般用这个。
• Qt::BlockingQueuedConnection：槽函数的调用时机与Qt::QueuedConnection一致，不过发送完信号后发送者所在线程会阻塞，直到槽函数运行完。接收者和发送者绝对不能在一个线程，否则程序会死锁。在多线程间需要同步的场合可能需要这个。
• Qt::UniqueConnection：这个flag可以通过按位或（|）与以上四个结合在一起使用。当这个flag设置时，当某个信号和槽已经连接时，再进行重复的连接就会失败。也就是避免了重复连接。

在经过尝试后，发现该问题的场景只适合接收者和发送者绝对不能在一个线程，使用接收者的线程调用槽函数，即Qt::BlockingQueuedConnection模式下。

1. 申明信号函数

signals:
    //（连接参数为不同线程，发送方其他线程，接收方为UI线程，因此不会出现跨线程执行UI修改操作从而导致的崩溃错误）
    void sigFirst(const std::vector<int>& ioStatus);

2. 申明槽函数

slots:
void slotFirst(const std::vector<int>& ioStatus);

3. 槽函数的定义

void MainWindow::slotFirst(const std::vector<int>& ioStatus) {
    for(int i = 0;i < 16;++i) {
        if(ioStatus[i] == 1) {
            setLED(_vLabel[i],1,16);
        } else {
            setLED(_vLabel[i],0,16);
        }
    }
}

4. 创建连接

connect(this, SIGNAL(sigFirst(const std::vector<int>&)), this, SLOT(slotFirst(const std::vector<int>&)), Qt::BlockingQueuedConnection);

5. 发送信号

emit sigFirst(ioStatus);

即可通过信号调用到槽函数，这样即使发送方是另一个线程，也不会触发跨线程操作导致崩溃。

总结

遇到跨线程操作UI界面导致的Qt崩溃问题（包括普通类或窗口类调用另一窗口类的控件时产生的跨线程），可以尝试使用信号与槽的方式去解决，根据场景选择合适的连接模式。