android遊戲的增量更新（資源及代碼的熱更新）

需求
當遊戲須要更新時，沒必要讓用戶下載新的完整包，
只須要經過遊戲內部的更新系統自動更新差別包，達到節約用戶流量和時間的目的。

大致思路：
1.（遊戲邏輯用lua等腳本編寫的狀況）
這種方式的增量更新很是簡單，由於腳本自己能夠當成資源來處理，只須要將腳本和其餘資源（美術資源，配置檔）
從遊戲的原包（apk）中剝離出來，每次版本更新將舊版本和新版本的資源包做對比，生產差別資源包便可。

2.（遊戲邏輯用c++等編譯型語言編寫的狀況）
這種方式相對來講複雜一些，展開說一下，以c++做爲遊戲主邏輯的開發語言爲例。

分析：通常apk程序部分由java和c++兩部分組成，java部分主要負責與android平臺相關的邏輯，而c++部分則主要
負責遊戲的核心邏輯。一般咱們將全部的核心邏輯編譯打包成一個後綴爲.so的動態連接庫，遊戲開始運行的時候由java
端經過jni調用動態庫中的本地函數來運行遊戲的核心邏輯。而遊戲更新部分除了資源包，剩下的就是這個.so文件（遊戲
核心邏輯部分）。

須要作得事：
1.更新服務器，客戶端須要鏈接更新服務器下載差別包
2.客戶端更新模塊，負責客戶端版本的管理，須要從更新服務器上下載對應的差別包
3.文件差別對比生成工具，經過對比兩個不一樣版本的資源包來生產差別包。

1)更新服務器
一個簡單的支持http協議的web服務器，全部的版本差別包都放在裏面，當客戶端請求更新時，將對應的版本差別包所在位置的
url返回給客戶端，客戶端經過這個url今後服務器上下載差別包。好比客戶端發送以下請求http://xxx/version/update/1.2
意思是客戶端須要下載從1.1升級到1.2的差別包。

2)客戶端更新模塊
整個客戶端程序結構應該是這個樣子，（java部分）+（c++編寫的更新模塊部分）+（c++編寫的遊戲邏輯部分），其中前兩個部分組成客戶端更新模塊，
兩個c++部分的代碼分別對應兩個.so文件，其中（c++編寫的遊戲邏輯部分）的so文件將包含着差別包內，這樣遊戲邏輯就能被更新。
更新具體流程：客戶端更新模塊讀取當前版本號，將版本信息發送給更新服務器檢查，若是是否是最新版本，則下載更新包。
a)java部分，全部跟平臺登陸和支付相關的模塊必須所有放在這裏面
b)c++編寫的更新模塊部分，它負責鏈接更新服務器下載差別包，解壓，啓動遊戲核心邏輯。注：由於遊戲核心邏輯不在這個so文件裏面，因此經過更新模塊
調用核心邏輯的入口函數時，須要用到c++的動態函數調用技術，例如dlopen,dlsym這些函數

3)文件差別對比生成工具，能夠本身寫，也能夠用現成的，好比Beyond Compare。

這裏說一下版本差別包管理的兩種方式，
第一種是每次出新版本時，只須要生成與以前一個版本的差別包，玩家須要跨多個版本更新時，須要下載多個差別包，
舉例來講，如今遊戲的最新版本是1.3，某一個玩家的遊戲版本是1.1，那麼他須要先更新到1.2，再更新到1.3，不過整個過程應該是更新模塊自動完成。這種方式
的優勢是每次出版本只須要出一個差別包，缺點就是玩家若是跨不少個版本更新時，將會耗費更多的時間和流量。
第二種是每次出新版本時，將最新版本和以前每個版本都作對比，生成多個差別包，例如如今要出1.3的新版，那麼開發團隊須要作得就是生成一個1.3與1.1的差別包，
再生成一個1.3和1.2的差別包，這樣玩家就能夠從任何一個版本一次性升級到最新版本，優勢是玩家跨版本更新的時間和流量都減小，缺點是每次出版本須要耗費的時間更長。

最後說一下平臺登陸和支付相關的模塊所有要放在客戶端更新模塊的好處，這樣每次出新版本時不過有多少平臺，只須要生成一個通用的差別包，這樣就能大大減小維護和測試時間。