QEventSystem 提供了如下的 API:
QEventSystem.RegisterEvent(eventKey,onEventCallback); QEventSystem.UnRegisterEvent(eventKey,onEventCallback); QEventSystem.SendEvent(eventKey,params object[] args);很简单，就是注册，注销，和发送事件。
而 QEventSystem 本身就是一个消息注册列表，相当于上个例子中的 List<Person> 封装到了 QEventSystem。
所以如果将以上例子改成使用 QEventSystem，则代码会变成如下:
using System.Collections; using System.Collections.Generic; using UnityEngine; using QFramework; namespace CourseExample { class Person { public const int PersonEvent = 0; public string Name; public Person() { QEventSystem.RegisterEvent (PersonEvent, OnReceiveEvent); } void OnReceiveEvent(int eventKey,object[] args) { var receivedMsg = args [0] as string; Say (receivedMsg); } public void Say(string msg) { Log.E ("Person:{0} Say:{1}", Name, msg); } } class Me { public void SendMsgToContancts() { QEventSystem.SendEvent (Person.PersonEvent, "Hi"); } } public class ObserverPatternExample : MonoBehaviour { // Use this for initialization IEnumerator Start () { Me me = new Me (); new Person (){ Name = "张三" }; new Person (){ Name = "李四" }; new Person (){ Name = "王五 "}; yield return new WaitForSeconds (1.0f); me.SendMsgToContancts (); } } }QEventSystem 与观察者模式就介绍到这里。
中介者模式与事件机制这里不多说，主要比较下观察者模式和中介者模式就理解了。
观察者 (observer)模式通过 订阅 - 发布 (subscribe-publish) 模型，消除组件之间双向依赖
消息的 发布者 (subject) 不需要知道 观察者 (observer) 的存在
两者只需要约定消息的格式（如何订阅、如何发布），就可以通信
对应的是以上的不用 QEventSystem 的 Person/Me 的例子。
中介者 (mediator) 模式通过设置 消息中心 (message center)，避免组件之间直接依赖
所有的 协同者 (colleague) 只能通过 中介者 (mediator) 进行通信，
而相互之间不知道彼此的存在
当各个组件的消息出现循环时，消息中心可以消除组件之间的依赖混乱
对应的是以上的使用 QEventSystem 的 Person/Me 的例子。
所以 QEventSystem 与其说是观察者模式，不如说是中介者模式的实现。
以上关于设计模式的描述，仅仅是表达个人的理解，方便初学者更容易理解。
小结 (二)在这个小结简单了解了 观察者模式和中介者模式，以及 UI Kit 所支持的事件机制。
Manager Of Managers 简介UI Kit 内置了一个 Manager Of Managers 的支持。
主要提供两个功能:
模块化的脚本管理
模块化的消息系统
而模块化的脚本管理，对我们来说不是很陌生。其中 UIMgr 与 UIPanel 则是其一种实现。
UIMgr 为脚本管理器，而 UIPanel 则是脚本单元。
对应的可以推测出, CharacterManager 则有对应的 Character，Enemy/Weapon Manager 有对应的 Weapon 和 Manager 脚本。这是在一个业务逻辑上划分模块的一种方式。不难理解。
UI Kit 提供了两个基类:
QMonoBehaviour 和 QMgrBehaviour:
QMonoBehaviour 则是脚本的基类，比如 UIPanel 则是继承了 QMonoBehaivour。
QMgrBhavriour 则是管理类的基类，比如 UIMgr 则是继承了 QMgrBehaviour。
不难理解，而 UIMgr 里边维护了一个关于 UIPanel 的容器。很好地表明了 QMgrBehaviour 与 QMonoBehaviour 之间的关系。
从而想实现其他模块也变得容易，比如 CharacterManager 只要继承 QMgrBehaviour 而 Character 脚本则继承 QMonoBehaviour 就可以实现角色模块了。
以上则是模块化的脚本管理的介绍。
另一个利器则是模块化的消息系统。
大家可能发下 UIGamePanel 与 UIGamePausePanel 实现的事件机制 与 后来的 QEventSystem 有一点区别。
在 UIGamePanelEvent 中，事件的定义如下:
public enum UIGamePanelEvent { Start = QMgrID.UI, GameResume, End }为什么 Start 要等于 QMgrID.UI 呢?