前言
游戏框架是支撑具体游戏逻辑的底层建筑，需要提供游戏工程大部分的基础需求的支持。
无论框架是小至只有一两个类模块，还是大至十几个模块，只要是为通用功能而起作用的都能成为项目的框架。
框架不是从开始指定了就不变动的，而是随着项目的发展而有所改变。但是并不意味着它是一个可以随便改动的地方。
当框架已经满足了功能，除非是功能有大改，具体的问题，详细的优化等情况，通常就是趋向于稳定。
框架稳定后，更多是基于框架进行上层建筑的开发，和辅助工具的开发。
组成
无论是什么类型的游戏，都有一些功能是共同需要的。这些需求组成了框架的基础模块架构。
一级模块
无论什么项目都必然需要的功能
- 版本管理
- 网络通讯
- 资源加载
- 输入管理（触摸，键盘，鼠标，手柄等外部设施）
- UI管理
- 音效管理
- 场景管理
二级模块
一级模块中，一些重要的技术核心点
- 脚本语言（要根据项目的使用而定）
- 对象池/资源池（面向一切资源）
- 协程管理（根据项目不同，使用的类型和程度也有所不同）
- 计时器
- 事件分发
- GM
接触
框架的组成通常是由非常多的脚本组成，那么刚接手一个全新的框架时应该注意什么呢？
可以先从自己的职位入手，大部分情况下必然会接触的模块包括UI，计时器，事件。这几个模块可以作为第一个入手点。
先了解如何调用相关的API是最重要的。如果能够直接看到源码的话，就能对框架的细节了解地更为深入。
但接触一个陌生的环境，最好先将工作所需的模块相关的公用API大致了解一下。目的是能快速开发。
如其看内部错综复杂的模块代码，还不如在实践中理解模块设计的思路和原理。
在使用中，思考路径可以是：
- “为了实现XXX，应该调用哪个API”
- “除了这个API，还有别的api可以实现相同的功能吗”
- “这几个API有什么区别，各自的侧重点是为了实现什么”
这样一路思考下来，应该能对整个模块的使用和理解有一个比较快的提升。
UI
在制作UI时，几乎能贯穿整个框架的核心模块。而制作UI时，肯定首要是接触UI模块。所以UI模块应该接触框架时首要要了解的模块。
核心关注点在于：
- UI模块提供的API
- UI对象对应的数据结构
API
打开关闭是首要的，这个是很容易看到的。而其余关注点应该在于UI管理器还提供了什么接口。
相关的接口的意义实际上是框架设计者希望使用者是按照提供的功能的思路去实现的，也会体现出该框架的UI结构。
看API是一个记忆活，重点在于记忆API提供实现的功能。
单看API可能会觉得很无趣，通篇都只是参数和返回值。但是在开发时，若不知道框架提供了什么，就极容易重复造轮子，也可能用偏了的版本去实现功能。
常见的辅助需求：
- 打开界面需要传递数值，对应是否能开启指定界面（界面打开需要等级判断，需要指定状态）
- 需要传递数据给指定UI对象（Tip）
- 关闭非当前的所有对象 （跳转场景非加载条界面全部关闭）
结构
UI结构是指面对一个Prefab对象是用什么样的数据结构去与之对应的。了解到UI结构后，就能比较清晰地明白要将逻辑和数据分别写在什么地方。
常见的结构：
- 一个perfab对应一个脚本
- 一个perfab对应MVC结构
单个脚本是非常简单就能实现的，但若是大型项目，程序员会变动，需要其他人来维护的话，这就不推荐使用了。
因为单个脚本意味着将一切实现都混合在其中，代码必然会变得混乱。即便能梳理结构，一个较为复杂的UI，起码上千的代码交给他人去快速快发也是一件痛苦的事情。
所以使用解耦的接口，将功能定位都显示地清晰明了，对于后期维护有非常大的好处。
工具
为了更有效率的开发，辅助工具必不可少。对应常见的需求，有些工具几乎是所有项目都会存在的。
- 导表工具（根据表原文件生成指定的可读数据文件）
- 图集导出（无论NGUI还是UGUI都有图集概念，对应不同平台使用不同实现）
- 脚本生成（生成UI脚本文件）
而开发工具和日常游戏开发有所区别。工具需要开发者思考，使用者的目的和想要解决的问题。工具也是随着项目的发展而一路需要维护和更新的。
在工作上重点是放在功能的实现。例如大量操作IO的功能，要是不考虑性能就很容易卡，但只是实现功能也是可以的。因为编辑器并不需要像给玩家使用那么严谨。
但是，这也考验这一个程序员的责任心和水平。在他人要求不高的情况下，自身的要求将到达何处。在已实现功能的情况下，能将细节做到什么程度。