Qt的信号和槽是如何工作的

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

用Qt做过开发的朋友，不知道是否曾为下面这些问题疑惑过：
我们知道Qt是基于C++的，Qt写的代码最终还是要由C++编译器来编译，但是我们的Qt代码中有很多C++里没有的关键字，比如slots\signals\Q_OBJECT等，为什么C++编译器会放过他们呢？
Qt的槽函数跟普通的成员函数有何区别？一个信号发出后，与之关联的槽函数是什么时候由谁来调用的？
Qt的信号定义跟函数定义有相同的形式，那信号跟普通函数有何区别？一个信号被emit时我们的程序到底在干什么？
信号和槽的连接是怎么建立的？又是如何断开的？
本篇博文里对这些问题作了详尽的解释，初学Qt或者用了很长时间Qt却很少思考过这些问题的朋友，可以在下面的段落中找到答案。

下文出自- original：http://woboq.com/blog/how-qt-signals-slots-work.html

译：NewThinker_Jiwey NewThinker_wei @CSDN

很多人都知道Qt的信号和槽机制，但它究竟是如何工作的呢？在本篇博文中，我们会探索QObject 和 QMetaObject 内部的一些具体实现，揭开信号-槽的神秘面纱。

在本篇博文中，我会贴出部分Qt5的源码，有时候会根据需要改变一下格式并做一些简化。

首先，我们看一个官方例程，借此回顾一下信号和槽的使用方法。

头文件是这样的：

***********************************************

class Counter :publicQObject
{
    Q_OBJECT
    int m_value;
public:
    int value()const {returnm_value; }
public slots:
    void setValue(intvalue);
signals:
    void valueChanged(intnewValue);
};

***********************************************

在源文件的某个地方，可以找到setValue()函数的实现：

***********************************************

voidCounter::setValue(intvalue)

{

   if (value !=m_value){

       m_value =value; emitvalueChanged(value);

    }

}

***********************************************

然后开发者可以像下面这样使用Counter的对象：

***********************************************

Counter a, b;
  QObject::connect(&a,SIGNAL(valueChanged(int)),
                   &b, SLOT(setValue(int)));

a.setValue(12); // a.value() == 12, b.value() == 12

***********************************************

这是从1992年Qt最初阶段开始就沿用下来而几乎没有变过的原始语法。

虽然基本的API并没有怎么变过，但它的实现方式却变了几次。很多新特性被添加了进来，底层的实现也发生了很多变化。不过这里面并没有什么神奇的难以理解的东西，本篇博文会向你展示这究竟是如何工作的，

MOC，元对象编译器

Qt的信号/槽和属性系统都基于其能在运行时刻对对象进行实时考察的功能。实时考察意味着即使在运行过程中也可以列出一个对象有哪些方法（成员函数）和属性，以及关于它们的各种信息(比如参数类型)。如果没有实时考察这个功能，QtScript 和 QML 就基本不可能实现了。

C++本身不提供对实时考察的支持，所以Qt就推出了一个工具来提供这个支持。这个工具就是MOC。注意，它是一个代码生成器，而不是很多人说的“预编译器”。

MOC会解析头文件并为每一个含有Q_OBJECT宏的头文件生成一个对应的C++文件(这个文件会跟工程中的其他代码一块参与编译)。这个生成的C++文件包含了实时考察功能所需的全部信息（文件一般被命名为moc_HeaderName。cpp）。

因为这个额外的代码生成器，Qt有时对语言会有很严格的要求。 这里我就让这篇Qt文档来解释这个严格的要求。代码生成器没有什么错误，MOC起到了很大的作用。

几个神奇的宏

你能看出这几个关键字并不是标准C++的关键字吗？signals, slots, Q_OBJECT, emit, SIGNAL, SLOT. 这些都是Qt对C++的扩展。这几个关键字其实都是很简单的宏定义而已，在qobjectdefs.h 头文件中可以找到他们的定义。

没错，信号和槽都是很简单的功能：编译器会将他们与其他任何宏一样处理。不过这些宏还有一个特殊的作用：MOC会发现他们。

Signals在Qt4之前都是protected类型的，他们在Qt5中变为了public，这样就可以使用一些新的语法了。

