用 handler 塊 降低代碼分散程度
為用戶界面編碼時, 一種常見的范式是 '異步執(zhí)行任務(wù)', 這種范式的好處在于: 處理用戶界面的顯示及觸摸操作所用的線程, 不會因為要執(zhí)行 I/O 或網(wǎng)絡(luò)通信這類耗時的任務(wù)而阻塞, 這個線程通常稱為主線程, 假設(shè)把執(zhí)行異步任務(wù)的方法做成同步的 ,那么在執(zhí)行任務(wù)時, 用戶界面就變得無法響應(yīng)用戶輸入了. 某些情況下, 如果應(yīng)用程序在一定時間內(nèi)無響應(yīng), 那么就會自動終止, iOS 系統(tǒng)上的應(yīng)用程序就是如此. '系統(tǒng)監(jiān)控器'在發(fā)現(xiàn)某個應(yīng)用程序的主線程已經(jīng)阻塞了一段時間之后, 就會令其終止.
異步方法在執(zhí)行完成任務(wù)后, 需要以某種手段通知相關(guān)代碼, 實現(xiàn)此功能有很多方法. 常用的技巧是設(shè)計一個委托協(xié)議. 令關(guān)注此時間的對象遵從該協(xié)議. 對象稱為 delegate 之后,就可以在相關(guān)時間發(fā)生時 (例如某個異步任務(wù)執(zhí)行完畢時) 得到通知了.
這種做法確實可行,而且沒有什么錯誤,然而如果改用 塊 改寫的話, 代碼會更清晰, 塊 可以令這種 API 變得更緊致, 同時也令開發(fā)者調(diào)用起來更加方便,
與使用委托模式的代碼相比. 用 塊 寫出的代碼顯然更為整潔, 異步任務(wù)執(zhí)行完畢之后所需運行的業(yè)務(wù)邏輯. 和啟動異步任務(wù)所用的代碼放在一起,而且,由于 塊 聲明在創(chuàng)建獲取器的范圍里面, 所以它可以訪問此范圍內(nèi)的全部變量,
這種寫法的缺點是: 由于全部邏輯都寫在一起. 所以會令 塊 變的比較長, 且比較復(fù)雜. 然而只用一個 塊 的寫法也有好用, 那就是更為靈活; 比方說,在傳入錯誤信息時,把成功情況和失敗情況放在同一個 塊 中,還有個優(yōu)點,調(diào)用 API 的代碼可能會在處理成功響應(yīng)的過程中發(fā)現(xiàn)錯誤, 比方說,返回的數(shù)據(jù)可能太短, 這種情況下需要和網(wǎng)絡(luò)獲取器所認(rèn)定的失敗情況按同一方式處理. 此時, 如果采用單一 塊 的寫法,那么就能把這種情況 和 獲取器所認(rèn)定的失敗情況統(tǒng)一處理了, 要是把成功情況和失敗情況交給兩個不同的處理程序來負責(zé), 那么就沒辦法共享同一份錯誤處理代碼了, 除非把這段代碼單獨放在一個方法里.而這又違背我們想把全部邏輯代碼都放在一處的初衷.
總體來說, 建議使用同一個 塊 來處理成功與失敗情況,
有時候需要在相關(guān)時間點執(zhí)行回調(diào)操作, 這種情況也可以使用 handler 塊, 比方說,調(diào)用網(wǎng)絡(luò)數(shù)據(jù)獲取器的代碼, 也許想在每次有下載進度時 都得到通知, 這可以通過委托模式實現(xiàn), 不過也可以使用 handler 塊, 把處理下載進度的 handler 定義成 塊 類型,并新增一個此類型的屬性.
typedef void (^EOCNetworkFetcherProgressHandler)(float progress);
@property (nonatomic, copy) EOCNetworkFetcherProgressHandler progressHandler;
這種寫法很好, 因為它還是能把所有業(yè)務(wù)邏輯都放在一起: 也就是把創(chuàng)建網(wǎng)絡(luò)數(shù)據(jù)獲取器和定義 progress 的代碼寫在一起.
基于 handler 來設(shè)計 API 還有個原因, 就是某些代碼必須運行在特定的線程上, 比方說, Cocoa 與 Cocoa Touch 中的 UI 操作必須在主線程上執(zhí)行, 這就相當(dāng)于 GCD 中的 '主隊列', 因此,最好能由調(diào)用 API 的人來決定 handler 應(yīng)該運行在哪個線程上. NSNotificationCenter 就屬于這種 API ,它提供了一個方法, 調(diào)用者可以經(jīng)由此方法來注冊想要接收的通知,等到相關(guān)事件發(fā)生時, 通知中心就會執(zhí)行注冊好的那個 塊,調(diào)用者可以指定某個 塊應(yīng)該安排在哪個執(zhí)行隊列里, 然而這不是必須的, 若是沒有指定隊列, 則按默認(rèn)方式執(zhí)行, 也就是說, 將由投遞通知的那個線程來執(zhí)行,
總結(jié):
在創(chuàng)建對象時, 可以使用內(nèi)聯(lián)的 handler 塊將相關(guān)業(yè)務(wù)邏輯一并聲明.
在有多個實例需要監(jiān)控時,如果采用委托模式,那么經(jīng)常需要根據(jù)傳入的對象來切換, 而若改用 handler 塊 來實現(xiàn),則可直接將 塊 與相關(guān)對象放在一起.
設(shè)計 API 時如果用到了 handler 塊, 那么可以增加一個參數(shù), 使得調(diào)用者可通過此參數(shù)來決定應(yīng)該把 塊 安排在哪個隊列上執(zhí)行.
