目前情况

从第一次打算开发框架到现在已经快一年半了，最开始的时候确实对很多开发时的概念不是很理解，最后只是对着上一家的框架鹦鹉学舌的代码复制，实际进度几乎为零。后来又经历了几个项目的开发，对了架构和抽象有了新的理解，才逐渐感觉找到了方向。

框架出发点

开发框架最核心的目标就是对业务层面进行抽象和封装，提高开发效率。

明确问题

• UI组件绑定繁琐
• 代码结构混乱
• 资源加载影响运行效率
• 模块之间耦合
• 游戏逻辑中大量依赖状态管理
• 处理游戏中基本的生命周期

设计特性

• 生成模板代码 -> UI组件绑定繁琐问题
• 逻辑层面单向持有视图 -> 代码结构混乱
  • 视图层本身不参与逻辑，逻辑层不关心视图层具体实现。
• 抽象数据管理（model） -> 代码结构混乱
• 抽象逻辑管理（system） -> 代码结构混乱
• 实现ResourceManager -> 资源加载影响运行效率
• 实现EventManager -> 模块之间耦合
  • 强类型匹配的事件广播机制 -> 事件id与事件参数与回调函数严格匹配
• 提供灵活的状态管理 -> 游戏逻辑中大量依赖状态管理
  • 设计行为节点，可在状态机与行为树中同时使用

启动流程

1. 初始化框架
   1. 各类Manager
2. 开始游戏
   1. 打开起始页
3. 进入游戏
   1. 初始化存档
   2. 初始化system
   3. 初始化model

技术债

技术债不可避免，需要有意识的区分哪些方案是临时方案，打好标记，后续进行优化，使得代码能往好的方面迭代。

需要对技术债进行分级，

1. 第一类是影响到后续拓展的内容，比如可能导致某些功能实现困难的技术债，保证框架的灵活是首要目标。
2. 第二类是影响运行效率的技术债，比如某些模块的初始化，某些模块的调用，某些模块的加载，这些都需要进行优化。
3. 第三类是影响代码复用的技术债，避免项目中出现太多的相似代码
4. 第四类是影响代码可读性的技术债，比如命名不规范，代码结构混乱，代码重复，代码冗余，代码风格不一致，代码注释缺失等

需求出发

1. 项目与项目间的代码复用并不是第一优先级，当前项目的实现才是第一优先级。目前的水平没办法兼顾可以在多个项目间复用的开发框架，并且不同的游戏类型也不大可能共用一个框架。
2. 保证抽象满足当前需求即可，只有当抽象被破坏并且无法保留时才应该考虑重构，避免过度设计。