我为何要用委托模式（Delegate）来代替消息机制

首先，消息机制并无错，错在咱们使用它的场景。每一种技术都有他的优势和价值，可是不能滥用，就像继承同样。没有一种技术是放之四海而皆准的，除了几个设计原则必须遵照。

在讨论这个话题以前，先来描述一下我在项目中被广播消息坑过的痛苦经历。你们知道，新闻类信息流产品会有多个频道，每一个频道是一个ListView或RecycleView，一个ListView里面会有不少张卡片，每张卡片就对应一条新闻。为方便说明问题，借用典型信息流新闻类产品的屏幕截图来展现一下：

图中能够直观看出信息流产品的UI总体布局，顶部是频道Tab，底部是专栏Tab，点击专栏Tab例如视频按钮，就会进入视频专栏，里面又会有不少新的频道。每一个频道都会有不少卡片，每张卡片上面会有一个删除按钮。
咱们来还原一张类图：

该类图隐去了大量细节内容，只展现了构造大体UI所需的基本元素。
接下来咱们接到一个需求：

需求定义是当用户点击卡片上的删除按钮时，弹出一个用户反馈弹框。以前的现状是直接删除卡片，而后弹出一个Toast，Toast会在两秒后自动消失。这个弹框需求自己很简单，可是，当我把这个弹框作出来，集成到项目中后，运行，发现两个问题：

• 界面卡顿很厉害;
• 点击选项后没法关闭。

然而我将这个弹框放在Demo中，或者项目中其它地方，都没有问题。项目中我是这样作的，以前是在一个删除消息中调用doDislike方法，直接将卡片从列表中删除。因而我在调用doDislike的地方，替换为这个新的用户反馈弹框，当用户点击其中一项后，关闭弹框，再执行doDislike方法。感受这个逻辑并无错啊，可是事实是程序就是出现了严重卡顿。因而在弹框入口添加Log输出，天啊，一瞬间执行了二十次弹框。这不科学，因而查看代码，看看删除流程执行过程，原来，每个ListViewController绑定了一个事件处理对象，专门用于处理来自卡片的事件，这个对象注册了一个消息，DISLIKE_CLICK_MESSAGE，并且这个消息仍是使用的项目内广播消息。当用户点击Delete按钮的时候，卡片类将使用广播消息接口发送DISLIKE_CLICK_MESSAGE消息，当ListViewController的事件处理对象收到这个消息时，执行doDislike方法。这样使用消息的好处是回避了卡片组件跟ListView之间的空间距离，参考前面的类图，真实状况比这个图要复杂得多。

可是这带来了一个问题，前面说过，项目中频道是不少的，一个首页专栏就有20几个频道，还有视频专栏以及其它专栏等。因为考虑到用户体验与加载性能，每每须要提早准备缓存，也就是说后台已经建立了多个频道对象。这些对象都将收到DISLIKE_CLICK_MESSAGE消息，他们都会执行弹框，所以就出现了刚才描述的状况，一瞬间二十几个弹框，固然就会异常卡顿了，并且行为也不正确。为何以前的删除就没有问题呢，由于弹20个Toast叠加在一块儿，文案都是同样的，并且都是在两秒后消失，那么也就无法引发注意了。

到这里，也许你会说，列表中查询一下数据不就好了，若是不存在待删除的卡片数据，就不执行弹框。没错，我就是这样尝试解决问题的，前面只是前奏，如今才是入坑经历的开始。首先固然就是在列表中查找，找不到则不弹框，不作任何处理，至关于让消息发动机空转20转。觉得这样就大功告成了，实测发现，依然会出现连续两次弹框。继续排查缘由，由于首页跟频道列表页是共用了一份数据，也就是说有两个ListViewController里面是相同的数据，所以出现问题，并且即使不考虑首页数据重复问题，谁又能保证服务器不在两个频道下发同一张卡片呢，咱们客户端程序总不能靠天吃饭吧，总的想办法解决问题才行。我注意到ListViewController有一个selected状态，一个专栏应该只有一个频道处于选中状态，那么咱们是否能够用这个状态来判断，当前处于选中状态的ListView才响应删除消息，理论上能够，可是也要考虑一个状况，除了首页新闻专栏，还有视频专栏和其它专栏，每一个专栏均可能有一个频道处于selected状态。要完全解决这个问题，还应该引入一个isActive状态，当专栏处于不可见，被其它专栏覆盖的时候，isActive设为false，最前端专栏isActive设为true，那么当收到消息的时候，检测selected和isActive状态，二者同时为true，才能处理DISLIKE消息。

当我试图采用上述方案解决问题的时候，问题来了，若是是全新设计一个系统，一开始就将这些状态规划好，天然是没有问题的，可是要在一个已经很庞大的系统上去新添加一种系统性状态规则，难度可想而知，成本很高不说，还很容易出现问题，一旦状态维护很差，又将是无休止的埋坑、踩坑、填坑的过程。

虽然想象起来很高大上，但我仍是及时踩住了刹车，简单的尝试一下后就终止了该方案。

新的方案：DISLIKE事件的处理再也不使用消息机制。将卡片组件、卡片、ListView、事件处理对象等，使用清晰的链条连接起来。由于这些对象是有关系链的，有明确的生命期管理关系（虽然有垃圾回收不用考虑什么时候销毁）。咱们彻底可使用委托模式（Delegate）在Owner中处理来自子孙产生的回调事件。咱们的系统中原本就有UIEventDelegate接口设计，跟消息机制的差异，主要是从ListView到卡片组件DeleteButton之间，必需要层层设置Delegate回调对象，事件发生时层层上报。Owner在建立子对象时调用obj.setEventHandler(this)，任何对象在产生事件时要么本身消化，要么只能将事件回调给Owner处理，并非经过消息一抛了之，惟一的缺点是构造对象时传递Delegate回调接口略显麻烦。不过这样一来，事件的传递是清晰的，谁产生事件，谁处理事件，流程是很清楚的，不会再有乱子发生，再不会有其它不相干对象收到事件的状况出现。

经过这种方案最后圆满解决问题，可是尝试各类方案解决这个问题的过程，我足足花了两天时间，发现问题、排查问题、尝试方案到解决问题，整个过程远比我这里描述的要复杂的多。要知道以前实现弹框这一步需求一共才花了3天，其中仍是由于作了一个通用的Popover组件。那么，试问这两天解Bug的时间花的值得吗？

总结：事件传递应该有明确清晰的链条，而不是随意乱飞，能不能正确处理全看缘分。

像内存报警、应用换肤、多语言切换这些很是通用，而又不存在各业务间关联的事件通知，使用广播消息是很是方便的，也是合理的。可是一旦在复杂的业务逻辑中滥用消息机制尤为是广播消息，其后果将是灾难性的。