GameFramework解析：编写游戏启动流程

前言

本文主要说明基于GameFramework框架去设计一个通用的支持热更的启动流程。以下流程与官方Demo的流程一致。

启动流程图

ProcedureLaunch

进行一些游戏启动的必要的初始化，支撑后续的启动流程，如：

1. 初始化构建信息：如版本检测和资源更新的URL信息，更新界面资源等
2. 语言设置：若有上次设置记录则使用上次设置记录，若没有则使用默认或系统语言
3. 初始化变体：根据当前语言设置，通知后续底层加载对应的资源变体
4. 初始本地化文本资源：根据当前语言设置选择对应的文本

以上涉及到的资源，包括更新信息文件、更新界面资源、本地化文本等都是build-in资源，也就是发布时就在包内，不可更新的。试想我们发布的游戏是一个仅仅支撑启动的包，所有游戏资源都需要在启动后的热更流程中下载，但一些启动图片，以及热更时的界面本身也是需要资源的，需要给出基本的文本、确认框等，以提供给玩家确认是否下载、下载进度预览，还涉及到更新请求的URL。这部分资源就是我们需要放在包内的不可更新资源，主要用来支撑热更的启动，而ProcedureLaunch流程就是负责初始化这些资源和相关配置。

ProcedureSplash

闪屏流程，该流程会播放一个闪屏动画，然后根据当前的资源模式选择下一个流程，分别有

1. 编辑器模式->ProcedurePreload
2. 整包模式（不可更新）->ProcedureInitResources
3. 可更新模式->ProcedureCheckVersion

编辑器模式下将使用EditorResourceComponent作为资源组件，里面使用的是AssetDatabase的接口直接加载Editor下资源，不涉及任何打包资源，不需要做资源列表初始化等操作。可直接进入ProcedurePreload流程。

这个并非必要流程，若不需要闪屏，去掉此流程，把逻辑挪到上一个流程中即可。

ProcedureInitResources

对于整包模式这个分支流程很简单，主要逻辑就是调用ResourceManager.InitResources()，加载包内资源列表，并解析到ResourceManager中，这样就初始化完毕资源的相关信息了，包括AB包、Asset、资源组、文件系统、版本号等。因为整包模式下所有资源都在包体内，只需要一步初始化即可获得所有资源信息，且后续不需要进行更新，所以初始化后便进入ProcedurePreload流程。

ProcedureCheckVersion

此流程会向服务器请求一个当前版本信息，用于请求的URL在ProcedureLaunch流程中已被加载（在Demo中是BuildInfo中的CheckVersionUrl），文件的格式一般是Json（也可以是其他）。解析数据，先获取是否需要强制整包更新字段，若需要则弹框跳转到商城，流程不再往下执行。

若不需要强制整包更新，则尝试读取本地可读写路径中的GameFrameworkVersion.dat文件，读取该文件中的版本号，与上面从服务器请求的数据中的版本号作对比，对比只会产生两个结果：

1. 需要更新版本->ProcedureUpdateVersion
2. 不需要更新版本->ProcedureCheckResources

GameFrameworkVersion.dat文件读取失败，或者文件中版本号字段解析失败，或者版本号与服务器最新版本号不相等，都会认为是需要更新版本，进入ProcedureUpdateVersion流程。若最终读取本地版本号成功，并与服务器最新版本号相等，则不需要更新版本，进入ProcedureCheckResources流程。

ProcedureUpdateVersion

此流程主要是调用ResourceManager.UpdateVersionList()，更新版本资源列表，其实就是更新最新的GameFrameworkVersion.dat文件，此文件记录了服务器上最新资源的信息，包括一些校验信息等，这些信息将被用来在下一个ProcedureCheckResources流程中进行资源校验。

ProcedureCheckResources

资源检测流程，核心逻辑是调用ResourceManager.CheckResources()，GF内部会解析以下3个文件：

1. 可读写路径下的GameFrameworkVersion.dat，文件记录着服务器上最新的资源信息
2. 只读路径下的GameFrameworkList.dat，文件记录着只读路径（包内）下的资源信息
3. 可读写路径下的GameFrameworkList.dat，文件记录着可读写路径下（以前通过热更下载的）的资源信息

资源模块内部会根据本地资源信息和服务器资源信息作对比，标记出每个资源的状态，包括是否需要更新、是否可用、是否需要删除等。后续可以根据这些状态来加载或更新资源。

检测完资源后，有哪些资源是需要更新的就已经明确了，这个时候可以根据项目具体需求选择是否进入更新流程。

• 若游戏要求所有资源都为最新时才能进入游戏，则有资源变化就必须进入更新流程更新资源
• 若游戏做了分包下载，进入初始场景不需要更新（初始场景资源无变化），待用到对应资源时才更新，也可以不进入更新流程，在游戏中玩家需要访问未更新资源时，再在后台更新。

ProcedureUpdateResources

资源更新流程，如上文所说，在本流程可以根据项目具体需求，更新此刻需要更新的资源。例如游戏内做了资源分组，把一些活动、副本等资源单独分组了，则可以在此时只更新基础资源，待玩家访问到还没更新的活动、副本相关资源时，再在后台更新活动、副本的资源。更新的最小单位为一个资源组。

另外这个流程还需要实现热更时的当前进度、下载速度、剩余大小等界面表现。

更新完成后正式进入游戏业务流程。

ProcedurePreload

预加载流程，这一流程已经属于游戏业务层，但大部分游戏其实都需要这么一个流程，所以这里也把他规划到通用流程中，流程中主要负责设置框架的功能模块，预加载数据表，初始化游戏中的功能系统等。

Game

本文流程图中的Game并不特指某一流程，在ProcedurePreload结束后，流程就彻底从游戏业务来规划了，开发者可以在此再补充登录、选角、进入正式场景等流程。

最后

GameFramework解析 系列目录：GameFramework解析：开篇

个人原创，未经授权，谢绝转载！