最開始使用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()信號判斷連接是否到來，而不必將程序阻塞在那。
