探索iOS开发中的消息传递机制.docVIP

探索iOS开发中的消息传递机制 每个应用程序或多或少，都由?些松耦合的对彖构成，这些对彖彼此z间要想很好的完 成任务，就需要进行消息传递。本文将介绍所有町用的消息传递机制，并通过示例来介绍 这些机制在苹果的Framework中如何使用，同吋，还介绍了一些最佳实践建议，告诉你什么 时机该选择使用什么机制。 虽然这一期的主题是关于Foundation Framework的，不过本文中还介绍了一些超出 Foundation Framework (KVO和Notification)范围的一些消息传递机制，另外还介绍了 delegation, block fl target- action。 大多数情况下，消息传递该使川什么机制，是很明确的了，当然了，在某些情况下该使 用什么机制并没有明确的答案，需要你亲自去尝试一下。 本文中,会经常提及接收者［recipient］和发送者［sender］ o在消息传递 机制中 具体是什么意思，我们可以通过一个示例來解释一个table view是发送者，而它的 del egate 就是接收者。Core Data managed object context 是 noti fication 的发送者，而 获取这些notification的主体则是接收者。一个滑块(si ider)是action消息的发送者， 而在代码里血対应着实现这个action的responder就是接收者。対象中的某个属性支持KVO, 那么谁修改这个值，谁就是发送者，对应的观察者(observer)则是接收者。 可用的机制 首先我们来看看每种机制的具体特点。在下一节屮，我会结合一个流程图来介绍如何在 具体情况下，选择正确的消息传递机制。最示，将介绍一些来苹果Framework中的示例， 并会解释在某种确定情况下为什么要选择固定的机制。 KVO KVO提供了这样一种机制当对彖中的某个属性值发生了改变，对以对这些值的观察者 做岀通知。KVO的实现包含在Foundation里而，基于Foundation构建的许多Framework 对KVO部有所依赖。要想了解更多关于如何使用KVO,可以阅读木期由Daniel写的的KVO 和KVC文章。 如果对某个对象屮值的改变情况感兴趣，那么可以使用KVO消息传递机制。这里有两个 要求，首先，接收若（会接收到值发生改变的消息）必须知道发送者（值将发生改变的那个对 彖）。另外，接收者同样还需耍知道发送者的生命周期，因为在销毁发送者对彖Z前，帝耍 取消观察者的注册。如果这两个要求都满足了，消息传递过程屮可以是1对多（多个观察者 可以注册某个对彖中的值）。 如果计划在Core Data对象上使用KVO,需要知道这跟一般的KVO使用方法有点不同。 那就是必须结合Core Data的故障机制（faulting mechanism），一旦core data出现了故障， 它将会触发其属性对应的观察者（即使这些属性值没有发生改变）o Notification 在不相关的两部分代码屮要想进行消息传递，通知（notifacation）是非常好的一种机制, 它可以对消息进行广播。特别是想要传递丰富的信息，并且不一定指望有谁对此消息关心。 通知可以用来发送任意的消息，其至包含一个userinfo字典，或者是NSNotifacation 的一个了类。通知的独特之处就在于发送者和接收者双方并不需要相互知道。这样就可以 在非常松耦合的模块间进行消息的传递。记住，这种消息传递机制是单向的，作为接收者是 不可以回复消息的。 delegation 在苹果的Framework屮，delegation模式被广泛的貝用着。delegation允许我们定制 某个对彖的行为，并且可以收到某些确定的事件。为了使用delegation模式，消息的发送 者需要知道消息的接收者（delegate）,反过来就不用了。这里的发送者和接收者是比较松耦 合的，因为发送者只知道它的delegate是遵循某个特定的协议。 delegate协议可以定义任意的方法，因此你可以准确的定义出你所需要的类型。你可 以用函数参数的形式来处理消息内容，delegate还可以通过返冋值的形式给发送者做出冋 应。如果只需要在相对接近的两个模块之间进行消息传递，那么Delegation是一种非常灵 活和直接方式。 不过，过渡使用delegation也有一定的风险，如果两个对象的耦合程度比较紧密，相 互Z间不能独立存在，那么此时就没有必耍使用delegate协议了，针对这种情况，对彖Z 间可以知道相互间的类型，进而肓接进行消息传递。例如UICollectionViewLayout和 NSURLSessionConfi gurationo block Block相对来说,是一种比较新的技术,它