基于Quick-cocos2d-x的资源更新方案

昨天写了一篇关于更新方案的理论 游戏开发：通过路径搜索优先级来进行补丁升级（从端游到手游） 今天继续细化一下
由于新项目采用的是Quick-cocos2d-x，那我就直接给出我基于Quick-cocos2d-x-master( > 2.2.3 rc) 的更新方案吧

此更新方案要解决以下几个问题
一、资源、代码在线更新
二、framework、update模块自更新
三、玩家安装新版本后，减少不必要的更新
四、更新中断的处理
五、Quick-cocos2d-x中，遇上的问题

做到上面几点后，我觉得整个更新方案应该没有大问题了。
在说更新流程前，我先说说安装包的内容
首先，我们这里会涉及一个大版本号，大版本号的意思，就是C++部分的版本号，如果有变动，这个版本号才会动。 以提示用户去APPSTORE下载新的版本
其余的版本号，只是一个显示版本号，可以根据游戏内容来区分。

每一个安装包本身，包含了所有游戏资源。即一个新版本发布后，玩家是不需要更新的。点开即玩。
安装包内部带了一个文件列表，内容如下




local flist = {
  core = 1
  version = "1.0.1"
  update_md5 = "xxxxxx"
  framework_md5 = "xxxxxx"
  files = {
       {path="ui/shop/shop_close_btn.png",md5="xxxxxx",size="30"},
       {path="ui/army/army_tip.png",md5="xxxxxx",size="20"}
  }      
}
return flist



这是一个LUA文件，之所以使用LUA文件，是为了在LUA中使用dofile方便读取。而files里面，列出了所有包内的文件。 core就是我们刚刚提到的大版本号。
上面的 path，是相对于res的路径，且带完整目录和文件后缀

资源服务器上也有一份同样的资源列表。

服务器和安装包中的结构如下
res/flist 资源列表
res/update.bin 这个是update模块自己的打包
res/framework.bin这个是quick-framework的打包
res/game.bin这个是游戏逻辑的打包
res/.....  其它游戏资源
更新流程大致如下
1、从服务器取得版本列表(flist)
2、检查update的md5值，看是否有更新，如果有更新，则下载update.bin，重新载入，并退到main（退出之前，注意清除对某些的引用），再次重新进入
3、检查framework的md5值，看是否有更新，如果有更新，则下载framework.bin，并提示用户重新启动
4、读取本地安装目录的版本列表文件(flist)
5、比对服务器版本列表和本地安装目录列表中的大版本号，如果大版本号不一样，则提示用户去APPSTORE上下载。
6、读取upd目录的版本列表文件(flist)，如果flist文件不存在，或者flist中存放的core与安装目录列表中的不一致（表示用户安装了新版本），则清除整个upd目录,并将本地安装目录的flist内容，写入upd目录

7、对比服务器列表与本地列表中的version（由上一步可以得到），如果version相同，则认为数据是不需要更新的
8、如果version不同，则与服务器的flist对行md5差异对比，得到需要更新的文件
9、遍历需要更新的文件列表，若upd存在，则效验其MD5值，如果MD5值与服务器的相同，则从待更新列表中移除（这一步，是为了应对上一次更新过程中，玩家中途退出的情况）
10、逐个更新文件，每个文件更新完毕后，再次效验其MD5码，如果MD5码效验失败，则重新下载此文件
11、待所有文件更新完毕，重写upd文件中的flist
12、进入游戏

资源的下载是OK了，我们如何来做更新呢，如何能够使程序加载到正确的资源。为了正确更新资源，我们可以通过路径搜索来实现

--add update path
CCFileUtils:sharedFileUtils():addSearchPath(device.writablePath.."upd/")
--add res path for install
CCFileUtils:sharedFileUtils():addSearchPath("res/")

