用 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 块, 那么可以增加一个参数, 使得调用者可通过此参数来决定应该把 块 安排在哪个队列上执行.
