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

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

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

图中可以直观看出信息流产品的UI整体布局，顶部是频道Tab，底部是专栏Tab，点击专栏Tab例如视频按钮，就会进入视频专栏，里面又会有很多新的频道。每个频道都会有很多卡片，每张卡片上面会有一个删除按钮。

我们来还原一张类图：

该类图隐去了大量细节内容，只展示了构造大致UI所需的基本元素。

接下来我们接到一个需求：

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

1. 界面卡顿很厉害;

2. 点击选项后无法关闭。

然而我将这个弹框放在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的时间花的值得吗？

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

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

作者：凡尘卍

链接：https://www.jianshu.com/p/e3b5dbbee782

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。