emit是个空的宏定义，而且MOC也不会对它进行解析。也就是，emit完全是可有可无的，他没有任何意义（除了对开发者有提示作用）。

（译注：对于#define的一些高级用法，参见我整理的一片文章：http://blog.csdn.net/newthinker_wei/article/details/8893407）

上面这些宏，会利用预编译器将一些参数转化成字符串，并且在前面添加上编码。

在调试模式中，如果singnal的连接出现问题，我们提示警告信息的时候还会注明对应的文件位置。这是在Qt4.5之后以兼容方式添加进来的功能。为了知道代码对应的行信息，我们可以用qFlagLocation ，它会将对应代码的地址信息注册到一个有两个入口的表里。

MOC生成的代码

我们现在就来看看Qt5的moc生成的部分代码。

The QMetaObject

***********************************************

const QMetaObject Counter::staticMetaObject = {
    { &QObject::staticMetaObject,qt_meta_stringdata_Counter.data,
      qt_meta_data_Counter, qt_static_metacall,0,0}
};

const QMetaObject *Counter::metaObject()const
{
    return QObject::d_ptr->metaObject ? QObject::d_ptr->dynamicMetaObject() : &staticMetaObject;
}

***********************************************

我们在这里可以看到Counter::metaObject()和 Counter::staticMetaObject 的实现。他们都是在Q_OBJECT宏中被声明的。

QObject::d_ptr->metaObject 只被用于动态元对象（QML对象），随意通常虚函数metaObject()只是返回类的staticMetaObject 。

staticMetaObject被创建为只读数据。qobjectdefs.h 文件中QMetaObject的定义如下：

代码中用的d是为了表明那些数据都本应为私有的。然而他们并没有成为私有的是为了保持它为POD和允许静态初始化。（译注：在C++中，我们把传统的C风格的struct叫做POD（Plain Old Data），字面意思古老的普通的结构体）。

这里会用父类对象的元对象（此处就是指QObject::staticMetaObject ）来初始化QMetaObject的superdata，而它的stringdata 和 data 这两个成员则会用之后要讲到的数据初始化。static_metacall是一个被初始化为 Counter::qt_static_metacall的函数指针。

实时考察功能用到的数据表

首先，我们来分析 QMetaObject的这个整型数组：

***********************************************

static const uint qt_meta_data_Counter[] = {

// content:
       7,       // revision
       0,       // classname
       0,    0, // classinfo
       2,   14, // methods
       0,    0, // properties
       0,    0, // enums/sets
       0,    0, // constructors
       0,       // flags
       1,       // signalCount

// signals: name, argc, parameters, tag, flags
       1,    1,   24,    2, 0x05,

// slots: name, argc, parameters, tag, flags
       4,    1,   27,    2, 0x0a,

// signals: parameters
    QMetaType::Void,QMetaType::Int,   3,

// slots: parameters
    QMetaType::Void,QMetaType::Int,   5,

0        // eod
};

***********************************************

开头的13个整型数组成了结构体的头信息。对于有两列的那些数据，第一列表示某一类项目的个数，第二列表示这一类项目的描述信息开始于这个数组中的哪个位置（索引值）。

这里，我们的Counter类有两个方法，并且关于方法的描述信息开始于第14个int数据。

每个方法的描述信息由5个int型数据组成。第一个整型数代表方法名，它的值是该方法名（译注：方法名就是个字符串）在字符串表中的索引位置（之后会介绍字符串表）。第二个整数表示该方法所需参数的个数，后面紧跟的第三个数就是关于参数的描述（译注：它表示与参数相关的描述信息开始于本数组中的哪个位置，也是个索引）。我们现在先忽略掉tag和flags。对于每个函数，Moc还会保存它的返回类型、每个参数的类型、以及参数的名称。

字符串表

***********************************************

