Quick-cocos2d-x增加了编译及加密源代码的功能(具体可参考这篇文章)。以此功能为基础,我实现了一个版本更新模块,解决了自己项目中的版本更新需求。现抛砖引玉,与大家分享。
从基本原理和方案讲起比较枯燥,直接从介绍具体用法开始吧。
要能够在线更新文件,一个服务器是必须的。我目前实现的是用HTTP协议取文件,只需要有一个基本的web服务器,能通过类似http://<server>/<filename>的链接取到文件即可。当然,如果需要根据平台和版本进行文件的分发,服务器端还需要进行相应配置。
要调试下面的例子,自己在内网甚至就在本机上搭建一个最简单的web服务器就可以了。
一、基本更新功能
1.创建一个可以自动更新的程序
首先准备好我们的quick-x工程。作为例子,我们直接使用create_project来创建一个新工程helloworld来使用。这一步不用我多说。
接下来,请到这里下载我写的更新模块。只需要根目录下的update.lua文件即可,其他的目录下只是我的一些例子和工具。
(2014.5.30加注:quick-x的2.2.3版本里的sample/2048使用了这一更新模块,可以使用例子中的update.lua文件)
将update.lua文件加到helloworld工程的scripts目录下。修改文件中“local server = "http://192.168.1.98:8088/"”这一句,改成自己的服务器地址。
在scripts目录下创建一个新文件appentry.lua,然后打开工程原来的main.lua文件,把里面调用程序入口的代码复制过来。如果你使用的是最新版的quick-x,那么就只有“require("app.MyApp").new():run()”这一句。保存appentry.lua文件。
现在修改main.lua文件,去掉原来的程序入口代码,改成“require "update"”。
这样,更新模块就添加好了。程序在启动时,将先运行更新模块,完成后,自动调用appentry进入原来程序的真正入口。
现在可以先运行看看了,相信大家都会选择最方便的player来调试的。实际上真机也是没问题的。
运行后,界面上首先会显示“Loading...”,然后再进入熟悉的“Hello,world”界面。
接下来我们调试与服务器的连接是否正常。在服务器上创建一个flist文件,内容为:
locallist={ ver="1.0.1",stage={ },remove={ },} returnlist
需要保证用http://<server>/flist这样的网址能取到flist。如果是最基本的web服务器,把flist文件放在web服务目录的根下面就可以。如果希望用http://<server>/getfile?filename=flist这样的形式取文件,请自己修改update.lua里的相关代码。
现在重新运行程序,运行结果看起来没有什么不同。不过,如果是在player上调试,应该能在helloworld工程目录下找到flist文件,和服务器上的文件内容是一样的,说明我们从服务器取到了文件,连接是正常的。如果是真机,请在device.writablePath指向的目录下找flist文件。
现在,我们已经有一个可以自动更新版本的程序了。为了模拟真实的应用环境,我们将把源码加密打包再进行后面的调试。如果还不知道应该怎么打包,请再认真参考前面的文章。另外,推荐使用QuickXDev插件进行打包(可参考这一篇)。
为了后面更好的演示图片资源的更新,打包前可以修改一下MainScene.lua,在界面上添加一张图片,如下:
display.addSpriteFramesWithFile(GAME_TEXTURE_DATA_FILENAME,GAME_TEXTURE_IMAGE_FILENAME) self.bg=display.newSprite("#logo.png",display.cx-200,display.cy-200) self:addChild(self.bg)
将资源放到res目录下,在config.lua里配置好GAME_TEXTURE_DATA_FILENAME和GAME_TEXTURE_IMAGE_FILENAME的值。运行能正常显示图片后,就可以真正打包源码了。
假如你是完全按照参考文章去打包的,那你应该会将打包后的文件game.zip放在res目录下,并将scripts目录下所有原来的源码全部移走,启动程序,运行结果和没打包之前一致。
2.简单的功能更新
现在,我们希望将显示的文字改成中文。代码的修改是很简单的,将MainScene.lua中显示的字串“Hello,World”改成“你好,世界”就可以了。
但我们怎么让程序自动进行更新呢?当然是打包新代码然后放到服务器上让程序来取了。
因为我们只修改了MainScene.lua,所以我们只需要打包这个文件就可以了。打包时需要注意的是,MainScene.lua是放在app\scenes目录下的,所以它在打包目录下也应该放在相同的两级目录之下才行。
我们将新打包的文件随便改个文件名(其实在这一情境中,仍然叫game.zip也是没问题的),比如update.bin。将它放到服务器上,当然仍然要保证http://<server>/update.bin这样的网址能取到。
接下来我们修改服务器上的flist文件,如下:
locallist={ ver="1.0.2",stage={ {name="update.bin",code="8c528975dec8b6da5811e92f10a41be0",act="load"},},宋体"> 可以看出,list文件的版本号变成了1.0.2,这样客户端程序就知道有了更新,准备取新的文件。 stage里指出这个版本里有多少需要下载到客户端的文件。
name是文件名。code是文件的MD5码,用于验证文件。如果不想验证文件,code可以等于nil或者干脆不写这一键值。但不进行文件验证显然是不利的,除了不能保证下载文件的正确性而引起程序崩溃,还有就是不能进行同名文件的更新,如果原来已经下载过update.bin,不进行验证的话默认原来的文件是正确的,客户端程序将不会重新下载update.bin。
文件的md5码取得是很容易的,有很多方法。我实现更新模块时顺便写了个取md5的小程序,放在更新模块工程的tools目录下,使用方法很简单,将要取md5的文件放在getMd5/files目录下,用player打开getMd5工程运行,工程目录下生成的flist.txt里就是需要的内容了。
act="load"表明这一文件是代码文件,需要载入运行,如果是普通的图片资源,可以等于nil或者直接不写这一键值。
现在,可以运行客户端程序了。“Loading...”界面过后,显示的是“你好,世界”,自动更新成功了!接下来我们将讨论一下更新的基本原理,以确认我们的更新方式是真正可行的,同时进一步演示如何进行更深层次的功能更新(如资源路径变化的处理、framework包修改、update模块自身更新等)。当然,更新机制的健壮性(不能因为更新失败,或者更新文件被破坏造成程序无法工作),还有如何根据平台和机型进行版本文件的分发等,也是我们要讨论的。
二、更新原理讨论及更复杂的更新功能
1.更新原理
在前面的更新过程中,从服务器取文件列表,并根据文件列表再更新相关的文件,这都是很好理解的。当然其中还有些流程细节关系到健壮性、续传、文件版本分发等,我们可以后面再讨论。
对于一些刚开始学习Quick-x的朋友来说,可能希望了解的是,这一更新机制的替换原理是什么,为什么新的文件下载后能够替代原来的代码生效呢?
从前面我们参考的源文件编译及加密的相关文章,可以清楚的看到,初始代码打包成的game.zip文件,是在AppDelegate.ccp中,在程序启动前通过loadChunksFromZIP载入的。这一载入工作实际上已经将所有代码都加载了,之后调用require时,将会直接 调用而不会再去找代码文件来载入。也正因为如此,一些朋友会感到迷惑,即使下载了新的代码文件,又如何让它生效呢?
其实很简单,loadChunksFromZIP是可以多次调用的,而且如果第二次载入的包中的代码模块与之前载入的模块有重名,新的模块会覆盖旧的模块。
在Quick-x的Lua代码中,对应的调用接口是CCLuaLoadChunksFromZIP。有了这个接口,我们下载新的代码包后,就可以自己加载了。在update.lua里,在下载完成后,会自动将act标记为load的文件加载一次,这样,模块的新代码就取代了旧的代码,也就实现了我们之前看到的更新功能。
原理很简单,似乎没问题了?可惜问题没这么简单。这是因为require的机制问题。如果在第二次载入包之前,某一个模块文件已经被require过,那么,虽然第二次载入后,这一模块的代码已经被更新了,但再次require时,由于此模块不会被真正调用而是直接取原来的调用结果,将会造成更新不生效。
下面我们通过调试一个新的更新情景来说明这个问题及解决方法。
2.已经require过的模块的更新假设现在我们希望更新一下界面上的图片。
如果只是更换个别图片,这是很简单的,只需要在代码里newSprite里在图片文件名前加上完整的下载目录路径,然后将新的图片放到服务器上,在flist文件中添加图片文件名即可。不建议在要更新的代码里使用addSearchPath来添加搜索路径,因为在图片同名的情况下并不能保证优先查找到的是新的文件。
如果是更新纹理图,仍然可以使用上述明确指定资源路径的方式,同时也是建议的方式。因此,对于我们之前MainScene.lua的代码,可以做以下修改(假设device.writablePath是下载路径):
display.addSpriteFramesWithFile(device.writablePath..GAME_TEXTURE_DATA_FILENAME,device.writablePath..GAME_TEXTURE_IMAGE_FILENAME) self.bg = display.newSprite("#logo.png",宋体"> 当然这不是唯一的改法。为了说明主题,我们换成修改config模块的方式。这次不修改MainScene.lua,而是在config.lua中,修改原来的纹理图定义如下:GAME_TEXTURE_DATA_FILENAME = device.writablePath.."game.plist" GAME_TEXTURE_IMAGE_FILENAME = device.writablePath.."game.png"要注意的是,如果不是更新代码,这样写是有问题的。通常config模块都是最早被require的,甚至还在framework.init模块之前,此时device都还没有定义,所以如果是正常流程就会出错。但这里是更新代码,在被调用之前,update模块已经调用过framework.init,所以device已经被初始化过了。
这就引出了我们的问题,既然config模块在早期已经被调用,那么,当新的config下载到客户端后被加载时,再require实际上已经不能让它生效了!
最直接的解决办法是,在重新require之前,调用以下的代码:
package.loaded["config"] = nil即将config的调用标记清除。这样,再次require时就能让Lua程序重新去执行新的config模块了。我们将这条语句加到appentry模块的开头,这是最合适的地方了。
我们仍然将修改后的config.lua和appentry.lua打包成update.bin,和新的图片资源文件一起放到服务器上,这次服务器的flist文件如下:
local list = { ver = "1.0.3",stage = { {name="game.plist",code="29d103e9831720c1be12d8b33a1ea762",{name="game.png",code="e9dd2797018cad79186e03e8c5aec8dc",{name="update.bin",code="a681c6a002989832645ed26b766c7afa",remove = { },} return list在客户端启动程序,版本自动被更新,进入MainScene显示的图片变成了新的,成功了!大家可以自行验证不清除调用标记的情况。要注意的是如果是在player上,显示的图片一样会变成新的,这是因为device.writablePath在player上刚好是最优先的搜索路径,所以下载后的图片会被先搜到。因此这个测试最好下载到其他目录下,或者在新的config模块里加一条调试输出语句,这样就很容易确认新的模块是否真的被执行了。
由上述例子可以看到,更新模块时,困难的地方就在于判断重加载前有没有已经被调用的模块。特别是作在应用运行过程中动态更新的方案时,更需要对流程有清楚的把握。
即使是现在实现的这个预更新的方案,在解决了config模块的重载调用问题后,仍然要面对一个相对更困难的问题:如果framework模块需要更新,应该怎么办?
@H_502_241@ 3.深层逻辑更新的处理方式:强制覆盖式调用framework模块是Quick-x的核心之一,旧版本里是在main.lua里载入,现在的版本更是将它的载入位置提前到了Lua程序入口被调用之前的C++代码中,而通常framework的init模块也是早早会被调用。即使是update模块,也是先调用了init才能方便的实现更新功能。虽然这一模块更新的机率很小,但作为解决方案,还是要考虑清楚应该如何对它进行更新。
首先会想到的,是象之前处理config模块一样,清除调用标记。然而仔细考虑,会觉得不太行得通。因为看代码可以知道,init模块还调用了framework里很多的其他模块,在修改之后要理清哪些模块需要重调用是很繁琐的,而繁琐就容易出错。因此这不是最好的解决方案。
经过考虑,我觉得最方便的是这样一种解决方式:如果需要更新framework模块,那么,在打包时,不将代码放在framework目录下,而是其他的目录,如“framework1”。这样,所有的模块就变成了framework1.init、framework1.device等等,在新的代码里调用“require "framework1.int"”,将会真正重新运行框架代码,而不必担心有哪个模块没有重新运行生效。
这就是“强制覆盖式调用”的含义,它在很多情形下可以避免过于复杂的更新逻辑的判断,推荐给大家。
再举个例子,如果更新模块本身需要更新,那应该怎么办呢?如果要为此在更新模块中预留更新逻辑,会非常复杂难解。然而,如果跳出来看,其实完全可以在修改完update模块后,打包成一个updateNew模块放到服务器,让原更新模块下载后强制调用,这样一来,整个处理就简单了。
通过上面的讨论,现在我们已经能确认,update模块的更新功能是有效的。接下来我们还要讨论更新方案的另一个要点:安全性。
如果因为更新失败造成客户端无法启动,那无疑是致命的。幸运的是,Quick-x的打包机制能让我们保有一个原始版本,即使是在最不幸的出错情况下,程序仍然能回到最初的版本而不至于崩渍。
三、更新流程说明及特性分析 A.更新流程
B.安全性
- 加载初始安装包,载入旧资源列表
- 取最新资源列表文件,载入新资源列表
- 比较两个资源列表版本,如果一致,跳到第8步;以下流程中如果有误也跳到第8步
- 根据新资源列表检查现有文件,逐一下载新增或者有变化的文件,并加.upd后缀保存
- 每个下载的文件在保存后马上进行一次校验
- 所有文件下载完成,更新本地资源列表文件,用新列表替换旧列表
- 将下载的文件去掉.upd后缀,覆盖旧的文件
- 根据资源列表再校验一遍资源文件
- 第8步正确,则按资源列表的指示载入相关资源,启动程序(新版本)
- 第8步有错,说明资源列表与资源文件不匹配,删除本地资源列表文件(保证下次启动时重新更新资源),启动程序(原始安装版本)
可以看出在第6步之前,即使出错,也不会破坏原来的文件。跳到第8步后,一般能够以上一个更新成功的版本启动,除非上一个版本被用户破坏。
第6步和第7步出错,会造成资源列表与资源文件不匹配,跳到第8步后,肯定只有从原始版本启动了。
第8步错误,有可能是因为前面出错,也有可能是用户自己破坏了本地文件。无论如何,还是能从原始版本启动,并保证下次进入能再次更新。
第8步正确,并不一定说明这次更新是成功的,但启动起来的一定是最后一次更新成功的版本。
因此我们可以确认,只要update模块本身流程没有问题,此更新方案是安全的。
@H_502_241@ C.其他特性
- 对于确定的终端,服务器端只需要维护一个最新版本的文件列表。不管客户端是什么版本,都能直接升级到新版本
- 本地已经下载过的文件不会再次下载,只做增量更新
- 本次更新下载了部分文件但未完成最后更新,下次更新,已经下载成功的文件不会再重复下载
- 代码经过压缩,减少下载量
- 根据客户端请求时的参数能够做到版本分发
后记
对于方案的介绍到这里就告一段落了。后面这部分本来还想展开一下的,但后来觉得必要性没这么大,毕竟和大家分享的主要是解决方案而不是细节。
希望我的分享对大家能有所帮助,也请大家对方案的不足之类多提意见!
http://my.oschina.net/SunLightJuly/blog/180639