最開始使用Qt時就遇到過QT Gui失去響應的問題，我是用多線程的方式解決的，然而通常來說，多線程是會降低程序的運行速度。
之后，在使用QSqlQuery::execBatch()函數(shù)時，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
所以本文是在此文基礎上的部分翻譯、理解與二次總結?？傊袆h減，有補充，所以沒寫 '轉(zhuǎn)' 字。
一、問題的來源與分析
首先，我們要知道 “為什么Qt Gui 會停止響應？”。簡明扼要的說就是：長時間的密集處理或等待阻塞了Qt的事件循環(huán)，應用程序不能響應來自窗口系統(tǒng)的事件請求（《C++ Gui Qt4》 P135中有描述）。 那么多長算長呢？一秒鐘算長，兩秒鐘太長。
其次，“ 何種情形下會發(fā)生該問題？ ”。可分為兩種情形：
第一，長時間按順序執(zhí)行的密集運算，全部計算結束后才能繼續(xù)執(zhí)行，如快速傅立葉變換。
第二，“ 觸發(fā) ”了某項操作，該操作完成后才能進行“ 下一步 ”， 所以這里描述的是異步操作，如保存文件操作，服務器等待連接、網(wǎng)絡下載等。詳細見附注（1）.
私以為兩種情形并無明顯的概念上的區(qū)分，本質(zhì)是一樣的，但兩種情形有不同的處理方法，特別是第二種情形， 在Qt框架下 ，用Qt的信號和槽機制往往可以解決阻塞問題，如QTcpServer::newConnection信號通知連接的到來，QIODevice::bytesWritten()與 QIODevice::readyRead()通知文件的讀寫，它們都是以非阻塞的形式實現(xiàn)相關功能的利器。 而第一種情形，不僅所有的事件循環(huán)停止了，信號和槽也暫時被忽視。我們將針對以上兩種情形尋找解決方案。
最后，我們考慮是否可以把這個造成 Qt Gui 停止響應的罪魁禍首大卸八塊，即把他拆分成一個個小塊，如果可以拆分，那么每塊之間是依賴還是獨立，如果獨立那問題好辦，放在不同的位置獨立運作，否則，我們只能同步的執(zhí)行，而最差的結果是——根本無法拆分?。?/p>
總之，考慮以上信息差異，執(zhí)行不同的解決方案。
二、解決方案
Manual event processing（人工執(zhí)行事件）
保持事件循環(huán)有一種最基本的方法——讓程序去處理 懸掛事件好了 ，處理完了再回來繼續(xù)我的后續(xù)運算，要做到這一點，就要在我的運算代碼中間加上處理事件的代碼，這句代碼就是 QCoreApplication::processEvents();，只要該句代碼能夠周期性的被執(zhí)行，就能保持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中還提到，用戶可能會在應用程序還在執(zhí)行某種操作時，或者關閉了主窗口，或者通過界面再次觸發(fā)相同操作，這樣就會產(chǎn)生不可預料的后果，如 一個保存文件對話框，用戶單擊save按鈕后，程序開始磁盤文件的寫入操作，該操作還未完成時，用戶再次單擊了關閉按鈕，或者再次單擊save按鈕。書中給出的解決辦法是將 qApp->processEvents（）替換為qApp-> processEvents（QEventLoop::ExcludeUserInputEvents）,以告訴Qt忽略鼠標事件和鍵盤事件。
Using a Worker Thread（使用任務線程）
翻譯（略）—— Jason Lee的翻譯
除了 Witold Wysota 文中所說的重新實現(xiàn)QThread類之外，還可以使用QObject::moveToThread(QThread *thread)函數(shù)，將
進行復雜運算的對象移入子線程中運行，前提是子線程不能夠有父對象，否則無法移入子線程。示例如下：
QThread *thread = new QThread(this); MyComputation *computation = new MyComputation();//負責密集運算的對象 computation->moveToThread(thread); connect(thread, SIGNAL(started()), computation ,SLOT( compute()) ); //compute()為computation的運算函數(shù) thread->start();
需注意的是，將 computation 對象移入子線程后， 依舊不可直接調(diào)用 computation 對象 compute()函，應該調(diào)用線程對象的start()函數(shù)，發(fā)出started()信號觸發(fā) computation 對象的運算操作，否則依舊會阻塞主線程。
Waiting in a Local Event Loop（在本地事件循環(huán)中等待）
翻譯（略）—— Jason Lee的翻譯
注解：如文章開頭所說，“等待異步事件完成”，也就是說這種方法是針對異步事件而設計的，異步事件執(zhí)行過程中會不斷發(fā)送信號，我們根據(jù)該信號決定程序接下來的行為，包括人工執(zhí)行事件。而 Manual event processing 適用于順序執(zhí)行的操作 。
Solving a Problem Step by Step（分步驟解決問題）
翻譯（略）
如前文所說，如果一個復雜操作可以拆分為獨立的子操作，那么拆分應該是最好的解決辦法。至于如何拆分，可以通過閱讀《重構》這本書來學習。
Parallel Programming
翻譯（略）
三、總結
前面我提到過，我是用queryBatch()函數(shù)導致了Qt Gui無法響應的，最后我選擇了 Using a Worker Thread這種方法。queryBatch（）是一個操作數(shù)據(jù)庫的批處理函數(shù)，非常便利，但它是順序執(zhí)行的，我無法用異步方式來處理它，函數(shù)內(nèi)部是不可見的，也無法人工執(zhí)行事件或者拆分，最后只能使用子線程來執(zhí)行它了，這就是為便利所付出的代價吧。不同情況有不同的解決方案，認清自己的問題很重要。
四、附注
（1） “ 觸發(fā) ”了某項操作，該操作完成后才能進行“ 下一步 ”，但實際上對于“觸發(fā)”這個行為本身而言，它的職責已經(jīng)完成了，而
“下一步”指的是某個功能執(zhí)行中的“下一步”，當然也可能是編程語境下的“ 下一步 ”，即下一條語句， 所以這里描述的是異步操作，如保存文件操作，服務器等待連接、網(wǎng)絡下載等。
舉個栗子， 創(chuàng)建了QTcpServer對象并調(diào)用listen() 函數(shù)監(jiān)聽連接，這時如果調(diào)用QTcpServer::waitForNewConnection(...)函數(shù)，就會阻塞程序的運行，直到連接到來函數(shù)才能返回，進而執(zhí)行下一句。這里，listen()函數(shù)“ 觸發(fā) ”了監(jiān)聽行為， “ 下一步 ”與網(wǎng)絡連接相關的動作要等連接到來后才能執(zhí)行，而 QTcpServer::waitForNewConnection(...)則作為我們是否執(zhí)行下一步的判斷標準，只不過這里用的是阻塞的方式；對于異步操作，也可以用非阻塞的方式解決，Qt的信號和槽機制就能很好的解決，如我們可以接收newConnection()信號判斷連接是否到來，而不必將程序阻塞在那。
