保持Qt GUI響應的幾種方法_ZenDei技術網路在線

QThread Qt Gui frozen 未響應阻塞 processEvents ...

最開始使用Qt時就遇到過QT Gui失去響應的問題，我是用多線程的方式解決的，然而通常來說，多線程是會降低程式的運行速度。

之後，在使用QSqlQuery::execBatch()函數時，Qt Gui 又失去響應，雖然多線程可以解決，但是如果能用單線程很好解決的，最好不要用到多線程，因為多線程不僅容易拖慢程式的速度，編程及維護的難度也更大，能用簡單方法解決的，就不要用複雜的方法。

於是我再次搜索資料，期望在解決方案的選擇與解決步驟上，能夠得到一個全面而又細緻的總結。

Witold Wysota 的文章https://doc.qt.io/archives/qq/qq27-responsive-guis.html#performinglongoperations 總結的非常不錯。

Jason Lee的翻譯： http://blog.csdn.net/jasonblog/article/details/5568589

所以本文是在此文基礎上的部分翻譯、理解與二次總結。總之，有刪減，有補充，所以沒寫 '轉' 字。

一、問題的來源與分析

首先，我們要知道 “為什麼Qt Gui 會停止響應？”。簡明扼要的說就是：長時間的密集處理或等待阻塞了Qt的事件迴圈，應用程式不能響應來自視窗系統的事件請求（《C++ Gui Qt4》 P135中有描述）。那麼多長算長呢？一秒鐘算長，兩秒鐘太長。

其次，“ 何種情形下會發生該問題？ ”。可分為兩種情形：

第一，長時間按順序執行的密集運算，全部計算結束後才能繼續執行，如快速傅立葉變換。

第二，“ 觸發 ”了某項操作，該操作完成後才能進行“ 下一步 ”，所以這裡描述的是非同步操作，如保存文件操作，伺服器等待連接、網路下載等。詳細見附註（1）.

私以為兩種情形並無明顯的概念上的區分，本質是一樣的，但兩種情形有不同的處理方法，特別是第二種情形，在Qt框架下，用Qt的信號和槽機制往往可以解決阻塞問題，如QTcpServer::newConnection信號通知連接的到來，QIODevice::bytesWritten()與 QIODevice::readyRead()通知文件的讀寫，它們都是以非阻塞的形式實現相關功能的利器。而第一種情形，不僅所有的事件迴圈停止了，信號和槽也暫時被忽視。我們將針對以上兩種情形尋找解決方案。

最後，我們考慮是否可以把這個造成 Qt Gui 停止響應的罪魁禍首大卸八塊，即把他拆分成一個個小塊，如果可以拆分，那麼每塊之間是依賴還是獨立，如果獨立那問題好辦，放在不同的位置獨立運作，否則，我們只能同步的執行，而最差的結果是——根本無法拆分！！

總之，考慮以上信息差異，執行不同的解決方案。

二、解決方案

Manual event processing（人工執行事件）

保持事件迴圈有一種最基本的方法——讓程式去處理懸掛事件好了，處理完了再回來繼續我的後續運算，要做到這一點，就要在我的運算代碼中間加上處理事件的代碼，這句代碼就是 QCoreApplication::processEvents();，只要該句代碼能夠周期性的被執行，就能保持Qt Gui的響應。

//代碼來源於上述鏈接所指向文章

for (int i = 3; i <= sqrt(x) && isPrime; i += 2) {
        label->setText(tr("Checking %1...").arg(i));
        if (x % i == 0)
            isPrime = false;
        QCoreApplication::processEvents();
        if (!pushButton->isChecked()) {
            label->setText(tr("Aborted"));
            return;
        } 

    }

部分翻譯（略）——可查看 Jason Lee的翻譯

該方案除了具有Witold Wysota文中所提到缺點之外，《C++ Gui Qt4》P135中還提到，用戶可能會在應用程式還在執行某種操作時，或者關閉了主視窗，或者通過界面再次觸發相同操作，這樣就會產生不可預料的後果，如一個保存文件對話框，用戶單擊save按鈕後，程式開始磁碟文件的寫入操作，該操作還未完成時，用戶再次單擊了關閉按鈕，或者再次單擊save按鈕。書中給出的解決辦法是將 qApp->processEvents（）替換為qApp-> processEvents（QEventLoop::ExcludeUserInputEvents）,以告訴Qt忽略滑鼠事件和鍵盤事件。

Using a Worker Thread（使用任務線程）

翻譯（略）—— Jason Lee的翻譯

除了 Witold Wysota 文中所說的重新實現QThread類之外，還可以使用QObject::moveToThread(QThread *thread)函數，將

進行複雜運算的對象移入子線程中運行，前提是子線程不能夠有父對象，否則無法移入子線程。示例如下：

QThread *thread = new QThread(this); 
MyComputation *computation = new  MyComputation();//負責密集運算的對象 
computation->moveToThread(thread); 
connect(thread, SIGNAL(started()), computation ,SLOT( compute()) ); //compute()為computation的運算函數 
thread->start();

需註意的是，將 computation 對象移入子線程後，依舊不可直接調用 computation 對象 compute()函，應該調用線程對象的start()函數，發出started()信號觸發 computation 對象的運算操作，否則依舊會阻塞主線程。

Waiting in a Local Event Loop（在本地事件迴圈中等待）

翻譯（略）—— Jason Lee的翻譯

註解：如文章開頭所說，“等待非同步事件完成”，也就是說這種方法是針對非同步事件而設計的，非同步事件執行過程中會不斷發送信號，我們根據該信號決定程式接下來的行為，包括人工執行事件。而 Manual event processing 適用於順序執行的操作 。

Solving a Problem Step by Step（分步驟解決問題）

翻譯（略）

如前文所說，如果一個複雜操作可以拆分為獨立的子操作，那麼拆分應該是最好的解決辦法。至於如何拆分，可以通過閱讀《重構》這本書來學習。

Parallel Programming
翻譯（略）

三、總結

前面我提到過，我是用queryBatch()函數導致了Qt Gui無法響應的，最後我選擇了 Using a Worker Thread這種方法。queryBatch（）是一個操作資料庫的批處理函數，非常便利，但它是順序執行的，我無法用非同步方式來處理它，函數內部是不可見的，也無法人工執行事件或者拆分，最後只能使用子線程來執行它了，這就是為便利所付出的代價吧。不同情況有不同的解決方案，認清自己的問題很重要。

四、附註

（1） “ 觸發 ”了某項操作，該操作完成後才能進行“ 下一步 ”，但實際上對於“觸發”這個行為本身而言，它的職責已經完成了，而

“下一步”指的是某個功能執行中的“下一步”，當然也可能是編程語境下的“ 下一步 ”，即下一條語句，所以這裡描述的是非同步操作，如保存文件操作，伺服器等待連接、網路下載等。

舉個慄子，創建了QTcpServer對象並調用listen() 函數監聽連接，這時如果調用QTcpServer::waitForNewConnection(...)函數，就會阻塞程式的運行，直到連接到來函數才能返回，進而執行下一句。這裡，listen()函數“ 觸發 ”了監聽行為， “ 下一步 ”與網路連接相關的動作要等連接到來後才能執行，而 QTcpServer::waitForNewConnection(...)則作為我們是否執行下一步的判斷標準，只不過這裡用的是阻塞的方式；對於非同步操作，也可以用非阻塞的方式解決，Qt的信號和槽機制就能很好的解決，如我們可以接收newConnection()信號判斷連接是否到來，而不必將程式阻塞在那。