【原创】我所理解的自动更新-概要

概述
    一般来说，游戏在开发完成后会通过渠道分发至玩家的手机上。这也就涉及到游戏的下载，安装。但是游戏还有一个重要的步骤，更新。对于手游而言，更新分为大版本更新和当前内容更新（大版本更新也会包含当前内容更新）。大版本更新需要开发商重新提交游戏安装包，玩家重新下载安装包安装。而当前内容更新更多的是指更新脚本/资源等。那么问题来了，就技术而言，游戏通过什么方式下载安装？内容通过什么方式更新？恰好刚完成某手游的下载更新模块，就自己的理解，和大家聊聊游戏更新的那些事儿。

本文适用人群

    本文档适用于自研和cocos2d-x等以c++为基础的游戏引擎。

游戏下载
    Ios：测试阶段，一般是通过adhoc的形式提供ipa包进行安装，通过网页里的itms-services协议进行安装，你需要准备一个plist文件和相对应的ipa文件，玩家在ios设备上点击这个itms链接就可以进行安装（也可以是覆盖即更新）了。发布上线之后，跳转到appstore上相关的页面进行安装。
    Android：提供apk文件通过 Intent的方式来安装。

设想一个场景
    运营人员需要团队出一个版本上线给大家测试、试玩。版本支持人员在后台拉取代码编译最新的游戏版本（ios，android，各渠道），然后打包资源（完整包，差异更新包）。这样，一个新版本就创建成功了。
    运营将下载页推广出去吸引玩家。 新玩家在移动设备上（手机，pad之类）打开这个推广页（也可以是二维码），进行游戏的下载，下载完成后打开游戏进行资源更新。首次打开需要下载资源整包，这样做的好处是游戏主程序大小很小（小于30m，只有更新页面，加载页面等有限的资源，适合各种渠道的要求，并且用户下载时间较少，另外就是新出版本的时候只需要更新那个小于30m的app执行文件就可以完成大版本更新）。
    老玩家打开游戏后进行自动更新，根据游戏主版本和资源版本获取需要更新信息。如果没有更新，则进入到更新后流程。如果是大版本更新，则走游戏主程序更新流程，否则进行资源版本更新。
这套方案的大致结构图如下所示

ClientDownload：下载页（二维码，url）根据UserAgent判断设备版本来下载/更新app
ClientUpdate：更新页（渠道id，app版本，资源版本）
DownloadServer:web服务器（下载页，更新页），跟VersionInfoServer通过scp进行数据交互
PublishBackend：发布后台（渠道创建/查看，编译app，更新app版本，打包资源，更新资源版本，版本日志）
DB：版本信息数据（渠道信息，渠道版本，app下载链接，资源链接）
VersionInfoServer：打包服务器（打包资源，app编译，发布）
ResPackageTool：资源打包，打包不同渠道的资源。从版本服务器下载单独渠道的资源并打包完整包和差异包，设定版本号
APP Publish：app发布，从版本服务器上下载代码，编译，签名生成app
VersionServer:代码及资源仓库，根据渠道（appstore，ios测试，android 91， 360等渠道）进行分支处理。
梳理一下整个流程
开发/运维人员：进入PublishBackend，创建app版本，设置资源版本号，添加渠道号，选择合适的资源进行编译，资源打包（通过VersionInfoServer分配任务：通过APP Publish去VersionServer获取代码和资源<ios，android等不同版本的编译>，分发任务到ResPackageTool进行资源打包），结束后，使用scp上传到外网的DownloadServer。
玩家：浏览器进入http://version.mygame.com/（ClientDownload通过UA来区分不同的下载包<ios，android，win32>），下载安装并启动游戏，游戏通过http://version.mygame.com/channelid=%d&appver=%d&resver=%d返回需要更新的资源链接，curl下载，解压并合并到游戏资源中。

【原创】我所理解的自动更新-概要
【原创】我所理解的自动更新-环境搭建和协议制定
【原创】我所理解的自动更新-外网web服务器配置
【原创】我所理解的自动更新-APP发布与后台发布
【原创】我所理解的自动更新-资源打包流程
【原创】我所理解的自动更新-客户端更新流程
【原创】我所理解的自动更新-知识点讲解