优雅的红点系统：MV数据视图分离与全局集中管理

在游戏UI开发中红点系统虽然逻辑简单但随着功能模块的膨胀极易产生“面条代码”。为了解决耦合与维护难题我们采用MVModel-View数据视图分离结合全局单例管理的架构方案。本方案不依赖特定引擎核心在于理清数据流向与职责边界。核心架构脑图在设计之初我们需要明确系统的层级关系。整个红点系统可以拆解为以下模块1. 类结构设计 (UML Class Diagram)为了更直观地展示各模块间的依赖关系我们使用 UML 类图来描述。RedDotManager系统的核心控制者持有所有数据。RedDotModel纯粹的数据载体负责通知。RedDotItemUI 表现层依赖 Model 进行更新。2. 模块详细设计2.1 红点全局集中管理 (Manager)Manager 是数据的唯一真理来源Single Source of Truth。单例模式确保全局只有一个数据中心避免状态冲突。数据字典使用Key-Value结构存储Key 为红点类型枚举Value 为对应的 Model 实例。惰性获取 (Lazy Get)调用GetRedDotModel时先检查字典。若不存在则new一个新的 Model 加入字典并返回。优势无需在项目启动时手动注册所有红点按需创建节省内存。状态设置与广播提供SetRedDotState方法。修改 Model 中的布尔值后立即调用 Model 的NotifyUpdate方法触发事件。2.2 数据模型 (Model)Model 层完全独立于 UI只负责数据的存储和变更通知。红点类型枚举标识该数据属于哪个功能模块。显示状态 (bool)核心数据决定红点是Active还是Inactive。事件通知机制提供一个公开的事件接口如 Action, Delegate, Signal 等。当数据发生变化时遍历并执行所有订阅者的回调。2.3 红点 Item 预制体 (View)View 层是挂载在具体 UI 节点上的组件负责“看”和“做”。配置化提供一个公开字段允许在编辑器/配置表中手动选择该 UI 对应的红点类型枚举。初始化 (Init)在生命周期开始时如Awake或OnEnable根据配置的枚举向 Manager 请求对应的 Model。绑定事件将自身的刷新方法注册到 Model 的事件通知上。视图更新逻辑当收到 Model 的广播时读取 Model 的bool值。直接控制 UI 节点GameObject/Image的SetActive或Visible属性。资源释放在销毁时OnDestroy或OnDisable务必取消事件订阅防止内存泄漏。3. 数据流向总结为了便于理解我们可以用简单的流程图概括一次红点触发的全过程业务触发玩家获得道具 - 调用Manager.SetRedDotState(Bag, true)。数据更新Manager 找到Bag对应的 Model - 修改isActive true。事件广播Model 执行NotifyUpdate()- 触发所有绑定的回调。视图响应所有挂载了Bag类型红点的 UI 组件收到回调 - 执行SetActive(true)-红点亮起。4. 方案优势彻底解耦UI 预制体不需要知道业务逻辑为什么亮业务逻辑也不需要知道有哪些 UI哪里亮。高复用性红点 Item 预制体可以无限复用只需在配置中修改枚举即可适配不同功能。易于维护新增功能模块只需添加枚举无需修改现有架构代码。这种基于 MV 模式的架构设计能够有效支撑中大型项目的 UI 开发需求。