cocos2d-js 热更新具体解释(一)

本文将会具体解说cocos2d-js下的热更新机制。这篇内容先给大家介绍一下两个manifest文件就当热身了。

首先介绍project.manifest:  举个样例

{

"packageUrl" : "http://192.168.1.108/games/dragon_gold",

"remoteManifestUrl" : "http://192.168.1.108/games/dragon_gold/project.manifest",

"remoteVersionUrl" : "http://192.168.1.108/games/dragon_gold/version.manifest",

"version" : "1.0.2",

"groupVersions" : {

"1" : "1.0.1",

"2" : "1.0.2"

},

"engineVersion" : "3.6",

"assets" : {

"update1" : {

"path" : "dragon_gold1.zip",

"md5" : "140caaa2a4508912424e807a941bf71",

"compressed" : true,

"group" : "1"

},

"update2" : {

"path" : "dragon_gold2.zip",

"md5" : "140caaa2a4508912424e807a941bf7bc",

"compressed" : true,

"group" : "2"

}

},

"searchPaths" : [

]

}

  • packageUrl :  远程资源的下载根路径。 (它是为“dragon_gold1.zip”服务的。没了这个根路径我们都找不到要下载的包)
  • remoteVersionUrl :远程版本号文件的路径,用来推断server端是否有新版本号的资源。
  • remoteManifestUrl :远程配置文件的路径,包括版本号信息以及全部资源信息。
  • version : 配置文件相应的版本号。

    (这个用来推断是否有新的更新包)

  • assets :这个比較重要:里面的value就是相应要更新的包,当中path是更新包的包名。md5:当在下次更新时用来比較这次与上次下载下来的manifest文件里相应的包的md5 码是否同样,不同的话须要做些处理(更新。删除操作)。

    compressed是用来决定下载下来的包是否须要解压。

    group是重中之重。它是用来实现增量跟新的。它的值与groupVersions相相应。

举个样例:有这么两个用户,第一个用户下载app之后一直没玩。第二个用户一直在玩每次有更新时第二个用户都会跟着更新,如今第二个用户当前的version为1.0.1时。他会去更新update2这个包,可是第一个用户一直没玩所以他的更新包version是1.0.0。这时他须要去更新update1和update2这两个包,
这就是一个简单的实现增量更新的样例。

(备注:当时用2.x版本号引擎没提供这个功能。自己做了个增量更新功能坑了一段时间,如今引擎已经提供这个功能方便多了)。

我一直再讲project.manifest这个文件却没有说version.manifest,它事实上是个简化版 的project.manifest。当我们版本号已经有了几十个甚至几百个更新包时。显然下载project.manifest来推断是否有无更新是不明智的(由于更新包越多project.manifest体积变得越大。对于手机这么贵的流量下载这么大的东西是不划算的),因此此时的version.manifest用处就明显了,不管project.manifest体积多大,它永远仅仅须要这么几行代码就能够了:

{

"packageUrl" : "http://192.168.1.108/games/dragon_gold",

"remoteManifestUrl" : "http://192.168.1.108/games/dragon_gold/project.manifest",

"remoteVersionUrl" : "http://192.168.1.108/games/dragon_gold/version.manifest",

"version" : "1.0.2",

"groupVersions" : {

"1" : "1.0.1",

"2" : "1.0.2"

...

}

}

这一节就讲到这。下次開始用我眼下做的一个项目来具体解说热更新的使用方法。(备注:这一节是用工作时间写的。有点马虎了.......)

时间: 2024-08-26 03:12:36

cocos2d-js 热更新具体解释(一)的相关文章

cocos3——4.js热更新

1.launch.js代码: // launch: update files var __failCount = 0; var AssetsManager = cc.Scene.extend({ _am: null, _progress: null, _percent: 0, _percentByFile: 0, run: function () { // windows may not need update var not_update; if (cc.sys.os == sys.OS_WI

Cocos Creator热更新

