原文地址：http://www.cocoachina.com/bbs/read.php?tid=213061
別在意那個標題中的“終極版”，那只是個噱頭爲了把你拉進來而已。
就好像頁遊廣告中的MM一樣，你點了一定會被騙的。
寫文章是非常花時間的，尤其是寫到大部分人都能看懂，且邏輯正確（不一定觀點正確），言語清晰，沒有錯別字的程度。
寫這篇文章的主要目的，是把我的思路做一個整理以備查；次要目的，則是希望我的思路對你有幫助。
簡單的說，就是刷我的存在感（靠這麼多人回帖）和你的優越感（靠這麼傻B的文章都發上來我的方法比這好一百倍我就是不想告訴你們）。
這篇文章成文都用了6個小時，前後修改了3次，標點符號和錯別字改了許多。爲了更多人能看到，我也只能用點小伎倆把你拉進來了。
我不求你認同我的方法，只願你看完後能有自己的思考。
轉身就走還來得及，但不要後悔哦……
-------------------------------------------------------------------------------------------------------------
0
依賴
這裏說的熱更新，指的是客戶端的更新。
大致的流程是，客戶端在啓動後訪問更新api，根據更新api的反饋，下載更新資源，然後使用新的資源啓動客戶端，或者直接使用新資源不重啓客戶端。
這種方式可以跳過AppStore的審覈，避免了用戶頻繁下載、安裝、覆蓋產品包。
我們一般使用這種方式快速修復產品BUG和增加新功能。
本文基於 quick-cocos2d-x
zrong 修改版 。
1 前言
1.1 他山之石
在實現這個機制之前，我研究了這幾篇文章：
- quick-cocos2d-x基於源碼加密打包功能的更新策略 by SunLightJuly
- 看到有同學在研究在線更新，希望我能幫到你一些 by Henry
- 基於Quick-cocos2dx 2.2.3 的動態更新實現完整篇 by 西門大官人
不幸的是，這幾個方案我都不能直接拿來用。因此思考再三，還是自己寫了一套方案。
==重要提醒==
這篇文章很長，但我不願意將其分成多個部分。這本來就是一件事，分開的話有種開房時洗完澡妹子卻說兩個小時後才能來。這中間乾點啥呢？
所以，如果你不能堅持兩個小時（能麼？不能？），或者你的持久度不能堅持到把這篇文章看完（大概要10~30分鐘吧），那還是不要往下看的比較好。
當然，你也可能堅挺了30分鐘之後才發現妹子是鳳姐，不要怪我這30分鐘裏面沒開燈哦……
1.2 爲什麼要重複造輪子
上面的幾個方案側重於儘量簡化用戶（使用此方案的程序員）的操作，而簡化帶來的副作用就是會損失一些靈活性。
Roberto Ierusalimschy 在 Lua程序設計(第2版) 第15章開頭說：
通常，Lua不會設置規則（policy）。相反，Lua會提供許多強有力的機制來使開發者有能力實現出最適合的規則。我認爲更新模塊也不應該設置規則，而是儘可能提供一些機制來滿足程序員的需要。這些機制並不是我發明的，而是Lua和quick本來就提供的。讓程序員自己實現自己的升級系統，一定比我這個無證野路子的方法更好.
因此，本文中講述的並非是一套通用的機制，而是我根據上面說到的這些機制實現的一套適合自己的方法。當然你可以直接拿去用，但要記住：
- 用的好，請告訴你的朋友。
- 出了問題，請別找我。
1.3 需求的複雜性
熱更新有許多的必要條件，每個產品的需求可能都不太相同。
例如，每個產品的版本號設計都不太相同，有的有大版本、小版本；有的則有主版本、次版本、編譯版本。我以前的習慣，是在主版本變化的時候需要整包更新，而次版本變化代表邏輯更新，編譯版本代表資源更新等等。這些需要自己來定義升級規則。
再例如，有的產品希望逐個下載升級包，有的產品希望把所有資源打包成一個升級包；有的產品直接使用文件名作爲資源名在遊戲中調用，而有的產品會把資源名改爲指紋碼（例如MD5）形式來實現升級的多版本共存和實時回滾，還有的產品甚至要求能在用戶玩遊戲的過程中完成自動更新。
AssetsManager 那套機制就太死板，在真實的產品中不修改很難使用。
而我也不建議使用 CCUserDefault 這種東西——在Lua的世界裏，爲什麼要用XML做配置文件？
如果抽象出我的需求，其實只有1點：
能更新一切
這個說的有點大了，準確的說，應該是 能更新一切Lua代碼與資源 。
如果你的整個遊戲都是Lua寫的（對於quick的項目來說應該是這樣），其實也就是更新一切。
1.4 版本號設計
關於上面 需求的複雜性 中提到的版本號的問題，可以參考一下這篇文章：語義化版本2.0.0 。
我基於語義化版本設計了一套規則在團隊內部使用：項目版本描述規則 。
在這裏，我儘量詳細地闡述我的思路和做法，拋磚引玉吧。