补充说明
1、前言
该文本简单介绍Demo开发过程中一些系统框架的设计思路和想法。
本人经验有限，框架会存在很多问题，有待后续学习将框架优化并完善。
2、热更流程设计思路
为了加快Demo进程，本次资源加载都使用的是Addressable官方插件。代码的热更使用HybridCLR来实现。
基于Addressable实现的资源热更流程，图示：
大体流程：
- ** 包准备阶段：** 打包->远端仓库->生成md5列表（用于验证完整性）。
- ** Demo启动热更：** 本地启动->是否可连接到远端->下载远端md5列表->与本地md5列表比较->获取远端需要下载的bundle列表->下载所需的bundle包 ->继续游戏流程
最初设计想法本地不保存md5列表，因为考虑到一些特殊情况如：本地md5列表和本地bundle包不匹配时无法保证bundle包的一致性。
但是如果随着项目资源量的增加，热更检查遍历每个bundle包并检查md5是非常缓慢的，于是决定本地缓存md5列表。对于遍历本地bundle包进行检查的方案，可以作为热更后游戏异常的修复手段。
3、资源预加载的想法
设计原因：
- 游戏中可能存在需要大量创建一个资源实例的情况，例如：角色模板
- Addressable主要支持的都是异步加载和实例化，但一些情况需要一帧内批量生成多个实例化对象，单靠Addressable就不可靠了。
思路：
项目内所有资源加载全都依靠Addressable进行。
- 需要预加载资源模块去申请需要预加载的资源得到一个Handle。
- 当要获取实例时通过Handle获取，其内部会为资源进行计数+1。
- 释放实例时也通过Handle释放，内部计数-1。
- 当模块清除或被销毁时，通过Handle将资源释放。简单地说需要有一个模块来管理 一个资源的加载和释放流程，比较适用于需要大量创建资源实例的场景。
设计图示
4、战斗单元相关设计
4.1 Actor的结构设计
初期需要设计一个Actor框架以继续开发，展示的仅仅是一个简单的结构。
- Actor: 是游戏中玩家，敌人，npc等基础单元。
- ActorData: 主要存储单元的属性和参数相关的数据
- ActorBehaviour: 主要管理Actor的模型和移动等表现相关的组件。
- FSMManager: 管理状态机
- CommandManager: 管理该Actor相关的指令，例如玩家输入指令，释放技能指令等
- CommponentAgent: 可以为Actor添加不同的Component以实现不同的逻辑。
4.2 Actor状态机想法
设计时希望能手动配置每个Actor的状态机，希望每个Actor可以有不同的状态。
所以需要设计一个动态状态机，其实思路很简单，就是需要一个决策对象来判断当前进入哪个状态类型的子状态实例。
5、UI框架设计
设计思想：
由UIManager来管理UI的生命周期，包括打开UI,UI栈，UI关闭等。尽可能实现UI逻辑代码与表现的分离。
描述:
- UIManager: 负责管理UI的生命周期，UI栈，UI关闭等直接调用接口提供。
UISysterm:挂载在UI预制体上，是UI逻辑和UI预制体的桥梁，主要由UIManager持有进行管理。 - UILogicBase: 是UI脚本逻辑，与预制体分离。这样不同的UILogicBase可以是多个不同UI预制体的逻辑脚本。
- UIDef: 用于静态注册UILogicBase类型与对应UI预制体的映射，用于通过UIDef来打开界面。
- UIFactory: 用于构建加载UI预制体。将UISystem和预制体以及UIBLogicBase结合起来。
- UILayerManager: 负责UI分层控制UI生成所处的层级，同时处理UI间的渲染顺序处理。
6、结语
上面介绍的思路和设计，都是基于本人以往经验设计开发，存在很多不足，但我会继续学习以将Demo开发完善，成为我技术成长的一个里程碑。