不久前在游戏项目中设计编写了一套红点提示机制，在游戏中已运作了一段时间，此时得空可以回顾一下整个机制的设计。
在最初的技术讨论会中主要围绕两套方案，分别是以一个简单模块为基础 各业务基于此基础各自实现，以及以一个复杂 尽可能通用的模块来总管红点。
简单红点模块其实就是红点模块只负责与服务端的数据交互与保存，提供接口给各业务从中获取所需数据，各业务模块自行管理红点的生命周期。
此方案可以避免红点模块陷入复杂多变的业务逻辑，避免因业务界面的改动而需重新整理逻辑；同时缺点也是非常明显，各业务模块需要各自管理红点意味着需要多名开发人员去进行维护，每次界面改动都意味着代码的调整，也就增加了许多重复的工作量，浪费了人力资源。
通用型红点模块即红点模块不仅管理红点数据，还需控制与管理所有业务界面的所有红点的生命周期，将之统一收纳在一个尽可能通用 灵活 健壮的管理机制当中，同时把显示路径抽象并分离为配置文件，交由游戏策划去维护，避免界面改动所带来的代码调整。
优点当然就是开发与维护人员只需一名，只要一次成型便几乎无需维护，界面调整只需修改配置文件。
比较两个方案的优劣之后，最终自然选择了通用型机制，然后花了一些时间去实现。
经过应用几个月之后，对通用型红点机制有了更实际的体会，自然有了更深的思考。
这种机制确实极大地解放人力资源，业务开发人员完全无需理解与思考红点机制，只需在业务关键处下发数据，派发消息，红点模块即可根据数据进行刷新，把红点附加到对应界面元素上。然而对于维护人员实在痛苦，需要适应风格各异又多变的界面设计，一旦此业务界面由于设计原因无法直接获取元素时（例如动态元素路径），红点模块就需要根据此情况编写新函数来获取所需要的数据，以便进行判断与操作。当这种情况多次发生时，事情便变得繁琐起来。
目前已经增加的判断函数包括页签判断（一个item有多个可操作页签），选中判断（一个按钮可被多个item操作），动态路径判断，等等。暂时尚且可以满足绝大多数界面红点的需求，策划只需提供数据，后端下发数据，前端派发消息，即可完成红点流程。基本满足当初设计的初衷：一人维护，全系统通用。只是对这个人来说维护工作比较琐碎而已。
此通用机制适合界面风格比较一致，设计不会多样化，即使变化也不会很大的环境；对于风格多变 形式各异的设计来说，此机制做起来简直就是噩梦。
