写了一个超长的热更新文档,欢迎反馈

这个需要些时日了,别急哈

两个月内会出么

:joy::joy::joy::joy::joy:求加急啊大大,论坛里好多人在翘首以盼呢!!!

@panda
请问panda,目前这个流程是否能够应对宽带供应商的缓存服务器的干扰. 我观察这个流程中的服务器上manifest文件的url是固定的,那么被缓存以后就会一直判断没有更新,导致更新不到新版本.

这个文档不错,早点放出来可以省好多工作量。

字节级进度(百分比)
文件级进度(百分比)
已接收到的字节数
总字节数
已接收到的文件数
总文件数

-x 3.15会有这些吗

看着别人的游戏可以不重启热更新,如果creator不可以,总感觉起步就比别人短一截,感觉怪怪的…

下载资源,不涉及js的,也得重启,确实是感觉不顺畅。可是不用这个框架,自己也不知道怎么可以实现

我的手機裡至少也有上百款遊戲,
熱更新後需要重啟的至少有80%以上,就一個玩家而言我覺得還是可以接受的

汗!是我会错意了,不好意思。改成“if (typeof cc !== ‘undefined’ && cc.sys.isNative)”就可以了,直接判断if(cc)还是会报错 cc is not defined的。

panda大大,今天发现一种情况。比如一个1.0.0的版本热更新1.0.1,迭代了一个热更新的版本,1.0.1比1.0.0的版本当中在某场景添加了一个图片“A”,接下来大更新了1.1.0版本,这个版本必须要替换安装包,这个时候某些用户并没有通过打开客户端走热更新检测流程,而是直接去官网下载了安装包进行覆盖安装,这个时候打开客户端,发现图片“A”依然存在场景上,这表明1.0.1的更新资源依然存在于客户端当中,客户端读取的资源并不是最新安装包的1.1.0的资源,这时候想清理掉缓存的热更新资源是不可能的了,因为客户端和远程的版本都是1.1.0,不进行热更新处理,那么这种情况如何处理?虽说这种情况很极端,出现的很少,正常人都会打开客户端更新,但我们还是要处理不正常人的情况哈,我想到的是能不能分开获取安装包和热更新缓存的manifest文件版本号,对比两个版本,如果安装包内的版本高于热更新缓存版本,则清除缓存资源。

可否判断一下本次是是否是覆盖安装,如果是,并且覆盖安装的版本号是最新的,则删掉缓存之前的热更新版本。
但问题是,怎么判断玩家是不是覆盖安装。。。:sweat:

的確會有這種狀況,關注一下

请问文档中的“第一是更新下来的脚本需要干净的 JS 环境才能正常运行”,干净的JS环境是什么意思。

可以描述一下你看到的表现。我们说的重启是热重启,不是要用户关掉应用再开,是应用自动重新启动,进入起始画面而已。

这里的干净的 JS 环境,是删除了 JS 引擎的 runtime 和 Context,重新创建,也就是说,没有执行过任何 JS 脚本的环境,相当于网页中刚刚刷新页面,还没有执行任何脚本的状态。意义在文档中也说,已经执行的脚本引入的对象和新脚本执行后引入的对象可能会有冲突,这种冲突造成的问题是完全不可预知的

迭代升级的章节有介绍,理论上版本对比的时候包内 1.1.0 要高于缓存文件夹的 1.0.1,在更新的过程中不会以 1.0.1 为标准。但是你遇到的问题可能是搜索路径没有清理,导致 1.0.1 的搜索路径仍然被使用,发现了 1.0.1 版本的资源,这个时候就要用到迭代升级章节中介绍的清理操作了,你看一下应该就明白的

和迭代升级相关的还有这个帖子

http://forum.cocos.com/t/1-4/45202/5

@panda大大,请有空看看这个问题哈.
请问panda,目前这个流程是否能够应对宽带供应商的缓存服务器的干扰. 我观察这个流程中的服务器上manifest文件的url是固定的,那么被缓存以后就会一直判断没有更新,导致更新不到新版本.

后面版本会提供给 url 添加后缀的选项

顶,希望能尽快哈,否则会有很多人更新不到.

嗯,迭代升级版本的大更新部分我再看了下,现在明白那几行代码的意思了,上次看的时候不太理解,就过了,现在知道怎么搞了,谢谢panda大大