一,添加热更新需要的文件 1. 在项目根目录添加 version_generator.js 文件   version_generator.js 内容如下: /** * 此模块用于热更新工程清单文件的生成 */ var fs = require('fs'); var path = require('path'); var crypto = require('crypto'); var manifest = { //服务器上资源文件存放路径(src,res的路径) packageUrl: 'http

webpack开启本地服务器与热更新

第一个webpack本地服务 webpack本地服务相关的一些操作指令与应用 一.第一个webpack本地服务 //工作区间 src//文件夹 index.js//入口文件 index.css//测试样式文件 index.html//结构文件 package.json//打包系统配置信息 webpack.config.js//打包配置 需要下载安装的加载器和插件: 1 npm install webpack --save-dev 2 npm install webpack-cli --save-

cocos2dx js 3.2 热更新

COCOS IDE用手机调试更新是正常的,是预想的结果,但用COCOS IDE打包发布APK,安装到手机上,热更新下载图片.JSON UI什么的都能正常更新替换,但JS脚本没有替换,这是为毛.更新文件是已经有下载到手机上了[email protected]:/ # ls -l /data/data/org.cocos2dx.CocosJSGame/files/ls -l /data/data/org.cocos2dx.CocosJSGame/files/-rw------- u0_a113  u

Node.Js的热更新服务——supervisor

因为目前项目每次修改文件要看效果,必须重启服务:node app.js再进入浏览器看效果,很是麻烦.所幸的是有很多第三方的管理工具(supervisor,hotnode,forever,pm2等),当文件修改保存后,能自动重启node服务,但需要刷新浏览器,帮助我们节省开发时间. $ npm install -g supervisor 启动服务: supervisor node.js 命令窗口显示信息如下: [暂时贴不了,需要重新登录] 其实webpack也是可以实现实时热更新服务,暂时没去配置

iOS热更新的几种方案

iOS APP的上架审核一直是个令人困扰的问题,动辄一个星期甚至半个月的审核时间,往往会耽误产品的运营计划. 尤其是,审核过程中难以避免的会被苹果拒绝,然后又是一个周期,很是痛苦. 除了在提交审核前,尽可能的保证产品没有Bug,以及充分研究苹果的app审核政策外,从技术开发层面如果能解决热更新问题,则再好不过了. 所以我简单整理了以下一些技术,可用于产品的内部更新,而不用重新提交给苹果审核.如果有更多的方案,或是错误,也请提出. 1. Hybrid App 混合架构,借助于Html,JS等前端技

RN学习1——前奏,app插件化和热更新的探索

react_native_banner-min.png React Native(以下简称RN)有大量前端开发者的追捧.前端开发是一个活跃的社区,一直尝试着一统前后端,做一个全栈开发,RN就是他们在客户端领域的尝试. 说是从零开始,但其实我还是懂一点点JS代码的,而且算是一个有经验的iOS.Android开发,对很多js和native交互的细节和特性还算了解,在QDaily里面也做过好多hybird的尝试,还经常用JSPatch做hotfix,总的来说,就是对hot update.插件化以及hy

IOS热更新-JSPatch实现原理+Patch现场恢复

关于HotfixPatch 在IOS开发领域,由于Apple严格的审核标准和低效率,IOS应用的发版速度极慢,稍微大型的app发版基本上都在一个月以上,所以代码热更新(HotfixPatch)对于IOS应用来说就显得尤其重要. 现在业内基本上都在使用WaxPatch方案,由于Wax框架已经停止维护四五年了,所以waxPatch在使用过程中还是存在不少坑(比如参数转化过程中的问题,如果继承类没有实例化修改继承类的方法无效, wax_gc中对oc中instance的持有延迟释放...).另外苹果对于

cocos2dx 3.1.1 在线热更新 自动更新(使用AssetsManager更新游戏资源包)

为什么要在线更新资源和脚本文件? 简单概括,如果你的游戏项目已经在google play 或Apple Store 等平台上架了,那么当你项目需要做一些活动或者修改前端的一些代码等那么你需要重新提交一个新版本给平台.但是平台审核和具体的上架时间是个不确定的.具体什么时候能上架,主要由具体的平台决定. 如果游戏项目是使用脚本语言进行编写的(如lua.js),那么一旦需要更新,则可以通过从服务器下载最新的脚本和资源,从而跳过平台直接实现在线更新.(有些平台是禁止在线更新资源方式的,但是你懂得) 闲话