假设device.writablePath的目录是 /data/data/com.ooxx.game1/  那，第一个目录就是/data/data/com.ooxx.game1/upd/ 第二个目录是 res/
在ANDROID和IOS上，如果它检查是以 / 开头的，则认为是绝对路径，直接与文件名合并，生成对应的完整路径
如果不是以 / 开头的，那在IOS上的工作原理和WINDOWS一个样，在ANDROID上，他会先检查是否以assets开头，如果不是，则强加上 "assets/" 并去APK里面搜索
总之，上面的两个路径，是在任何地方都适合的。

以上就是我综合了阳光七月，yezehui200，GcvqrNq等人的更新方案而得出的自己的更新流程，上面的流程，几乎解决了本文开头就提出的问题。
下面我来说说我在实现这一方案中，遇上的问题
第一次遇上的问题，是执行安装目录中的flist. 因为dofile会认一个绝对路径，我在WINDOWS上是很OK的，但是在ANDROID上死活都不行，即使我硬编码 dofile("assets/res/flist") 其原因是因为，在ANDROID上，读取资源是从APK压缩包中读取的。
后来我只有通过一个比较矬的方法来优美地解决 就是使用CCFileUtils:sharedFileUtils:getFileData(“res/flist”) ,将得到的数据写入存储卡上，再dofile
由于upd目录下是没有res文件夹的，因此，我们可以保证，这货取得的肯定是安装包下的文件路径。 这样就解决了dofile在ANDROID上的问题。
而要想取安装上下的资源，就只能像这样 dofile(device.writablePath.."upd/flist")
总之，在添加了多路径搜索后，对路径的使用就要格外小心。

第二个问题，就是我在测试crypto.md5file的时候，发现，在ANDROID上，如果我们要取一个APK中的文件时，是会失败的，原因就是在C++实现里，它使用了fopen来打开文件，这在ANDROID上是做不到读取APK中文件的。 好在这个需求不需要了。

第三个问题，由于没有使用AssetManager,因此，目前还没有实现单个文件的进度条，到时候可能会参考一下AssetManager的实现 