struct qt_meta_stringdata_Counter_t {
    QByteArrayData data[6];
    char stringdata[47];
};
#define QT_MOC_LITERAL(idx, ofs, len) \
Q_STATIC_BYTE_ARRAY_DATA_HEADER_INITIALIZER_WITH_OFFSET(len, \
offsetof(qt_meta_stringdata_Counter_t, stringdata) + ofs \
- idx * sizeof(QByteArrayData) \
)
static const qt_meta_stringdata_Counter_tqt_meta_stringdata_Counter = {
    {
QT_MOC_LITERAL(0,0,7),
QT_MOC_LITERAL(1,8,12),
QT_MOC_LITERAL(2,21,0),
QT_MOC_LITERAL(3,22,8),
QT_MOC_LITERAL(4,31,8),
QT_MOC_LITERAL(5,40,5)
    },
    "Counter\0valueChanged\0\0newValue\0setValue\0"
    "value\0"
};
#undef QT_MOC_LITERAL

***********************************************

这主要就是一个QByteArray的静态数组。QT_MOC_LITERAL 这个宏可以创建一个静态的QByteArray ，其数据就是参考的在它下面的对应索引处的字符串。

信号

Qt::HANDLE currentThreadId = QThread::currentThreadId();

    /* ... Skipped some debugging and QML hooks, and some sanity check ... */

/*跳过一些调试代码和完整性检测*/
    /* We lock a mutex because all operations in the connectionLists are thread safe */

/*这里用一个互斥量锁住，因为在ConnectionList里的所有操作都应是线程安全的*/
    QMutexLocker locker(signalSlotLock(sender));

/* Get the ConnectionList for this signal. I simplified a bit here. The real code
* also refcount the list and do sanity checks */

/*得到这个信号的ConnectionList。这里我做了一些简化。原来的代码还有完整性检测等*/
    QObjectConnectionListVector *connectionLists =sender->d_func()->connectionLists;
    const QObjectPrivate::ConnectionList *list =
        &connectionLists->at(signal_index);

QObjectPrivate::Connection *c = list->first;
    if (!c) continue;
    // We need to check against last here to ensure that signals added
// during the signal emission are not emitted in this emission.
    QObjectPrivate::Connection *last = list->last;

/* Now iterates, for each slot */
    do {
        if (!c->receiver)
            continue;

QObject * const receiver = c->receiver;

/*译注：比较当前正在运行的线程的ID与receiver所属的线程的ID是否相同*/
        const bool receiverInSameThread = QThread::currentThreadId() == receiver->d_func()->threadData->threadId;

// determine if this connection should be sent immediately or
// put into the event queue

//译注：注意下面这一段，从这里可以看出对于跨线程的连接，信号发出

//后槽函数不会立即在当前线程中执行。其执行要等到槽函数所在的线程被

//激活后。有时间了再研究一下queued_activate这个函数。
        if ((c->connectionType == Qt::AutoConnection && !receiverInSameThread)
            || (c->connectionType == Qt::QueuedConnection)) {
            /* Will basically copy the argument and post an event */
            queued_activate(sender,signal_index,c,argv);
            continue;
        } else if (c->connectionType == Qt::BlockingQueuedConnection) {
            /* ... Skipped ... */
            continue;
        }

/* Helper struct that sets the sender() (and reset it backs when it
* goes out of scope */
        QConnectionSenderSwitcher sw;
        if (receiverInSameThread)
            sw.switchSender(receiver,sender,signal_index);

const QObjectPrivate::StaticMetaCallFunctioncallFunction =c->callFunction;
        const int method_relative = c->method_relative;
        if (c->isSlotObject) {
            /* ... Skipped.... Qt5-style connection to function pointer */
        } else if (callFunction &&c->method_offset <=receiver->metaObject()->methodOffset()) {
            /* If we have a callFunction (a pointer to the qt_static_metacall
* generated by moc) we will call it. We also need to check the
* saved metodOffset is still valid (we could be called from the
* destructor) */
            locker.unlock();// We must not keep the lock while calling use code
            callFunction(receiver,QMetaObject::InvokeMetaMethod,method_relative,argv);
            locker.relock();
        } else {
            /* Fallback for dynamic objects */
            const int method =method_relative +c->method_offset;
            locker.unlock();
            metacall(receiver,QMetaObject::InvokeMetaMethod,method,argv);
            locker.relock();
        }

// Check if the object was not deleted by the slot
        if (connectionLists->orphaned)break;
    } while (c != last && (c = c->nextConnectionList) !=0);
}
***********************************************