游戏UI框架设计(一)
---架构设计理论篇
前几天(2017年2月)看到一篇文章，国内王健林、马云等大咖们看好的未来十大最有“钱途”产业中，排名第一的就是“泛娱乐”。 所以我们发现最近几年无论是BAT企业还是万达等，都纷纷投资游戏、电影、动漫等泛娱乐产业。
随着人们物质生活的不断提高，游戏(包含端游/手游/VR/AR等游戏形式)产业只会越来越繁荣。但是问题来了，我们一线的游戏研发人员面对越来越复杂与规模庞大的游戏开发需求（策划文稿），越来越多的开发人员就更加重视与强调优良开发框架的使用，以期进一步增强游戏开发效率与代码质量！
本篇就基于Unity游戏引擎UGUI为基础，对UI界面游戏架构做一些有益探索与研究。首先我们来研究一下大型游戏项目中，没有UI框架容易导致与出现的问题：
问题1；
以ARPG为例，多个场景会反复出现相同的“UI窗体”，造成多个场景中反复加载相同的UI窗体。
解决思路：
“UI框架” 需要缓存项目（例游戏项目）中常用的“UI窗体"。
问题2：
开发商业复杂项目时，各个UI(UI脚本)之间传值，容易出现“紧耦合”的情况，容易导致项目的“可复用性”降低。
解决思路：
各个UI的生成、销毁、切换，都是通过框架(Manger)实现，各个UI之间不直接联系（传值），开发类似“消息传递中心”的机制来负责所有“UI窗体”或者UI脚本之间的传值。
问题3：
卡牌、RPG等游戏类型项目，很多情况下会出现多个“弹出窗体” 叠加的现象，开发人员需要“手工”维护窗体中间的层级关系。
解决方案：
设计UI框架系统，使用“栈”的数据结构，保存与控制当前所有需要显示的“UI窗体”的层级关系。
问题4：
商业项目中多个“UI窗体” 叠加出现时，保持“UI窗体”的“模态显示”非常重要（即： 弹出子窗口时，不允许玩家操作父窗体），否则容易出现各种误操作。
解决方案：
设计的框架本身，需要对当前显示的窗体做“遮挡处理”，即：不允许用户绕过当前“UI窗体”直接操作底层窗体，或者误操作点击项目中的3D游戏对象等。
当然还有很多其他的问题，诸如：语言的国际化、“窗体预设”自动加载的管理等。但是设计UI框架一个总的核心原则是：尽量让框架本身完成与具体业务无关的事务性工作，让开发人员只需要专注游戏业务逻辑的开发本身即可。（这个原则同样适用于其他框架的设计中）
为了解决以上商业开发遇到的各种问题，因此笔者设计如下UI窗体架构的“功能设计图”：
相应的类图设计如下：
为了更好的描述整个框架系统，笔者对整个框架分如下六个部分作详细描述：
- 最简版本设计
- 窗体的层级管理
- 模态窗体管理
- 配置管理与应用
- 消息传递中心
- 资源国际化技术
先写到这里，下篇来讲解“游戏UI框架设计(二)：“最简版本”设计篇