GameFramework 解析：编写游戏启动流程
前言
本文主要说明基于 GameFramework 框架去设计一个通用的支持热更的启动流程。以下流程与官方 Demo 的流程一致。
启动流程图
ProcedureLaunch
进行一些游戏启动的必要的初始化，支撑后续的启动流程，如：
- 初始化构建信息：如版本检测和资源更新的 URL 信息，更新界面资源等
- 语言设置：若有上次设置记录则使用上次设置记录，若没有则使用默认或系统语言
- 初始化变体：根据当前语言设置，通知后续底层加载对应的资源变体
- 初始本地化文本资源：根据当前语言设置选择对应的文本
以上涉及到的资源，包括更新信息文件、更新界面资源、本地化文本等都是 build-in 资源，也就是发布时就在包内，不可更新的。试想我们发布的游戏是一个仅仅支撑启动的包，所有游戏资源都需要在启动后的热更流程中下载，但一些启动图片，以及热更时的界面本身也是需要资源的，需要给出基本的文本、确认框等，以提供给玩家确认是否下载、下载进度预览，还涉及到更新请求的 URL。这部分资源就是我们需要放在包内的不可更新资源，主要用来支撑热更的启动，而 ProcedureLaunch 流程就是负责初始化这些资源和相关配置。
ProcedureSplash
闪屏流程，该流程会播放一个闪屏动画，然后根据当前的资源模式选择下一个流程，分别有
- 编辑器模式 →ProcedurePreload
- 整包模式（不可更新）→ProcedureInitResources
- 可更新模式 →ProcedureCheckVersion
编辑器模式下将使用 EditorResourceComponent 作为资源组件，里面使用的是 AssetDatabase 的接口直接加载 Editor 下资源，不涉及任何打包资源，不需要做资源列表初始化等操作。可直接进入 ProcedurePreload 流程。
这个并非必要流程，若不需要闪屏，去掉此流程，把逻辑挪到上一个流程中即可。
ProcedureInitResources
对于整包模式这个分支流程很简单，主要逻辑就是调用 ResourceManager.InitResources()，加载包内资源列表，并解析到 ResourceManager 中，这样就初始化完毕资源的相关信息了，包括 AB 包、Asset、资源组、文件系统、版本号等。因为整包模式下所有资源都在包体内，只需要一步初始化即可获得所有资源信息，且后续不需要进行更新，所以初始化后便进入 ProcedurePreload 流程。
ProcedureCheckVersion
此流程会向服务器请求一个当前版本信息，用于请求的 URL 在 ProcedureLaunch 流程中已被加载（在 Demo 中是 BuildInfo 中的 CheckVersionUrl），文件的格式一般是 Json（也可以是其他）。解析数据，先获取是否需要强制整包更新字段，若需要则弹框跳转到商城，流程不再往下执行。
若不需要强制整包更新，则尝试读取本地可读写路径中的 GameFrameworkVersion.dat 文件，读取该文件中的版本号，与上面从服务器请求的数据中的版本号作对比，对比只会产生两个结果：
- 需要更新版本 →ProcedureUpdateVersion
- 不需要更新版本 →ProcedureCheckResources
GameFrameworkVersion.dat 文件读取失败，或者文件中版本号字段解析失败，或者版本号与服务器最新版本号不相等，都会认为是需要更新版本，进入 ProcedureUpdateVersion 流程。若最终读取本地版本号成功，并与服务器最新版本号相等，则不需要更新版本，进入 ProcedureCheckResources 流程。
ProcedureUpdateVersion
此流程主要是调用 ResourceManager.UpdateVersionList()，更新版本资源列表，其实就是更新最新的 GameFrameworkVersion.dat 文件，此文件记录了服务器上最新资源的信息，包括一些校验信息等，这些信息将被用来在下一个 ProcedureCheckResources 流程中进行资源校验。
ProcedureCheckResources
资源检测流程，核心逻辑是调用 ResourceManager.CheckResources()，GF 内部会解析以下 3 个文件：
- 可读写路径下的 GameFrameworkVersion.dat，文件记录着服务器上最新的资源信息
- 只读路径下的 GameFrameworkList.dat，文件记录着只读路径（包内）下的资源信息
- 可读写路径下的 GameFrameworkList.dat，文件记录着可读写路径下（以前通过热更下载的）的资源信息
资源模块内部会根据本地资源信息和服务器资源信息作对比，标记出每个资源的状态，包括是否需要更新、是否可用、是否需要删除等。后续可以根据这些状态来加载或更新资源。
检测完资源后，有哪些资源是需要更新的就已经明确了，这个时候可以根据项目具体需求选择是否进入更新流程。 - 若游戏要求所有资源都为最新时才能进入游戏，则有资源变化就必须进入更新流程更新资源 - 若游戏做了分包下载，进入初始场景不需要更新（初始场景资源无变化），待用到对应资源时才更新，也可以不进入更新流程，在游戏中玩家需要访问未更新资源时，再在后台更新。
ProcedureUpdateResources
资源更新流程，如上文所说，在本流程可以根据项目具体需求，更新此刻需要更新的资源。例如游戏内做了资源分组，把一些活动、副本等资源单独分组了，则可以在此时只更新基础资源，待玩家访问到还没更新的活动、副本相关资源时，再在后台更新活动、副本的资源。更新的最小单位为一个资源组。
另外这个流程还需要实现热更时的当前进度、下载速度、剩余大小等界面表现。
更新完成后正式进入游戏业务流程。
ProcedurePreload
预加载流程，这一流程已经属于游戏业务层，但大部分游戏其实都需要这么一个流程，所以这里也把他规划到通用流程中，流程中主要负责设置框架的功能模块，预加载数据表，初始化游戏中的功能系统等。
Game
本文流程图中的 Game 并不特指某一流程，在 ProcedurePreload 结束后，流程就彻底从游戏业务来规划了，开发者可以在此再补充登录、选角、进入正式场景等流程。
最后
GameFramework 解析 系列目录：GameFramework 解析：开篇
个人原创，未经授权，谢绝转载！