ufofacker

观察者模式和发布订阅模式的设计思想是类似的，只是在应用场景上和实现策略上略有不同而已。 发布订阅模式可以认为是在观察者模式的基础上进行了一定的优化。通过增加消息代理管理器（大家常称其为：中间商，个人认为称其为代理商更合理些。因为，它的主要作用就是提供代理服务和消息处理加工的能力），优化了发布器和订阅器的耦合度，同时又对提供消息的发布器，及订阅器进行了隐藏。在发布订阅模式的实际使用的过程中，我们会发现对于订阅器而言，根本不知道是哪个发布器提供的消息服务。这为程序设计提供了更好的封装性，这也是其对比观察者模式的优势之一。 网上有个不错的的例子：定牛奶 观察者模式：人们到奶农那里预定牛奶，牛奶挤好了，奶农就会通知大家去取。 发布订阅模式：人们到奶站预定牛奶，人们不需要关心是哪个奶农提供的牛奶，奶农的奶挤好了也不需要关心买奶的人是谁。

为什么遇到性能瓶颈，真的有必要去解决吗？个人觉得可以从两个维度去思考： ①交互设计上：很多情况下，交互设计存在导致页面出现性能瓶颈的问题，在实际应用中，是否可以考虑优化现有交互，比如：列表，是否可以分页？地图撒点，是否可以通过点聚合实现？树型视图，是否可以在交互上懒加载，而不是一次性加载所有？这些类似的场景都不需要直接通过研究底层技术去实现优化，这种方式个人认为是应该优先考虑的。 ②技术上：如果已经要考虑这个层面的优化了，证明你已经向产品或者交互妥协，那就专业的研究下在既定场景下，导致性能问题的因素都有哪些？如：加载的资源中重复代码过多，使得文件太大、业务设计不合理导致请求过多、代码编写不规范，造成不必要的浏览器计算，及服务端计算，浪费运行资源、业务代码中关于组件实现上，内部涉及业务的算法上是否有优化的空间、对应用的技术栈理解的不够深入，在使用过程中不合理的运行了一些不必要的框架内部程序，从而导致整个业务单元运行效率降低，从而产生用户可以感知的性能问题。 简而言之：交互优化优先级高于技术性优化