其中的 EventSystem（消息系统）和 ResSystem（资源系统）是两大亮点。EventSystem 的 EventId 是用泛型进行注册的。把一个泛型转换为 int 。这个解决了之前笔者注册事件时需要把枚举强转成 ushort 的问题，这样的代码写起来很不愉快，于是笔者把原来 MgrBehaviour 和 QMonoBehaviour 里关于消息注册和转发的代码杀掉，直接换成了 EventSystem 就 OK 了，QMonoBehaviour 和 MgrBehaviour 里的代码变得非常精简。而 ResSystem 使用非常简单和强大。ResSystem 是在 AssetBundleManager 的功能基础之上有抽象出来了 ResLoader。这样做有什么好处呢？
首先 AssetBundleManager 在哪里加载了什么资源和卸载了资源需要使用人脑进行记忆，项目体量很大时很容易由于忘记卸载资源而造成内存泄露。而 ResLoader 是一个对象，可以每个界面都申请一个 ResLoader 对象。所有在这个界面加载过的资源的信息都会记录到 ResLoader 里，而卸载很简单，只要在 OnDestroy 里直接进行 ResLoader 的卸载就好了，非常方便。但是这时候笔者已经用惯了 AssetBundleManager 的打包方式，所以只收录了 ResSystem 中除打包以外的代码。这里简单提一下，ResLoader 是用对象池实现对象的申请和回收的。而 ResSystem 里的资源积累则是使用引用计数器决定资源的释放的。在这里 QFramework 收录了 EventSystem、ResSystem、引用计数器、对象池，可以说收获颇丰。
提拔带人做完第一个项目之后，被 Leader 提拔，开始带人带团队。在框架和架构进行探索的时间少了很多。QFramework 在这之后边也加了一些库，比如 UniRx，ActionKit 等等。最终就是现在的 ActionKit、UI Kit、Res Kit 为核心的 QFramework 了。ActionKit 专注异步逻辑和状态机，可以很好地完成 GamePlay 需求和异步需求。而 UI Kit 是 UI 的解决方案，里边还是包含着之前的基于模块的消息框架。 Res Kit 则是解决资源管理方案。这里不多说 Action Kit。在这里笔者的经历分享完了。
总结
架构是“约定、规则、共识”
框架具有约束性和支撑性
好的架构直接就等于你要有一套好的规则，好的准则
Unity 好的规则
使用 C# 而不用 JavaScript
命名的时候要起一个比较有含义的名字
起文件夹的名字时尽量和 GameObject 对应起来
MVC 文件结构：先按照业务功能划分，再按照 MVC 来划分
代码是资产
做完每一个项目都积累一些东西
QFramework
* 工具集
* FSM
* Singleton&MonoSingleton
* QEventSystem
* MathUtils
* 笔者知识积累工具
* 业务支撑工具集（支撑性)
* UI Kit
* UIManager
* 代码生成
* MgrBehaviour、MonoBehaivour(约束性)
* Res Kit
* AudioManager
* Action Kit
* 建议
1. 为每个 UI 界面都建立一个测试场景。
2. 为每个 UI 界面都提供一个 Init 接口。
3. UI 界面的 Init 接口传数据，而不是在 UI 里面去访问某个 Manager Or Instance。
在项目准备的架构活动
需求/业务整理、收集、分析
编码规范、项目结构约定、资源命名规范、程序结构约定、模块/MVC 划分、成员分工
插件购买、造轮子、框架选型
这里可以得出框架与架构关系的结论，框架可以解决一部分架构问题，使用框架 本身就是一种“约定、规则、共识”。
直到文章的结尾，QFramework 还是没有收集到关于框架的约束性相关的内容。唯一能扯上点关系的就是基于模块的消息框架这块了。其实像 StrangeIOC、uFrame、PureMVC 等框架可以更容易去讲解约束性相关的内容。Any way 这次就讲到这里吧，我们以后见。
推荐资料《UNITE －Unity项目架构设计与开发管理》
《架构漫谈》
《Unity3D手游开发实践》
《10年感触：架构是什么？——消灭架构！》
《凉鞋的笔记》