QT出现重复调用SLOT函数

版权声明：本文为博主原创文章，转载请注明出处，谢谢!

版权声明：本文为博主原创文章，转载请注明出处：http://blog.jerkybible.com/2016/11/04/QT出现重复调用SLOT函数/

访问原文「QT出现重复调用SLOT函数」

问题表现

问题是这样的，在每次重复一些操作之后，总会给我多次调用。而且很有规律，第一轮调用1次，第二轮调用2次，第三轮调用3次，以此类推。

问题修改

源代码是这样的。

connect(rtmpSource, SIGNAL(showCameraInterrtpt()), this, SLOT(showCameraMessageBox());

这样就会有问题，默认的connect每次调用都会建立一个连接，改成下面的代码就好了。

connect(rtmpSource, SIGNAL(showCameraInterrtpt()), this, SLOT(showCameraMessageBox()), Qt::UniqueConnection);

问题原因

Qt信号槽给出了五种连接方式，分别如下。

默认的方式是Qt::AutoConnection，这样是不行的，重复调用connect会建立多个映射，这个时候应该使用Qt::UniqueConnection，这样就没有问题了。

信号槽的调用方式和线程

UniqueConnection 模式：严格说不算连接方式，方式就是4中，此只是一个附加的参数。不讨论。

AutoConnection 模式：这个模式是默认的，但其可以看作是DirectConnection和QueuedConnection的自动选择，直接分析那两种也就行了。

发出信号，调用槽的方式也可以简单的分为两种：同步调用和异步调用

同步调用：发出信号后，当前线程等待槽函数执行完毕后才继续执行。

异步调用：发出信号后，立即执行剩下逻辑，不关心槽函数什么时候执行。

所以有下表：

QT信号连接多个槽，调用顺序

先说基本原则：

槽函数开始调用的顺序和连接的顺序是一致的。

但是，上面也说了，有同步调用和异步调用。

对于同步调用，你观察的结果和基本原则一样。

但是对于异步调用，可能你最先连接的它，但是可能其他都执行完毕了，但是其还没执行。是因为对于异步调用：是开始调用的时候，生成一个需要调用这个函数的事件，然后放到事件队列里。然后立即返回，去执行调用其他槽函数或者槽函数都执行了，不关心槽函数的执行状态的。等到事件队列里任务轮到此事件再去调用。

信号的返回值

大都说Qt信号槽不能使用返回值。其实不不准确的，Qt5中，信号槽是有返回值的。只是Qt的一个信号可以连接多个槽，还有同步调用和异步调用的问题，没发支持的很好，所以，返回值虽有，但只是鸡肋。

先说下返回值的规则把：

• 同步调用才有返回值，异步调用的返回值永远为返回值类型默认构造函数出来的。
• 连接的多个槽都返回值，那么结果是最后调用（连接）的那个。

也就是说对于QueuedConnection连接的信号槽，永远只是返回返回类型的默认构造函数的。对于AutoConnection连接的，如果发出信号的线程和槽函数线程不同亦然。

信号参数的安全问题

因为一个信号可以连接多个槽函数，如果参数是T * 或者是T &的话会不会第一个槽函数改变参数的值，然后第二此调用的参数就已经不是信号发出的值？

1）对于T &： 在同步调用中则是变化的，不可用于异步，不可跨线程。所以BlockingQueuedConnection方式的同步也不行。（T& 不可用在队列调用（QueuedConnection）和阻塞调用（BlockingQueuedConnection）中。只能使用const T &。）

因为同步调用，你可以理解成直接调用，那么连接多个槽函数就相当于直接连续调用多个函数。类似于：

// 函数原型都是：void  (int &a )
int a;
fun1(a);
fun2(a)
·····

// 函数原型都是：void  (int * a )
int a;
pfun1(&a);
pfun2(&a)
·····

这样，当第一个函数执行改变参数值之后，其后的函数调用都要受影响。

2） 对于T *，最好不要同时连接多个槽。

对于同步调用：是一个接着一个调用的，执行顺序类似上面，所以值也是每次调用也会变化的。
对于异步调用：其内容确实不确定的，因为异步调用的时间是不可控的。如果还有跨线程相关，则还有线程安全问题。

##　信号槽性能损失:

注：仅仅代码层进行的理论分析，非实际测试，不严谨，不权威。

关于信号槽（很多吐槽Qt就是说的这个）：

（1）Qt4语法的，都说是匹配字符串，其实只是链接信号槽的用的匹配字符串 的方法，通过字符串找到信号和槽在QMeatObject里存的索引位置int类型，还有槽函数的索引，然后调用的时候通过索引号用switch去区分的 发射的那个函数，然后取出对应的链接槽的list，循环检测槽函数的参数是否匹配，然后调用槽函数。。这个链接时会耗时查找，但是你能有多少信号？这个链 接也耗时不多，调用的时候耗时主要就是在参数匹配上了。

（2）Qt5 语法的，Qt5 的槽函数链接和执行是基于模板实现的，函数对象。信号和槽的参数问题是编译时检查的，执行效率更高，但是编译就慢点了。链接时也是通过信号的地址找到其的 信号索引，至于槽函数直接是生成一个函数对象的，然后调用的时候也是先switch找到发射的信号，取出list，然后逐个调用其储存的函数对象，所以对 于Qt5 语法的信号槽，调用性能损失几乎可以说无的。

（3）链接的信号槽的时候，Qt::UniqueConnection的链接方式会对已经链接过的此先好的槽函数进行遍历，会有链接时的损失。其他链接的损失就在上面说过了。

（4）在信号槽调用的时候，还有一些链接方式和线程的判断和为了安全问题的锁操作。关于这个就还涉及到调用槽函数的线程问题。

对于同线程直接调用，较函数对象直接调用的损失，就只有链接方式和线程的判断的几个if 分支和 锁的操作。
对于线程间通讯的调用，跨线程。信号槽内部也是通过Qt事件循环机制实现的，跨线程就不是时时调用了，主要是安全了，对于性能有没有损失没法评论的。对于跨线程阻塞的调用，这个也是事件实现，只是但发射信号的线程会阻塞，这个找不到对应的直接调用的比较，也不好说。
关于信号槽Qt是作何很多方便使用和安全调用，较之函数指针，性能会有损失，但是也没损失多少的。对于函数对象调用，Qt5语法的调用，几乎是不损失什么的。