【原創】我所理解的自動更新-概要

概述
    通常來講，遊戲在開發完成後會經過渠道分發至玩家的手機上。這也就涉及到遊戲的下載，安裝。可是遊戲還有一個重要的步驟，更新。對於手遊而言，更新分爲大版本更新和當前內容更新（大版本更新也會包含當前內容更新）。大版本更新須要開發商從新提交遊戲安裝包，玩家從新下載安裝包安裝。而當前內容更新更多的是指更新腳本/資源等。那麼問題來了，就技術而言，遊戲經過什麼方式下載安裝？內容經過什麼方式更新？剛好剛完成某手遊的下載更新模塊，就本身的理解，和你們聊聊遊戲更新的那些事兒。

本文適用人羣

    本文檔適用於自研和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發佈與後臺發佈
【原創】我所理解的自動更新-資源打包流程
【原創】我所理解的自動更新-客戶端更新流程
【原創】我所理解的自動更新-知識點講解