客戶端熱更新框架之UI熱更框架設計(上)
熱更新是目前各大手遊等眾多App常用的更新方式。簡單來說就是在用戶通過App Store下載App之後，打開App時遇到的即時更新。對於手遊客戶端來說，受到蘋果審核的約束， 一次審核提交需要10~20天不等的等待時間。而這段時間開發進度依然會推進很多，一旦手遊上線，第一個版本在玩家瘋狂行為下，出點問題是必然的，所以”在線更新” 就成了家常便飯與必然。如果你要求必須整體重新下載完整下載包體，無法熱更， 那麽10~20多天後，遊戲估計就沒啥人了。
熱更新要解決的問題？
1: 更新頻繁而IOS審核長，IOS無法用DLL反射機制去做代碼更新。 如果無熱更新機制，則客戶端每次都需要玩家重新下載一次完整的安裝包，用戶體驗不好。
熱更新的基本原理是什麽？
首先要清楚Unity的打包原理，也就是AssetBundle的打包機制，他會把prefab打包成.asset格式作為傳輸的數據。通過校驗文件的MD5值來判斷是否需要更新，如果需要更新則下載差異文件。lua屬於解釋性文件所以能通過www直接下載到本地，通過C#與lua交互，把邏輯寫在lua裏，從而實現代碼熱更新。
為什麽需要帶熱更新的框架？
在中大型商業項目中，基於以上熱更新的實際運營需求，國內外各大遊戲公司紛紛基於國內已知技術與成熟插件，由技術總監或者主程來牽頭研發自己公司的熱更新框架。
筆者開發的熱更新簡單框架介紹：
筆者基於自身技術儲備參考部分行業公司框架產品，設計了一套簡單熱更新客戶端框架，現介紹如下，希望以此起到拋磚引玉的作用，結交行業朋友。
熱更新框架總體構成：
客戶端熱更框架，核心主要設計為以下幾個模塊：
A: 熱更新UI框架模塊。
B： lua框架（包含熱補丁模塊）。
lua框架由“純lua框架”與“C#映射lua”等技術構成。可以實現在lua腳本中，定義unity的生命周期（eg: Start()、Update() 等），方便lua的編寫與功能擴展。
業務邏輯方面，固定業務不需要頻繁修改的功能，筆者還是堅持用C#完成。 有頻繁更新需求的則用基於lua框架來編寫。基於本套lua框架，其比純lua編寫效率高很多。
C： 服務器端熱更新流程模塊。
D： 基礎支持插件與框架： xlua插件與AB(AssetBundle)框架。
熱更新框架運行過程：
整體熱更框架的運行流程如下：
1： 首先熱更新流程模塊啟動。 玩家可以從客戶端遊戲中看到PC或移動端(手機、Ipad等)與服務器的更新過程。
2： 熱更新的UI框架啟動。
3： lua框架啟動（與第2部分從宏觀上可以並行運行）。
3.1> 檢查本項目中哪些C#腳本需要進行Bug動態更新。
3.2> 初始化lua框架與C#建立生命周期映射關系，進一步方便程序員在lua中使用unity提供的系統函數(例如：Start()、Update()等) 。
3.3> lua框架啟動完畢後，通知框架外部可以開始加載項目lua文件，且運行期解釋執行。
4: 場景資源加載。
最後由於篇幅所限，筆者先寫到這。下一篇本人會先就 “熱更新UI框架” 這個模塊，進行詳細講解，歡迎廣大小夥伴們留言評論！
客戶端熱更新框架之UI熱更框架設計(上)