序
1、一个Unity框架需要满足的条件：
（1）对于程序、策划、美术可以一起流畅的工作；
（2）代码维护便捷、维护成本低；
（3）降低开发的难度；
（4）有较好的游戏更新机制与版本管理；
（5）打包发布方便；
（6）打空包；
（7）制作工具：路径编辑工具 + 地图编辑器 + Excel表格解析 …
…
2、Unity开发框架的一些基本原则：
原则1：程序做程序，美术做美术，策划做数据；
—>程序逻辑与美术视图（地图、角色、UI、特效…）分开；
即：程序—>拼逻辑，美术—>做资源
—>程序逻辑与策划数据（Excel表格、行为树、状态机…）分开；
原则2：方便代码维护；
Q：Unity哪些编写习惯是不好维护的？
A：代码挂到节点（资源）上，这样在寻找代码在哪调用时，就需要依次将视图翻开，去寻找这个节点有没有挂脚本。
抛弃在视图上直接手动挂脚本，只有文本可搜索的代码，才是好维护的。
原则3：要求游戏场景不要放任何逻辑相关的内容节点，也就是说要让场景是空的。场景只是一个运行时的载体和容器；
这样更新资源会更方便，代码维护会更方便。
原则4：代码加载资源；
尽量不用Resources.load。
Q：代码加载资源，为什么不使用Resources.load？
A：Resources里的资源，不管用了还是没用，都要被打到包里去，这样会导致打空包不方便。其次，Resources资源加载，不方便做资源更新（热更新）。
使用纯Assetsbundle来做资源更新 + 资源加载 + 资源管理；
资源加载流程：
step1：加载ab包到内存；
step2：从ab包里面加载资源给游戏使用；
step3：做好资源管理，不用的资源及时释放掉；
优点：
（1）方便打空包（空场景，没有Resources）
（2）方便更新，Assetsbundle机制，天然就可以更新资源
（3）ab包会压缩资源，如果把资源放到安装包里面，包体会小
只要在StreamingAssets/ 文件夹下，就可以加载到这个ab包。
缺点：
（1）不想Resources.load非常直接的加载到资源，需要先打ab包，然后再加载ab包，再从ab包读取资源
所以，在开发的时候，一般使用两种模式，第一种是发布模式，就从ab包中加载资源；第二种是调试模式，使用Editor编辑器模式下使用AssetsDatabase加载资源。
这两种模式都使用同一个接口，GetAssets(路径)：{调试模式->AssetsDatabase，发布模式->ab包}
资源管理
常用的项目文件夹结构：
在导入资源包后根据现有的文件夹结构，自行调整资源路径。
单例模式
一般常用两种单例模式，一种是普通的单例，另一种是继承unity的Monobehaviour的单例。
普通单例：
Unity单例：
主体流程
因为要保证场景中尽量不放置任何资源，所以在主场景中创建GameLanch对象并挂载名称相同的脚本，用来做游戏启动脚本。将此脚本继承Unity单例作为唯一的启动脚本。
再编写一个名为Game的脚本，也继承Unity单例。
之后在游戏启动脚本中引入游戏脚本。
加载资源（发布模式和调试模式）
然后初始化框架
这样在项目运行时，就可以发现游戏启动的对象有相应的实例。
UI框架
1、UI界面视图的制作 （美术 + 初级程序员 + 高级程序员）
（1）Q：哪些东西是能做成UI视图？
A：把完成特定功能的UI，做成一个视图。主游戏操作UI，例如：游戏商城、游戏背包、排行榜、结算视图…
反例：按钮做成一个视图（X）—>Button组件
（2）各个视图之间一定要独立，不要交叉引用；
单独适配，每个UI视图都要单独适配。
2、UI逻辑控制
一个UI视图，只能对应一个UI控制的代码；
一个UI视图，有且只有一个UI Ctrl 来作为他的代码控制
规定：视图名字 + Ctrl（Controller） 作为脚本名称
可以编写一个编辑功能 —>根据UI视图，自动生成代码；
（1）方便的接收输入；
千万不要在UI代码里，来写游戏逻辑，与UI无关的游戏逻辑；
通过派送事件来触发游戏逻辑；
（2）方便的显示结果；