第四个问题，目录创建问题， 比如 ui/shop/ 我们直接使用 lfs.mkdir(device.writablePath.."upd/ui/shop/) 是不会成功的，需要一级级向下创建，目前没有找到一次性搞定的方案，说不定使用os.execute的mkdir带参数，可以搞定 

最后我说说我测试资源服务器的方法。
测试资源服务器最简单的方法，就是网上下载一个nginx，解压，解压后，找到html目录，把资源扔进去，点nginx.exe启动，浏览器输入127.0.0.1，你会发现welcome nginx 输入127.0.0.1/1.png （假设你html目录下有这个图片），你会在浏览器里看到图片。
剩下的，就爱怎么整怎么整了。

如果是手机测试，最好是把内网的防火墙关了，否则连接不上。


代码还没有在IOS上测试过，以及update和framework的测试还没有OK，等一切都OK后。定会奉上源码

又是12点半了，对于一个程序员来说，这是一个黄金时间，精力旺盛，我想，是最适合整理和分享一些思路的时候了。
自从上次写了 基于Quick-cocos2d-x的资源更新方案
一直觉得有些什么地方不对。思考了许久之后，发现对于framework和update自身模块的更新，是有一定的问题的。
对于update自身模块的更新来说，检查是否有更新，若有更新，则使用require "main"重新来过。 是非常合理。
而对于framework的更新，就不是那么容易了。 前一篇文章中，我提到若检查到framework有更新，则提示用户重启客户端，看似很不经意的操作，却给了用户思考要不要再次打开此游戏的机会。
对于这种思考机会，我们是不能给用户的。 因此，无缝更新才是硬道理。

强势插入－－－－－－－－目前我使用的是 quick-cocos2d-x 2.2.3rc 版本－－－－－－－－－－－－－－－－－

在思索良久后，我发现对于update模块的实现，是完全可以脱离quick框架的。update模块所需要的scene,writablePath,md5file等功能，都不是quick提供的，仅仅是quick提供了一层封装。因此，我们可以使用纯cocos2d-lua的API来实现update模块。这样一来，framework.init就可以不在update模块里调用，那当我们在update中更新了framework模块时，我们完全不需要担心require重入问题。 因为在真正进入游戏前，我们的framework中的任何模块，都还没有被require过。
由于每天晚上只有1多小时的编程时间，所以，这事儿我又花了好几天。其间也遇上了不少问题。
我先来说说新版的更新流程
在前一文章的基础上，我们修改前三个步骤
1、从服务器取得update模块,与本地进行比较
2、检查update的md5值，看是否有更新，如果有更新，则下载update.bin，重新载入，并退到main（退出之前，注意清除对某些的引用），再次重新进入
3、如果本地update的值与服务器相同，表示update模块没有更新，则去下载文件列表 flist
.....后面的步骤不变

这样修改完毕后，我们就可以完全实现update模块的自更新，以及framework的自更新了。 整个过程不需要重新启动。
下面来说说这几天遇上的问题
1、在ANDROID上读取APK内文件的MD5值
由于CCCrypto::md5file是用fopen读取文件内容，再交给MD5计算器得出MD5值。 所以，在APK里是不可以的，后来，我把fopen改成了CCFileUtils::getFileData得到解决
2、flist是一个LUA文件，如果处于APK中，则无法使用dofile,如果是从网上下载，也无法使用dofile
为了保持兼容，在读取APK和执行网上下载来的flist时，我使用了loadstring(str)() 这样就解决了所有问题
3、递归创建文件和清空文件夹
一开始使用了os.execute来执行mkdir,rm等命令，但一但执行命令时控制台有输出，那整个LUA的LOG就乱了。 后来改为了lfs手工创建和遍历删除来解决。工作良好
4、compile_scripts.bat打包
我需要将update打一个包，main.lua不打包，其余的app和config.lua打一个包
由于compile_script.bat是按文件夹进行模块剔除的，所以，我只好调整以下结构
scripts
   +--launcher_src
       +--launcher.lua
   app
   +---MyApp
   +---config.lua
   +---scenes
 --main.lua
可以看出，我将更新模块单独放入了一个文件夹，将config.lua移到了app下面。 差点忘了说，我的update模块，也是没有依赖config.lua的。
这样，我就可以打出app和luancher两个包了，阳光七月的打包后缀是*.bin,我用了png，总之，这个后缀是无关紧要的，打包我写了两个脚本
build_app.bat
内容：%QUICK_COCOS2DX_ROOT%/bin/compile_scripts.bat -i scripts/app_src -p app -o res/app.png
build_lchr.bat
内容：%QUICK_COCOS2DX_ROOT%/bin/compile_scripts.bat -i scripts/lchr_src -p lchr -o res/lchr.png

这样当我们想要运行程序的时候，只需要打包一下就可以了。

而考虑到很多时候，我们改了代码就想直接按F5，不想去打包……。 这里有两个方案。
一是处理一下PLAYER的F5事件，自动执行上面两个脚本。
二是处理一下main.lua，使它支持打包和非打包模式，目前，我是通过修改main.lua来做的

LOAD_FROM_BIN = true
APP_NAME = "dota"
APP_PACKAGE_ROOT = ""

if LOAD_FROM_BIN then
    APP_PACKAGE_ROOT = "app"
    CCLuaLoadChunksFromZIP("res/lchr.png")
    package.loaded["lchr.launcher"] = nil
    require("lchr.launcher")
else
    APP_PACKAGE_ROOT = "app_src"
    package.loaded["lchr_src.launcher"] = nil
    require("lchr_src.launcher")
end

写到这里，已经不知道自己还要说些什么了。虽然目前功能不够完善，但已经可以发码了。希望能够给大家一个参考。

目前的版本存在以下问题
1、没有在update模块加载之前(main.lua中）添加搜索路径，导致update模块总是加载到安装路径下的

2、main.lua默认认为不更新的，但是目前代码过多，很难保证稳定性。因此，下一个版本，会将main.lua中的代码移到luncher里。

main.lua仅保持
local filemgr = CCFileUtils:sharedFileUtiles()
local writablePath = CCFileUtils:sharedFileUtiles():getWritablePath()
filemgr:addSearchPath(writablePath.."upd/")
filemgr:addSearchPath("res/")
CCLoadChunksFromZIP("lchr.png")
require "lchr.launcher"




这个代码，几乎不会因为需求有任何改动。
但这样只能在打包模式下执行更新模块。
不过，更新模块做好后，一般情况下是不需要去改动的， 因此，launcher内部，依然可以选择是采用ZIP方式来加载游戏代码，还是直接运行游戏代码。
PS：我也想过，将main.lua进行打包，这样main.lua也可以进行代码更新了。 但是，上面的代码中，如果说非要有什么需要动的话，那可能就是路径了。
就算把main.lua打包，在C++代码里进行加载，路径也是需要的，因此，如果路径改变了，C++代码也会变。 这是一个无解的问题，势必导致重新发布安装包。
因此，上面的实现和将main.lua打包为ZIP放入C++代码里加载是等同的，不需要再纠结。


如果觉得UPDATE模块负责的东西过多，那可以将目前的launcher拆分。
我们的launcher可以拆分为loader和update两个包，loader负责是否采用ZIP加载，以及是否需要进行update检查等工作。 但总的来说，也都差强人意，想要进行更新的模块，就需要打包。 因此，不如将那些代码打入到一个包。
这样更新过程中可以减少一个步骤，也减少了错误机会
3、关于framework
群里有人问道：framework总共才100KB，为毛在更新的时候要区分
在先前七月的文章中，区分framework的原因，是update模块依赖了framework，因此，当update检测到framework需要更新时，要消除require过的模块，重新再require一次。 因为lua中的require是一个MAP(当然，在LUA中是一个table,不要抠字眼),如果require发现一个东西已经require了，那他是不会再次require的。 这是一个策略上的优化，可以让你在代码里放心使用require,而不必担心别人已经require了。 同时，这在代码更新中，带来的就是一个问题，他会导致你新的代码无法执行。
我在思索很久后，决定重新消除update模块对framework的引用，因此，我使用了cocos2d-lua原生的API来实现了我的update，这样，framework的代码在我的更新方案中，就是一个普通的代码，不需要做任何的特殊处理。


4、在我的方案中，使用了 CCLoadChunksFromZIP来加载我的 res/app.png，这也是一个问题，首先， res是只有安装目录才有的路径。 对于已经更新的模块，应该是 writablePath.."upd/app.png"才对。 这是一个BUG。 其次，在这之前，我应该LOAD一次framework才对。
但如果我像下面这样做
CCLoadChunksFromZIP("framework")
CCLoadChunksFromZIP("app.png")


可能有人会问，如果某一天，我想把framework拆开，或者想把app拆分为不同的模块怎么办？
哦哈哈，这就是典型的想多了。
其实，我们在这里，CCLoadChunksFromZIP("app.png")即可。
然后，在MyApp.lua里面（这是app的入口) 使用CCLoadChunksFromZIP加载所有你想要的模块。
MyApp.lua的开头大概会像这样


在头上强加这段
CCLoadChunksFromZIP("framwork")
CCLoadChunksFromZIP("module1")
CCLoadChunksFromZIP("module2")
CCLoadChunksFromZIP("module3")
CCLoadChunksFromZIP("module4")
CCLoadChunksFromZIP("module5")


--这是原始文件的开始
require("app.config")
require("framework.init")


--这里可以初始化一些全局的模块，比如上面的所有模块都是“单件类“，那我们可以在这里全部require一次。


5、目前使用的是直线流程，并没有采用状态机制来做模块更新，这种方式下，完全不具备容错能力
6、没有实现先前提到的存储空间不足的提示问题。


这本来应该是写在本系列文章的第三篇中的，但我怕想法有漏洞，先写在这里，让大家拍砖