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