客服电话
APP下载
迪恩网络APP
随时随地掌握行业动态
官方微信
扫描二维码
关注迪恩网络微信公众号
前言本文主要引用cocos关于热更的官方文档，并在此基础上，总结sprout当前热更流程。 什么是热更热更（新）本质上是从服务器下载需要的资源到本地，并且可以执行新的游戏逻辑，让新资源可以被游戏所使用，它可以使开发者在不发布新版本的情况下，修复 BUG 和发布功能，让开发者得以绕开苹果的审核机制，避免长时间的审核等待以及多次被拒造成的成本。 Cocos 默认的热更新机制并不是基于补丁包更新的机制，传统的热更新经常对多个版本之间分别生成补丁包，按顺序下载补丁包并更新到最新版本。Cocos 的热更新机制通过直接比较最新版本和本地版本的差异来生成差异列表并更新。 cocos热更概述manifest了解cocos热更之前，先要了解manifest。在cocos中，manifest是一种文件格式，其对应的文件简称资源描述文件，是用来描述本地或远程包含的资源列表及资源版本。 manifest格式是仿照json格式，其关键字段的含义如下 :
{
"packageUrl" : 远程资源的本地缓存根路径
"remoteVersionUrl" : [可选项] 远程版本文件的路径，用来判断服务器端是否有新版本的资源
"remoteManifestUrl" : 远程资源 Manifest 文件的路径，包含版本信息以及所有资源信息
"version" : 资源的版本
"engineVersion" : 引擎版本
"assets" : 所有资源列表
"key" : 资源的相对路径（相对于资源根目录）
"md5" : md5 值代表资源文件的版本信息
"compressed" : [可选项] 如果值为 true，文件被下载后会自动被解压，目前仅支持 zip 压缩格式
"size" : [可选项] 文件的字节尺寸，用于快速获取进度信息
"searchPaths" : 需要添加到 FileUtils 中的搜索路径列表
}
Manifest 文件可以通过 Cocos Creator 热更新范例中的 Version Generator脚本 来自动生成。 工程资源和游戏包内资源的区别大家在创建一个 Cocos Creator 工程的时候，可以看到它的目录下有 assets 目录，里面保存了你的场景、脚本、prefab 等，对应编辑器中的 assets 面板。但是这些工程资源并不等同于打包后的资源，在使用构建面板构建原生版本时，我们会在构建目录下找到 res 和 src 文件夹，这两个文件夹内保存的才是真正让游戏运行起来的游戏包内资源。其中 src 包含所有脚本，res 包含所有资源。 所以我们的资源热更新自然应该更新构建出来的资源，而不是工程的 assets 目录。 在creator2.4.3中，重构了资源管理模块，采用bundle模块化管理资源。这里分享一个通过uuid来获取资源路径的API cc.assetmanager.utils.getUrlWithUuid //转换 uuid 为 url,这里返回的url是运行时游戏包内的资源路径 searchPaths搜索路径在谈到热更之前，关于searchPaths的概念，有必要先了解一下。在大多数的时候，我们描述一个文件的路径，都会基于一个”根目录“去给到对应的”相对路径“，并不会直接写死成”绝对路径“，这样更利于维护、迁移。在游戏开发中，其实我们”根目录“也是很难保证其确定性、唯一性。就拿热更功能而言，我们有一个图片，假设其对应bundle目录（默认是resources）的相对路径是 ”./png/icon1.png“，当我们游戏版本更新，需要更新该图片的时候，由于包内的资源是不可写的，那我们只能让其从另外一个地方读取到新的图片，为了保证代码的一致性，如果我们可以改变其对应的”根目录“，那代码中之前的相对路径都不需要修改，就能找到新的图片。 在creator中，其维护勒一套搜索路径的策略。对应的API可以查阅jsb.fileUtils.getSearchPaths、jsb.fileUtils.fullPathForFilename等。这里简述其原理。FileUtils中保存勒一个”根目录“数组，index越低的优先级越高，在查找资源的时候，我们如果指定的是”相对路径“，则其会按照searchPaths里面的”根目录“的优先级，去拼接成”绝对路径“去查找资源，如果路径有效，找到勒文件，则会停止继续寻找。 在游戏包的安装目录，肯定有一个目录是存放我们打包后的各种脚本、资源，我们这里称之为”游戏包目录“，在热更逻辑中，我们需要指定一个”热更目录“来存放我们热更的内容，这两个目录都应该设为搜索路径，并且需要控制版本，使优先级更高的目录，对应的搜索路径优先级也要越高，这样，我们才能找到最新的文件。一般而言，”热更目录“的优先级需要高于”游戏包目录“。 cocos的基础热更流程这是cocos官网资料的流程图，注意，当前流程是用户安装好 app 后，第一次检查到服务端的版本更新的情况，完整的热更流程会更为复杂一些，后面我们再慢慢补充。 本文主要帮助大家理解热更本身的流程逻辑，其各个细节，如断点续传、下载进度、并发下载、错误检测、解压缩、错误恢复等细节问题，暂不讨论。所以，把上诉流程图，可简单概况为： 根据当前包内的manifest的remoteVersionUrl字段，去下载其当前的版本描述文件，然后根据与本地的版本对比，若需要更新则更新到对应最新版本，不然就不需要更新，继续后续流程。 这里需要对其几个关键点，再细化剖析一下： _localManifest：当前包内的manifest首先，”游戏包目录“内应该有一个默认的manifest文件，描述当前游戏版本（"version"字段），这个manifest一般随游戏包卸载、安装来更新。然后在”热更目录“也会有一个manifest文件，描述当前热更目录下的版本信息。我们每次启动游戏的时候都应该判断一下，当前环境下，到底是”游戏包目录“，还是”热更目录“才是最新的版本，来调整其对应在searchPaths的优先级，较新的manifest也就称为当前包内的manifest，代码中用_localManifest来记录。 先请求远端版本manifest在manifest的”remoteVersionUrl“字段中，其对应的是远端服务器的版本文件，下面给到官方demo的一个version.manifest，便于大家理解
{
"packageUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/",
"remoteManifestUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/project.manifest",
"remoteVersionUrl":"http://192.168.50.220:5555/tutorial-hot-update/remote-assets/version.manifest",
"version":"2.0"
}
从上面可以看到，version.manifest有一个“version”字段，这也是我们快速进行版本对比的依据。下载version.manifest，然后再与本地_localManifest的版本对比，来检测当前包是否需要更新，这个过程代码上一般命名为checkUpdate。 临时文件夹的必要性在热更过程中，因为我们是多个资源依次下载的，这期间很可能出现各种问题，所有，我们需要一个临时文件夹来暂存我们的下载，等到全部文件下载结束后，还需要检测文件是否完整，才能去替换“热更目录”下的旧资源，不要直接在“热更目录”上下载，一旦出现问题，自己也搞不清那部分是新的，那部分是还是旧的。这种思路在程序设计中也可以借鉴体会，我们负责的一些数据、字段的维护，尽量能做到整体的替换更新，而不是到处随意的去修改、赋值。 热更是热更差异化文件，是怎么做到这点的在manifest文件中，"assets"字段下，记录每个资源的key和md5信息，只需要远端的_remoteManifest下记录的资源进行对比，新的key则是新增资源，没有的key则是需要删除的资源，md5不同的就是需要更新的文件。 热更好之后，怎么让其生效当我们热更好了新的资源后，怎么在不需要调整代码的情况下，让其生效？哈哈，刚刚上文已经介绍过了，我们调整我们的searchPaths，让“热更目录”优先级高于“游戏包目录”即可。 旧的版本资源怎么处理cocos的热更的虽然是差异化文件，但是其manifest脚本是记录勒对应bundle所有的资源，我们是能知道哪些资源已经不需要的，上文genDiff函数也提到过，但是个人认为，旧资源的删除需要谨慎，至少也是确保新资源更新好后，再去删除旧资源。 总结如果读者在消化勒上诉的一些知识后，利用cocos提供的基础功能函数，是完全可以彻底定制自己的热更流程的。热更，一言以蔽之，下载最新的远端资源替换当前包体内的就资源而已。比如一些小项目，完全可以整包的下载、替换，可以忽略其中版本对比、searchPath调整、文件校验等细节。 以上就是全面讲解CocosCreator热更新的详细内容，更多关于CocosCreator热更新的资料请关注极客世界其它相关文章！ |
请发表评论