客戶端熱更新框架之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框架” 這個模組，進行詳細講解，歡迎廣大小夥伴們留言評論！
轉載於:https://blog.51cto.com/liuguozhu/2385022