10.Block、Delegate、Notification、KVO浅解

PS：他们的定义我就不多赘述了，我就写一些我认为的干货吧

选择

• 简单的 值 传递
  像这种 一对一 简单的值传递，例如点 button 将子控件的信息传递给父控件的时候，这个时候用个 Block 就能很完美的解决了，就不要考虑其他的了。没必要
• 作为函数等方法的回调使用
  像上面说的，一对一的时候优先考虑 Block ，一对多的时候 Delegate 优势比较明显。应用最为明显的，网络请求的回调一般都使用 Block
• 对象间的通信
  作为对象间的通信使者，分情况把。如果是有关联的对象之间，可看场景选择是否使用 Block或者 Delegate，如果是毫无联系的对象之间，就不要使用前面两兄弟，将势必增加代码的耦合度，这个时候用 Notification 是个不错的选择
• 作为UI响应事件的传递者
  根据 Cocoa Touch框架中的文件，我们也能得出结论，用 Delegate
• 监视某个属性
  当你希望监视一个属性的时候，选用KVO，虽然notification和delegate有比较相似的用处，但当处理属性层的消息的事件时候，使用KVO，而其他的尽量使用delegate，除非代码需要处理的东西确实很简单，那么用通知很方便

优缺点

• Block
    >>> 优
     * block语法比较简洁，实现回调也需要显示调用方法，代码比较紧凑，增强代码的可读性和可维护性
     * block也就是代码块，在很多调用中使用block都会使得代码的逻辑更加清晰
     * block可以不进行命名，或者存储在临时变量之中；所以在只需要调用一次，或者在同一函数内多次调用的地方，使用block会比较方便
     * 当然，block也可以存储在属性之中，进行多次调用；这么使用的时候，一定要注意判断block不为nil
     * 配合GCD优秀的解决多线程问题
    >>> 缺
     * block中得代码将自动进行一次retain操作，容易造成内存泄露
     * block内默认引用为强引用，容易造成循环引用

• Delegate
    >>> 优
     * 非常严格的语法，减少维护成本，较强的代码可读性，所有能响应的事件必须在协议中有清晰的定义
     * 编译器能帮你检查是否实现了所有应该实现的方法，不容易遗忘和出错，如果delegate中的一个方法没有实现那么就会出现编译警告/错误
     * 使用delegate的时候，逻辑很清楚，控制流程可跟踪和识别
     * 在一个controller中可以定义多个协议，每个协议有不同的delegate，满足自定义开发需求，可选必选有较大的灵活性
     * 没有第三方要求保持/监视通信过程，一旦出现问题，那我们可以比较方便的定位错误代码
     * 能够接受调用的协议方法的返回值，意味着delegate能够提供反馈信息给controller
     * 减少代码的耦合性，使事件监听和事件处理相分离
    >>> 缺
     * 需要定义很多代码：（协议定义、controller的delegate属性、在delegate本身中实现delegate方法定义，实现委托的代码过程比较繁琐）
     * 在释放代理对象时，需要小心的将delegate改为nil。一旦设定失败，那么调用释放对象的方法将会出现内存crash
     * 在一个controller中有多个delegate对象，并且delegate是遵守同一个协议，但还是很难告诉多个对象同一个事件，不过有可能，委托的易用性将大大降低
     * 当实现跨层传值监听的时候将加大代码的耦合性，并且程序的层次结构将变的混乱
     * 要注意防止强循环引用

• Notification
    >>> 优
     * 代码量少，实现比较简单
     * 一个对象发出的通知，多个对象能进行反应，一对多的方式实现很简单
     * 传值方便快捷，Context自身携带相应的内容
    >>> 缺
     * 编译期不会减产通知是否能被正确处理
     * 释放注册的对象时候，需要在通知中心取消注册，否则将出现不可预见的crash
     * 调试的时候，程序的工作以及控制流程难跟踪
     * controller和观察者需要提前知道通知名称、UserInfo dictionary keys。如果这些没有在工作区间定义，那么会出现不同步的情况
     * 当使用者向通知中心发送通知的时候，并不能获得任何反馈信息
     * 需要一个第三方的对象来做监听者与被监听者的中介，管理controller和观察者的联系

• KVO
    >>> 优
     * 能够提供一种简单的方法实现两个对象间的同步。例如：model和view之间同步
     * 能够对非我们创建的对象，即内部对象的状态改变作出响应，而且不需要改变内部对象（SDK对象）的实现
     * 能够提供观察的属性的最新值以及先前值
     * 用key paths来观察属性，因此也可以观察嵌套对象
     * 完成了对观察对象的抽象，因为不需要额外的代码来允许观察值能够被观察
    >>> 缺
     * 我们观察的属性必须使用strings来定义。因此在编译器不会出现警告以及检查
     * 对属性重构将导致我们的观察代码不再可用
     * 复杂的“IF”语句要求对象正在观察多个值。这是因为所有的观察代码通过一个方法来指向
     * 当释放观察者时不需要移除观察者

注意

• Block

当在Block中引用某个外部变量的时候，Block内部只会进行只读拷贝，这也就意味着，即便你在使用Block之前修改了那个外部变量的值，那么在你使用的Block里面它的值依旧是最开始的那个外部变量的值。如果想要同步外部变量的值，那么就需要在block内部引用变量时，在前面加上__block关键字。（使用__block，是将变量地址传给block，不使用则传递的是变量值给block）
block本身是像对象一样可以retain，和release。但是，block在创建的时候，它的内存是分配在栈(stack)上，而不是在堆(heap)上。他本身的作于域是属于创建时候的作用域，一旦在创建时候的作用域外面调用block将导致程序崩溃。（MRC和ARC 有区别）

• Delegate

在代理中调用方法的时候使用的是系统的子线程，因此，当使用Delegate进行UI操作的时候，必须调用GCD的主线程方法：
dispatch_async(dispatch_get_main_queue(), <^(void)block>)，在block中写进行的UI操作代码。同时要防止强循环引用。

• Notification

在通知的使用过程中Crash的原因很多情况都是注册观察者以后没有及时的注销观察者，当然这个情况在非ARC时代比较常见，但是这并不是说在现在的ARC时代就不会出现这个问题。往往一旦出现问题就很难追查，所以还是要养成及时注销的习惯。由于通知的使用极其简单，往往能够看到很多开发人员在开发过程中滥用NSNoticationCenter的现象。导致到处都是乱七八糟的通知，代码的可维护性和可读性非常差，即便是使用了宏定义也不能完全避免这些问题。比如在Debug的时候，当存在多个Observe的时候，简直就是要人命的感觉，想死的心都有了。在这方面Block和Delegate比Notification强太多了

• KVO

潜在的问题有可能出现在dealloc中对KVO的注销上。KVO的一种缺陷(其实不能称为缺陷，应该称为特性)是，当对同一个keypath进行两次removeObserver时会导致程序crash，这种情况常常出现在父类有一个kvo，父类在dealloc中remove了一次，子类又remove了一次的情况下。不要以为这种情况很少出现！当你封装framework开源给别人用或者多人协作开发时是有可能出现的，而且这种crash很难发现。不知道你发现没，目前的代码中context字段都是nil，那能否利用该字段来标识出到底kvo是superClass注册的，还是self注册的？ 回答是可以的。我们可以分别在父类以及本类中定义各自的context字符串，比如在本类中定义context为@"ThisIsMyKVOContextNotSuper";然后在dealloc中remove observer时指定移除的自身添加的observer。这样iOS就能知道移除的是自己的kvo，而不是父类中的kvo，避免二次remove造成crash