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

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

本文适用人群

    本文档适用于自研和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发布与后台发布
【原创】我所理解的自动更新-资源打包流程
【原创】我所理解的自动更新-客户端更新流程
【原创】我所理解的自动更新-知识点讲解