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

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

此更新方案要解决如下几个问题
1、资源、代码在线更新
2、framework、update模块自更新
3、玩家安装新版本后，减小没必要要的更新
4、更新中断的处理
5、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/.....  其它游戏资源
更新流程大体以下
一、从服务器取得版本列表(flist)
二、检查update的md5值，看是否有更新，若是有更新，则下载update.bin，从新载入，并退到main（退出以前，注意清除对某些的引用），再次从新进入
三、检查framework的md5值，看是否有更新，若是有更新，则下载framework.bin，并提示用户从新启动
四、读取本地安装目录的版本列表文件(flist)
五、比对服务器版本列表和本地安装目录列表中的大版本号，若是大版本号不同，则提示用户去APPSTORE上下载。
六、读取upd目录的版本列表文件(flist)，若是flist文件不存在，或者flist中存放的core与安装目录列表中的不一致（表示用户安装了新版本），则清除整个upd目录,并将本地安装目录的flist内容，写入upd目录

七、对比服务器列表与本地列表中的version（由上一步能够获得），若是version相同，则认为数据是不须要更新的
八、若是version不一样，则与服务器的flist对行md5差别对比，获得须要更新的文件
九、遍历须要更新的文件列表，若upd存在，则效验其MD5值，若是MD5值与服务器的相同，则从待更新列表中移除（这一步，是为了应对上一次更新过程当中，玩家中途退出的状况）
十、逐个更新文件，每一个文件更新完毕后，再次效验其MD5码，若是MD5码效验失败，则从新下载此文件
十一、待全部文件更新完毕，重写upd文件中的flist
十二、进入游戏

资源的下载是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多小时的编程时间，因此，这事儿我又花了好几天。其间也赶上了很多问题。
我先来讲说新版的更新流程
在前一文章的基础上，咱们修改前三个步骤
一、从服务器取得update模块,与本地进行比较
二、检查update的md5值，看是否有更新，若是有更新，则下载update.bin，从新载入，并退到main（退出以前，注意清除对某些的引用），再次从新进入
三、若是本地update的值与服务器相同，表示update模块没有更新，则去下载文件列表 flist
.....后面的步骤不变

这样修改完毕后，咱们就能够彻底实现update模块的自更新，以及framework的自更新了。 整个过程不须要从新启动。
下面来讲说这几天赶上的问题
一、在ANDROID上读取APK内文件的MD5值
因为CCCrypto::md5file是用fopen读取文件内容，再交给MD5计算器得出MD5值。 因此，在APK里是不能够的，后来，我把fopen改为了CCFileUtils::getFileData获得解决
二、flist是一个LUA文件，若是处于APK中，则没法使用dofile,若是是从网上下载，也没法使用dofile
为了保持兼容，在读取APK和执行网上下载来的flist时，我使用了loadstring(str)() 这样就解决了全部问题
三、递归建立文件和清空文件夹
一开始使用了os.execute来执行mkdir,rm等命令，但一但执行命令时控制台有输出，那整个LUA的LOG就乱了。 后来改成了lfs手工建立和遍历删除来解决。工做良好
四、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

写到这里，已经不知道本身还要说些什么了。虽然目前功能不够完善，但已经能够发码了。但愿可以给你们一个参考。

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

二、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检查等工做。 但总的来讲，也都差强人意，想要进行更新的模块，就须要打包。 所以，不如将那些代码打入到一个包。
这样更新过程当中能够减小一个步骤，也减小了错误机会
三、关于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的代码在个人更新方案中，就是一个普通的代码，不须要作任何的特殊处理。


四、在个人方案中，使用了 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一次。


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


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