我最早用 Qt 做項(xiàng)目的時(shí)候最頭疼的就是把界面按鈕和業(yè)務(wù)邏輯串起來。那時(shí)候換過很多寫法回調(diào)、事件、甚至全局變量都試過代碼越寫越亂。后來有個(gè)老同事跟我說了一句別把信號(hào)槽想得太玄乎它就是個(gè)對(duì)講機(jī)。QT信號(hào)與槽從此在我腦子里立住了一個(gè)特別具體的畫面一個(gè)頻道、一呼一應(yīng)發(fā)送信號(hào)的人根本不關(guān)心誰在聽。這篇文章我就把這個(gè)對(duì)講機(jī)模型徹底拆開把信號(hào)槽的配對(duì)規(guī)則、連接方式、生命周期和調(diào)試手段一次講透適合剛接觸 Qt 的初學(xué)者也適合那些寫過一陣子但遇到跨線程、重載、內(nèi)存問題時(shí)總被繞暈的開發(fā)者。1. 從對(duì)講機(jī)說起信號(hào)槽到底幫我們解決了什么問題1.1 回調(diào)函數(shù)與我找你但你不一定在的現(xiàn)實(shí)問題很多圖形界面框架在沒有信號(hào)槽的時(shí)候都在用回調(diào)函數(shù)。比如某個(gè)按鈕被點(diǎn)了框架就調(diào)用你注冊(cè)的那個(gè)函數(shù)指針。聽起來很直接但寫多了你就會(huì)發(fā)現(xiàn)它有幾個(gè)特別別扭的地方。第一個(gè)問題是耦合。你要調(diào)用某個(gè)對(duì)象的方法就得拿到那個(gè)對(duì)象的指針。A 模塊里要放一個(gè) B 模塊的指針B 模塊還要暴露一個(gè)可調(diào)用的接口時(shí)間一長(zhǎng)模塊之間就纏成一團(tuán)。改一個(gè)類名可能要牽連十幾個(gè)文件。第二個(gè)問題是你很難處理“調(diào)用方不知道被調(diào)方是否還活著”的情況。你手里有一個(gè)指針如果那個(gè)對(duì)象已經(jīng)被銷毀了回調(diào)就等于打給一個(gè)已經(jīng)停機(jī)的人程序直接崩潰。第三個(gè)問題是調(diào)用時(shí)機(jī)。同步回調(diào)還能理解異步如何安全地把結(jié)果送回調(diào)用線程這套東西每個(gè)框架都在發(fā)明自己的機(jī)制沒有統(tǒng)一標(biāo)準(zhǔn)。Qt 當(dāng)年的辦法就是設(shè)計(jì)一套信號(hào)槽機(jī)制。它本質(zhì)上改變了一個(gè)關(guān)鍵思路發(fā)送方不需要知道接收方是誰甚至不需要知道有沒有接收方。1.2 對(duì)講機(jī)模型的三個(gè)關(guān)鍵詞頻道、呼喊、應(yīng)答把信號(hào)槽理解成對(duì)講機(jī)你會(huì)發(fā)現(xiàn)所有概念幾乎一一對(duì)應(yīng)。頻道信號(hào)和槽之間用函數(shù)簽名匹配信號(hào)參數(shù)列表和槽參數(shù)列表對(duì)得上雙方就工作在同一個(gè)頻道。按下通話emit mySignal(...)就是你按下對(duì)講機(jī)的通話鍵把消息喊到頻道里。應(yīng)答的接收者所有用connect連接到了這個(gè)信號(hào)、且簽名匹配的槽函數(shù)就是此刻站在頻道上的人。他們會(huì)收到呼叫并做響應(yīng)。對(duì)講機(jī)最大的特征是什么你在喊話的時(shí)候看不到對(duì)方臉上什么表情。發(fā)信方完全不關(guān)心收信方是拿手機(jī)聽還是拿收音機(jī)聽也不關(guān)心是幾個(gè)人在聽。信號(hào)槽也是一樣的。當(dāng)一個(gè)對(duì)象emit一個(gè)信號(hào)時(shí)這個(gè)對(duì)象對(duì)槽函數(shù)一無所知。所有接收方的身份和調(diào)用方式都被connect那層通聯(lián)關(guān)系完全包住了。這個(gè)模型帶來的直接好處就是松耦合。界面按鈕不需要認(rèn)識(shí)業(yè)務(wù)邏輯對(duì)象它只負(fù)責(zé)在用戶點(diǎn)擊時(shí)對(duì)著“頻道”喊一嗓子。至于頻道上有誰在聽聽了之后做什么按鈕類一概不管。接口之間的依賴一下子變?nèi)趿四K可以獨(dú)立編譯、獨(dú)立測(cè)試也能在運(yùn)行期動(dòng)態(tài)地建立或者斷開聯(lián)系。1.3 信號(hào)槽和回調(diào)的核心差異用一個(gè)表格總結(jié)兩者的本質(zhì)區(qū)別維度傳統(tǒng)回調(diào)Qt 信號(hào)槽調(diào)用方向被調(diào)用方必須被發(fā)送方知曉發(fā)送方不知道接收方是誰耦合程度強(qiáng)耦合依賴具體函數(shù)指針和對(duì)象指針弱耦合只約定信號(hào)簽名調(diào)用安全性對(duì)象銷毀后無法自動(dòng)失效接收者銷毀時(shí)連接自動(dòng)斷開異步支持需要自己實(shí)現(xiàn)線程同步跨線程自動(dòng)排隊(duì)投遞運(yùn)行時(shí)動(dòng)態(tài)性靜態(tài)綁定很難在運(yùn)行時(shí)增刪調(diào)用關(guān)系connect/disconnect隨時(shí)可做所以信號(hào)槽不是簡(jiǎn)單地把回調(diào)換個(gè)寫法它把通信機(jī)制本身做成了基礎(chǔ)設(shè)施。對(duì)講機(jī)這個(gè)類比之所以好用就是因?yàn)樗炎詈诵牡脑O(shè)計(jì)思想濃縮成了三個(gè)詞廣播、頻道、解耦。2. 通聯(lián)協(xié)議connect 連接怎么配對(duì)信號(hào)如何觸發(fā)槽2.1 信號(hào)的聲明與元對(duì)象編譯系統(tǒng)信號(hào)在 Qt 里不是普通函數(shù)它得先聲明在類里而且這個(gè)類必須繼承自QObject還要在類聲明里寫上Q_OBJECT宏。class TemperatureDevice : public QObject { Q_OBJECT public: explicit TemperatureDevice(QObject *parent nullptr); signals: void temperatureChanged(double celsius); };signals是一個(gè)宏它定義了一個(gè)訪問權(quán)限為 protected 的區(qū)域。信號(hào)不需要你寫函數(shù)體那部分是 Qt 的元對(duì)象編譯器moc在預(yù)處理步驟里生成的。如果你在類里寫了 signals 但是沒有 Q_OBJECT編譯報(bào)錯(cuò)會(huì)非常詭異通常是一堆“undefined reference to vtable”之類的問題。新手遇到這個(gè)報(bào)錯(cuò)第一反應(yīng)往往是去查鏈接庫(kù)實(shí)際上就是忘了寫 Q_OBJECT 或者改完頭文件沒有重新跑 moc。moc 到底做了什么呢它會(huì)給你的類生成一個(gè)靜態(tài)的元對(duì)象staticMetaObject里面記錄了類的信號(hào)索引、槽函數(shù)索引、屬性信息等。connect函數(shù)在運(yùn)行期就是拿著信號(hào)索引和槽索引建立一張注冊(cè)表。這也就是為什么信號(hào)的聲明里必須寫signals:且不能有實(shí)現(xiàn)。2.2 槽函數(shù)的三類寫法槽函數(shù)從形態(tài)上來講可以分為三類成員函數(shù)、lambda 表達(dá)式、以及任意可調(diào)用對(duì)象。Qt 5 之后推薦直接使用成員函數(shù)指針語法它能拿到編譯期檢查信號(hào)參數(shù)和槽參數(shù)不匹配會(huì)在編譯時(shí)報(bào)錯(cuò)不用等到運(yùn)行時(shí)才知道連不上。// 成員函數(shù)作為槽 connect(device, TemperatureDevice::temperatureChanged, display, TemperatureDisplay::onTemperatureChanged); // lambda 作為槽 connect(device, TemperatureDevice::temperatureChanged, this, [this](double celsius) { ui-label-setText(QString::number(celsius)); }); // 兼容舊式寫法字符串形式的 SIGNAL/SLOT 宏 connect(device, SIGNAL(temperatureChanged(double)), display, SLOT(onTemperatureChanged(double)));我在實(shí)際項(xiàng)目里幾乎不用SIGNAL/SLOT宏原因是它本質(zhì)上是把函數(shù)簽名變成字符串在運(yùn)行時(shí)去匹配拼錯(cuò)一個(gè)參數(shù)類型或者少寫一個(gè)空格都不報(bào)錯(cuò)只在運(yùn)行時(shí)不觸發(fā)。你排查半天才發(fā)現(xiàn)是字符串沒寫對(duì)浪費(fèi)時(shí)間。函數(shù)指針語法在性能上也更好而且編譯期就做了類型和參數(shù)個(gè)數(shù)校驗(yàn)。有個(gè)細(xì)節(jié)要注意Qt 5 新語法對(duì)槽函數(shù)的參數(shù)個(gè)數(shù)有限制槽的參數(shù)個(gè)數(shù)可以比信號(hào)少但是不能比信號(hào)多且參數(shù)類型必須能匹配。多出來的參數(shù)會(huì)被忽略這正好對(duì)應(yīng)對(duì)講機(jī)里“一呼一應(yīng)”的規(guī)則——有人只關(guān)心溫度變化了就刷新一個(gè)圖標(biāo)他可以不關(guān)心具體是多少度所以槽只取前一個(gè)參數(shù)也沒問題。2.3 參數(shù)類型與元類型注冊(cè)不同的信號(hào)要攜帶著不同類型的參數(shù)在對(duì)象之間傳遞。如果信號(hào)和槽是在同一個(gè)線程里直連那參數(shù)傳遞就是普通的函數(shù)調(diào)用直接用 C 對(duì)象沒問題。但是一旦涉及跨線程的排隊(duì)連接QueuedConnection參數(shù)就要被拷貝到事件對(duì)象里然后投遞到接收線程的事件循環(huán)。這個(gè)時(shí)候 Qt 必須知道怎么去拷貝你的自定義類型。對(duì)于內(nèi)置類型和 Qt 自己的類型如int、QString、QVariant它天生就認(rèn)識(shí)。對(duì)于自定義的結(jié)構(gòu)體或者類就得先注冊(cè)元類型struct SensorReading { double temperature; double humidity; }; Q_DECLARE_METATYPE(SensorReading) // 在使用前調(diào)用一次 qRegisterMetaTypeSensorReading(SensorReading);如果你忘了注冊(cè)跨線程連接時(shí)編譯沒問題運(yùn)行時(shí)會(huì)報(bào)“QObject::connect: Cannot queue arguments of type SensorReading”之類的警告信號(hào)就靜默丟失。我遇到過一次生產(chǎn)環(huán)境下的溫濕度數(shù)據(jù)完全不刷新查了半天才發(fā)現(xiàn)是自定義結(jié)構(gòu)體沒注冊(cè)元類型。這個(gè)坑很隱蔽因?yàn)橥粋€(gè)線程里直連可以正常觸發(fā)只有跨線程才炸。2.4 五種連接類型與線程邊界connect的最后一個(gè)參數(shù)可以指定連接類型不寫的話默認(rèn)是AutoConnection。具體行為我整理了一張表連接類型發(fā)送線程與接收線程行為AutoConnection同一線程直連信號(hào)里直接調(diào)用槽AutoConnection不同線程自動(dòng)轉(zhuǎn)隊(duì)列連接DirectConnection任意同步直連在發(fā)送線程執(zhí)行槽函數(shù)QueuedConnection任意投遞到接收線程事件循環(huán)異步執(zhí)行BlockingQueuedConnection不同線程排隊(duì)執(zhí)行但發(fā)送線程阻塞等待槽完成Auto 適合絕大多數(shù)場(chǎng)景它讓同一個(gè)線程內(nèi)的連接退化成直接調(diào)用性能最好跨線程時(shí)自動(dòng)選擇隊(duì)列連接天然避免了對(duì)共享數(shù)據(jù)的同時(shí)寫入。DirectConnection 雖然快但它違背了信號(hào)槽“異步廣播”的直覺變成了一種直接函數(shù)調(diào)用。你要是在一個(gè)工作線程里用 DirectConnection 去連接一個(gè)操作 UI 的槽那槽會(huì)在工作線程里跑Qt 的 UI 操作基本都不是線程安全的程序可能在奇怪的地方崩潰。BlockingQueuedConnection 用的時(shí)候要特別小心死鎖。如果發(fā)送線程在等待接收線程處理完而接收線程里的某個(gè)槽又在等待發(fā)送線程的某個(gè)資源兩邊就卡住了。我一般只在封裝底層硬件線程時(shí)偶爾用它來同步讀取結(jié)果業(yè)務(wù)代碼里很少碰。3. 操作實(shí)戰(zhàn)自定義信號(hào)、lambda、重載這些高頻場(chǎng)景怎么配3.1 自定義信號(hào)和帶參數(shù)發(fā)射做桌面應(yīng)用或者工控上位機(jī)時(shí)你幾乎一定會(huì)需要自定義信號(hào)。比如一個(gè)通信組件收到了設(shè)備回復(fù)就要發(fā)送一個(gè)信號(hào)給界面層。class DeviceClient : public QObject { Q_OBJECT public: void sendHeartbeat(); signals: void responseReceived(const QByteArray data, int sequence); }; void DeviceClient::sendHeartbeat() { // 模擬發(fā)送后異步收到的過程 QByteArray reply m_socket-readAll(); emit responseReceived(reply, m_sequence); }記住emit只是一個(gè)空宏它唯一的作用是告訴讀者“這里是信號(hào)觸發(fā)點(diǎn)”。有沒有它編譯結(jié)果完全一樣。自定義信號(hào)有一點(diǎn)要養(yǎng)成習(xí)慣信號(hào)聲明盡量只發(fā)“發(fā)生了什么”不要把怎么處理也帶到信號(hào)里。比如你要更新界面的溫度顯示不要在信號(hào)里傳一個(gè)已經(jīng)格式化好的字符串而是傳原始的浮點(diǎn)數(shù)讓槽自己去決定是顯示三位小數(shù)還是畫到曲線圖里。這樣可復(fù)用性最好。3.2 槽里寫 lambda 的注意事項(xiàng)lambda 槽讓代碼緊湊了很多不用為了一個(gè)動(dòng)作單獨(dú)聲明一個(gè)槽函數(shù)。但有幾個(gè)細(xì)節(jié)我吃過虧。第一connect沒有上下文對(duì)象時(shí)lambda 里捕獲的對(duì)象如果失效了lambda 照樣會(huì)執(zhí)行只是里面用的是懸空指針。所以四個(gè)參數(shù)的connect一定要寫。那個(gè)this不是擺設(shè)Qt 5 引入 context object 就是為了在你這個(gè)接收對(duì)象即將銷毀的時(shí)候自動(dòng)斷開連接防止槽跑在一個(gè)半死不活的對(duì)象上。// 安全寫法傳入 this 作為上下文 connect(device, TemperatureDevice::temperatureChanged, this, [this](double celsius) { ... });第二lambda 捕獲this之后如果this是個(gè)窗口或者界面類而 lambda 里還要訪問它的成員就要保證 lambda 的執(zhí)行時(shí)機(jī)不在窗口析構(gòu)之后。四參數(shù)connect會(huì)在窗口析構(gòu)時(shí)自動(dòng)disconnect這在大多數(shù)情況下都?jí)蛴谩？扇绻氵B接的是QThread這種長(zhǎng)期存在的對(duì)象發(fā)送者可能比接收者的生命周期長(zhǎng)這就更依賴上下文對(duì)象的保護(hù)機(jī)制。第三lambda 里不要做太重的操作。信號(hào)槽本質(zhì)上還是在某個(gè)線程的某個(gè)函數(shù)調(diào)用鏈上同步阻塞一個(gè)耗時(shí)操作會(huì)卡住界面或阻塞事件循環(huán)。3.3 信號(hào)重載與 QOverload 的拆彈Qt 自帶的一些信號(hào)有多個(gè)重載版本最典型的是QComboBox::currentIndexChanged。老版本里它有int版本和QString版本直接用函數(shù)指針QComboBox::currentIndexChanged會(huì)出現(xiàn)指針歧義編譯直接給你報(bào)錯(cuò)而且提示信息還特別繞。Qt 5.7 之后推薦用QOverload來化解connect(comboBox, QOverloadint::of(QComboBox::currentIndexChanged), this, [this](int index) { ... }); // 也可以把 QOverloadint::of 換成 qOverloadint connect(comboBox, qOverloadint(QComboBox::currentIndexChanged), this, MainWindow::onIndexChanged);我自己寫到重載信號(hào)時(shí)更徹底的辦法是封裝一個(gè)槽函數(shù)來轉(zhuǎn)接信號(hào)參數(shù)這樣槽的簽名穩(wěn)定后面維護(hù)不容易混。例如給QComboBox的信號(hào)先統(tǒng)一轉(zhuǎn)成自定義信號(hào)再往外分發(fā)。當(dāng)然QOverload是標(biāo)準(zhǔn)做法大多數(shù)場(chǎng)景直接用它就夠了。3.4 UI 線程響應(yīng)與 QueuedConnection 隊(duì)列跨線程連接是信號(hào)槽最有價(jià)值的地方之一。工作線程里完成網(wǎng)絡(luò)請(qǐng)求或文件讀寫后要把結(jié)果送回到 UI 線程刷新界面。你只需要把界面的槽函數(shù)連接到工作線程對(duì)象的信號(hào)上默認(rèn) AutoConnection 就會(huì)自動(dòng)用隊(duì)列連接把調(diào)用投遞到 UI 線程。// 工作線程中執(zhí)行完畢后 emit resultReady(resultData); // 界面類里連接 connect(worker, Worker::resultReady, this, MainWindow::showResult);這個(gè)調(diào)用的關(guān)鍵機(jī)制是QueuedConnection。它不直接調(diào)用槽函數(shù)而是把信號(hào)參數(shù)打包成一個(gè)QMetaCallEvent投遞到接收對(duì)象所屬線程的事件循環(huán)里。接收對(duì)象所在線程的事件循環(huán)在某個(gè)時(shí)刻取出事件再調(diào)用對(duì)應(yīng)的槽函數(shù)。這就保證了槽函數(shù)一定在接收線程里執(zhí)行不需要你手動(dòng)加互斥鎖來保護(hù)界面對(duì)象。但使用 QueuedConnection 時(shí)要考慮參數(shù)拷貝的成本。如果信號(hào)里帶一個(gè)巨大的容器比如幾百兆的圖片緩沖跨線程隊(duì)列連接會(huì)完整拷貝一份再投遞。這種場(chǎng)景不適合用信號(hào)槽傳輸大數(shù)據(jù)應(yīng)該改用QSharedPointer之類的共享指針或直接考慮線程間消息隊(duì)列方案。我一般在信號(hào)參數(shù)里只放輕量結(jié)構(gòu)或者指針的句柄大數(shù)據(jù)走共享對(duì)象或者文件路徑。4. 對(duì)講機(jī)不關(guān)機(jī)就帶出會(huì)議室生命周期和內(nèi)存管理的坑4.1 接收者銷毀時(shí)自動(dòng)斷開的機(jī)制信號(hào)槽在 Qt 5 里默認(rèn)是支持自動(dòng)斷開的。如果接收者是QObject的子類并且 Qt 能拿到它的析構(gòu)信息那么當(dāng)接收者被銷毀時(shí)所有指向它的連接都會(huì)被移除。這個(gè)機(jī)制是怎么做到的每個(gè)QObject內(nèi)部都保存了一份連接記錄在析構(gòu)時(shí)會(huì)主動(dòng)通知所有發(fā)送者把這組連接刪掉。你用四參數(shù)connect傳入的 context object 也是同一套機(jī)制。如果用了三參數(shù)或兩參數(shù)的connect沒有 context object就少了這層自動(dòng)斷開的保障。所以在動(dòng)態(tài)創(chuàng)建和銷毀對(duì)象的場(chǎng)景里比如一個(gè)彈窗關(guān)閉后再打開新窗口也務(wù)必要在 connect 里傳入接收對(duì)象的this。有一種常犯的錯(cuò)誤是連接到一個(gè)由裸指針管理的臨時(shí)對(duì)象對(duì)象銷毀后信號(hào)還在發(fā)運(yùn)行到那個(gè)舊地址上就崩潰了。4.2 發(fā)射信號(hào)的 this 被 delete 的翻車現(xiàn)場(chǎng)反向的坑更常見發(fā)送者對(duì)象被 delete 了但連接還掛在接收者那邊。TemperatureDevice *device new TemperatureDevice(this); connect(device, TemperatureDevice::temperatureChanged, this, MainWindow::onTemperatureChanged); delete device; // device 已經(jīng)沒了 device-setTemperature(36.5); // 崩潰現(xiàn)場(chǎng)發(fā)送者被刪除后如果代碼里還有它的指針并且調(diào)用它的方法程序自然崩。但要注意的是連接本身在發(fā)送者銷毀時(shí)也會(huì)被清理因?yàn)榘l(fā)送者的析構(gòu)函數(shù)會(huì)移除它關(guān)聯(lián)出去的信號(hào)連接。麻煩的是你無法靠信號(hào)槽機(jī)制來保護(hù)一個(gè)已經(jīng)被你手動(dòng) delete 的發(fā)送者這是最底層的內(nèi)存所有權(quán)問題。正確做法是統(tǒng)一用父子對(duì)象關(guān)系或者智能指針來管理生命周期。界面對(duì)象掛到窗口這個(gè) parent 下業(yè)務(wù)對(duì)象掛到某個(gè)管理對(duì)象下不要輕易手動(dòng) delete。4.3 用 QPointer 和 QMetaObject::Connection 保護(hù)連接QMetaObject::Connection是connect返回的一個(gè)連接句柄。你可以保存它之后手動(dòng)disconnect或者判斷連接是否有效。QMetaObject::Connection conn connect(device, TemperatureDevice::temperatureChanged, this, MainWindow::onTemperatureChanged); // 某處條件滿足時(shí)斷開 if (needStop) { disconnect(conn); }這個(gè)句柄特別適合“一次性監(jiān)聽”的需求比如一個(gè)進(jìn)度條走完就斷開或者等待某個(gè)異步結(jié)果只觸發(fā)一次。QPointer則是一個(gè)能感知對(duì)象銷毀的弱指針。它不增加引用計(jì)數(shù)但如果所指向的QObject被銷毀了它會(huì)自動(dòng)變成nullptr。在槽里如果收到了一個(gè)其他對(duì)象傳來的指針這個(gè)指針很可能來自裸指針用QPointer收一下更安全QPointerDeviceClient m_client; void MainWindow::onClientEvent() { if (m_client.isNull()) { qWarning() client already destroyed; return; } m_client-doSomething(); }在實(shí)踐中這類保護(hù)面向的是那些生命周期確實(shí)不好管理的對(duì)象例如插件系統(tǒng)里動(dòng)態(tài)加載卸載的模塊。常規(guī)界面對(duì)象用 parent 機(jī)制就夠了不要每個(gè)地方都上防御式編程那樣代碼會(huì)很啰嗦。5. 場(chǎng)景選擇題什么時(shí)候用信號(hào)槽什么時(shí)候別硬用5.1 高頻率信號(hào)的性能問題信號(hào)槽再方便也不等于所有對(duì)象間協(xié)作都該用它。性能上有個(gè)基本常識(shí)DirectConnection 調(diào)用一個(gè)槽并不比普通虛函數(shù)慢很多但有元對(duì)象查找和參數(shù)壓棧開銷?？梢坏┯昧?QueuedConnection即使參數(shù)是一個(gè)int也要跨事件循環(huán)做一次事件分配、排隊(duì)、序列化和信號(hào)再分發(fā)。如果這些操作發(fā)生在 UI 線程整體延遲能達(dá)到微秒到幾十微秒量級(jí)。所以高頻信號(hào)場(chǎng)景要特別謹(jǐn)慎。第二就是接收者執(zhí)行槽函數(shù)本身的開銷。如果你在一個(gè)鼠標(biāo)移動(dòng)事件里每秒觸發(fā)幾百次信號(hào)每次槽函數(shù)里做復(fù)雜的槽函數(shù)重繪操作界面直接掉幀。我遇到過一個(gè)實(shí)際案例一個(gè)上位機(jī)軟件需要實(shí)時(shí)顯示設(shè)備軌跡點(diǎn)原作者把每個(gè)點(diǎn)都通過信號(hào)槽發(fā)給繪圖控件頻率是每秒 120 幀。程序跑起來 CPU 直接占滿后來改成繪圖控件內(nèi)部用時(shí)間戳聚合這批點(diǎn)信號(hào)只負(fù)責(zé)通知刷新性能一下就好了。信號(hào)槽更適合“低頻但語義明確”的事件高頻的連續(xù)數(shù)據(jù)流應(yīng)該走專門的數(shù)據(jù)緩沖或者直接調(diào)用 API。5.2 多線程任務(wù)派發(fā)的正確做法跨線程派發(fā)任務(wù)時(shí)隊(duì)列連接是靠譜的手段但要注意別把信號(hào)槽當(dāng)成通用線程調(diào)度器。一個(gè)很常見的錯(cuò)誤是希望某個(gè)信號(hào)恰好只觸發(fā)一次槽函數(shù)結(jié)果因?yàn)閏onnect被調(diào)用了多次槽函數(shù)執(zhí)行了兩三次。或者在循環(huán)里動(dòng)態(tài)創(chuàng)建對(duì)象時(shí)不小心把一個(gè)信號(hào)連接到了多個(gè)對(duì)象上導(dǎo)致重復(fù)響應(yīng)。多線程任務(wù)派發(fā)我更推薦的模式是工作線程通過信號(hào)報(bào)告“完成事件”UI 線程通過信號(hào)下發(fā)“新任務(wù)”或“取消任務(wù)”兩者之間的數(shù)據(jù)傳遞用隊(duì)列或共享對(duì)象。比如一個(gè)任務(wù)管理類接收界面的開始命令跑完再把結(jié)果通過結(jié)果信號(hào)發(fā)回界面。這個(gè)模式里信號(hào)槽扮演的是事件通知的角色數(shù)據(jù)傳輸交給更可靠的容器。5.3 可以直接調(diào)用時(shí)才不要繞道還有一種反模式兩個(gè)對(duì)象在同一個(gè)線程方法直接調(diào)用明明就行非要發(fā)明一個(gè)信號(hào)轉(zhuǎn)一圈。比如一個(gè)模型類新到了一個(gè)值界面代碼可以直接調(diào)用display-showValue(value)如果非要先定義一個(gè)valueArrived信號(hào)再讓界面類去連接這純粹是增加了代碼量和鏈路。我自己的判斷標(biāo)準(zhǔn)是這樣的如果 A 對(duì)象已經(jīng)持有 B 對(duì)象的指針且 B 對(duì)象的接口是穩(wěn)定的同時(shí)兩者生命周期明確由同一模塊管理那就直接調(diào)用。信號(hào)槽用在真正“A 不知道誰關(guān)心”的場(chǎng)景比如一個(gè)設(shè)備管理器管著一堆設(shè)備每個(gè)設(shè)備狀態(tài)變化都要通知多個(gè)不同的 UI 部件這時(shí)用信號(hào)槽廣播就非常合適。簡(jiǎn)單的點(diǎn)對(duì)點(diǎn)同步調(diào)用用信號(hào)槽反而是自找麻煩。6. 調(diào)試信號(hào)槽的實(shí)戰(zhàn)經(jīng)驗(yàn)定位連不上、不觸發(fā)、重復(fù)觸發(fā)的三板斧6.1 檢查 connect 的返回值和警告輸出連不上、不觸發(fā)這類問題第一步永遠(yuǎn)是檢查connect是否成功。函數(shù)指針語法下connect返回QMetaObject::Connection如果連接失敗這個(gè)句柄是無效的。你可以在開發(fā)階段專門寫一個(gè)輔助函數(shù)static bool safeConnect(const QObject *sender, const char *signal, const QObject *receiver, const char *method) { QMetaObject::Connection conn QObject::connect(sender, signal, receiver, method); if (!conn) { qWarning() Connection failed: sender-metaObject()-className() signal - receiver-metaObject()-className() method; } return conn; }Qt 本身在連接失敗時(shí)也會(huì)輸出警告詳細(xì)告訴你信號(hào)的參數(shù)類型和槽的參數(shù)類型哪里不匹配。我看到的最常見原因是槽參數(shù)比信號(hào)參數(shù)多以及自定義類型沒有注冊(cè)。先看這兩點(diǎn)多半能解決一半問題。6.2 用 QSignalSpy 驗(yàn)證信號(hào)確實(shí)發(fā)出來了如果connect是成功的槽還是不觸發(fā)那就要判斷到底是信號(hào)沒發(fā)還是槽收到之后代碼邏輯有問題。這時(shí)候QSignalSpy是你最好的朋友。它專門用來在測(cè)試?yán)锊东@ Qt 信號(hào)。#include QSignalSpy TemperatureDevice device; QSignalSpy spy(device, TemperatureDevice::temperatureChanged); device.setTemperature(36.5); device.setTemperature(37.0); QCOMPARE(spy.count(), 2); QVERIFY(spy.first().at(0).toDouble() 36.5);你在開發(fā)時(shí)也可以臨時(shí)用QSignalSpy做一個(gè)小測(cè)試程序來確認(rèn)某個(gè)信號(hào)是否真的被emit了。如果 spy 捕獲到了信號(hào)說明信號(hào)鏈路正常問題在槽函數(shù)或者連接上如果 spy 都沒捕獲到說明問題出在發(fā)送端壓根沒有觸發(fā)。6.3 重復(fù)連接、Lambda 捕獲和直連/隊(duì)列混淆的常見坑第三類實(shí)踐問題一般不報(bào)錯(cuò)只是行為不符合預(yù)期。重復(fù)連接是最常見的。你在界面初始化里調(diào)用了兩次connect同一個(gè)信號(hào)連著同一個(gè)槽寫了兩次事件一來槽就跑兩遍。有些老代碼在showEvent里做連接窗口每次顯示都會(huì)再連一次問題只在特定時(shí)序下偶現(xiàn)特別難排查。解決辦法很簡(jiǎn)單把連接統(tǒng)一放到構(gòu)造函數(shù)或初始化函數(shù)里并且用成員變量保存連接句柄在重新連接之前先disconnect舊句柄。lambda 捕獲的坑在 3.2 節(jié)詳細(xì)說過這里補(bǔ)充一個(gè)排錯(cuò)的順序。如果槽根本沒跑先在 lambda 入口加一句qDebug()打印信號(hào)攜帶的參數(shù)。如果打印都沒有檢查連接參數(shù)和信號(hào)觸發(fā)點(diǎn)。如果打印有但是界面沒變化再檢查是否在跨線程隊(duì)列連接中界面對(duì)象其實(shí)在另一個(gè)線程里被操作了這會(huì)導(dǎo)致看起來“沒變化”。還有一個(gè)經(jīng)典陷阱是DirectConnection跨線程被誤用。你在工作線程里通過emit觸發(fā)了 UI 線程的槽但因?yàn)轱@式指定了DirectConnection槽直接跑在工作線程里Qt 的 UI 操作在這種狀態(tài)下會(huì)偶爾好偶爾壞典型的未定義行為。這種情況下要么刪掉顯式連接類型讓 Auto 決定要么改為 QueuedConnection 明確投遞。最后分享一個(gè)我自己的習(xí)慣開發(fā)環(huán)境中開啟 Qt 的調(diào)試輸出設(shè)置QT_LOGGING_RULES環(huán)境變量為*.debugtrue或者在main里調(diào)用QLoggingCategory::setFilterRules把信號(hào)相關(guān)的警告全部打到控制臺(tái)。Qt 元對(duì)象系統(tǒng)在連接失敗、參數(shù)不匹配、跨線程試圖調(diào)用不存在的槽時(shí)都會(huì)輸出詳細(xì)日志這些信息比你自己盲猜要可靠得多。真正理解了信號(hào)槽的對(duì)講機(jī)模型之后遇到這類問題基本能在一輪日志里定位不用再靠 qDebug 到處捅。