首先說明需求點：依次發(fā)起請求op1、op2、op3，要求op1成功后再發(fā)起op2，若失敗，則后續(xù)op2、op3不執(zhí)行，回調失敗結果；同理，若op1成功后，發(fā)起op2請求失敗，則op3不執(zhí)行，回調失敗結果。

最終參考代碼：Demo

先看一段網絡常見示例：

網上常見示例

從結果上看，滿足請求的順序執(zhí)行，但是實際使用后，情況變得不一樣了：

實際使用結果

從結果日志上看，op2并未等待op1請求結束后再發(fā)起，這就導致了無法根據op1的請求結果來判斷op2是否能夠發(fā)起，這就無法實現文章開始提到的效果。

修改方案：使用信號量來控制線程的執(zhí)行：

信號量實現方案

信號量請求結果

從請求結果看，這個已經滿足了使用需求，但是這并沒有結束，出現的主線程死鎖。

主線程死鎖

從結果可以看到，因為requestAction的回調是在主線程中執(zhí)行的，而此時主線程又在等待回調后的信號量以繼續(xù)執(zhí)行，從而形成了死鎖，更有甚者，如果UI上存在動畫或者loading的，此時也會卡死。

那么這種情況下改如何處理？

解決方法：

避免將dispatch_semaphore_wait() 放置于主線程中，而是放置到對應的子線程中進行，最終修改后的代碼：

Final

總結：原本不是復雜的場景，但是因為加入了線程的操作而容易出現錯誤，這個方案只是在遇到這個小問題的記錄，如果您有更好的辦法能夠實現這個場景，歡迎您留言！