一、什麼是熱更新？

熱更新，是對hot update或者hot fix的翻譯，計算機術語，表示在不停機的前提下對系統進行更改（摘抄一下）：

“hot就是熱，機器執行會發燙，hot就是不停機的意思。

熱更新，是個很形象的詞，機器燙的時候更新，開著更新。

比如Windows不重啟的前提下安裝補丁

比如Http伺服器在不重啟的前提下換掉一個檔案

那麼對於Unity3D來說，何謂熱更新？

額……這個真相實在是不想講出來，因為很多時候，這個詞都用錯了。

Unity3D是一個客戶端工具，使用者是否重啟客戶端，根本是我們不關心的問題。

很多時候我們用著熱更新這個詞彙，卻不需要真的熱更新。

只有少部分遊戲，遊戲資源在玩的過程中邊玩邊下，不重啟的前提下變更了資源。

我們不需要使用者不重啟客戶端就能實現資原始碼的更新，我們需要的是使用者重啟客戶端能實現資原始碼的更新。

讓我們暫時放過這個我們的需求連詞彙都用錯了這個基本事實，來總結一下何謂Unity3D熱更新，Unity3D熱更新就是指：使用者重啟客戶端就能實現客戶端資原始碼更新的需求或者功能。”

二、為什麼要熱更新？

熱更新，能夠縮短使用者取得新版客戶端的流程，改善使用者體驗。

沒有熱更新：

pc使用者：

下載客戶端->等待下載->安裝客戶端->等待安裝->啟動->等待載入->玩

手機使用者：

商城下載APP->等待下載->等待安裝->啟動->

有了熱更新：

pc使用者：

啟動->等待熱更新->等待載入->玩

有獨立loader的pc使用者：

啟動loader->等待熱更新->啟動遊戲->等待載入->玩

手機使用者：

啟動->等待熱更新->等待載入->玩

通過對比就可以看出，有沒有熱更新對於使用者體驗的影響還是挺大的，主要就是省去使用者自行更新客戶端的步驟。

三、如何熱更新？Unity3D的熱更新的方法比較

3.1、Android應用的熱更新

• 將執行程式碼預編譯為assemblydll。

• 將程式碼作為TextAsset打包進Assetbundle

• 執行時，使用Reflection機制實現程式碼的功能。

• 更新相應的Assetbundle即可實現熱更新。

3.2、Android 與iOS 熱更新的異同

• 蘋果官方禁止iOS下的程式熱更新；JIT在iOS下無效。

• 熱更新方案：Unity+Lua外掛。

3.3、使用Lua 外掛進行iOS 熱更新的原理

3.4、Unity 熱更新的注意點

• 需要更新的程式碼、資源，都必須打包成AssetBundle（建議使用未壓縮的格式打包）

• 熟悉Unity的幾個重要的路徑

• Resources（只讀）

• StreamingAssets（只讀）

• Application.dataPath（只讀）

• Application.persistentDataPath（可讀寫）

3.5、重要路徑之之Resources

• Resources資料夾下的資源無論使用與否都會被打包

• 資源會被壓縮，轉化成二進位制

• 打包後文件夾下的資源只讀

• 無法動態更改，無法做熱更新

• 使用Resources.Load載入

3.6、重要路徑之StreamingAssets

• 流資料的快取目錄

• 資料夾下的資源無論使用與否都會被打包

• 資源不會被壓縮和加密

• 打包後文件夾下的資源只讀，主要存放二進位制檔案

• 無法做熱更新

• WWW類載入（一般用CreateFromFile ，若資源是AssetBundle，依據其打包方式看是否是壓縮的來決定）

• 相對路徑，具體路徑依賴於實際平臺

•Application.streamingAssetsPath

• IOS: Application.dataPath + “/Raw” 或Application/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/xxx.app/Data/Raw

3.7、重要路徑之Application.dataPath

• 遊戲的資料資料夾的路徑（例如在Editor中的Assets）

• 很少用到

• 無法做熱更新

• IOS路徑: Application/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/xxx.app/Data

3.8、重要路徑之Application.persistentDataPath

• 持久化資料儲存目錄的路徑（沙盒目錄，打包之前不存在）

• 資料夾下的資源無論使用與否都會被打包

• 執行時有效，可讀寫

• 無內容限制，從StreamingAsset中讀取二進位制檔案或從AssetBundle讀取檔案來寫入PersistentDataPath中

• 適合熱更新

• IOS路徑: Application/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/Documents

3.9、使用Lua 外掛進行iOS 熱更新的總體流程

四、支援Unity iOS 熱更新的各種Lua 外掛的對比

4.1、uLua(asset store)

• uLua外掛原生版本，開山鼻祖

• 不會產生靜態程式碼

• 反射機制，效率低下，速度慢，gcalloc頻繁

• 已停止更新維護，不支援Unity5.x，淡出主流

4.2、uLua & cstoLua

• 開發平臺成熟穩定，Bug修復迅速

• 開發者眾多，資源豐富

• 靜態方法，效能優

• 有成功商業產品案例（啪啪三國、超神戰隊、酷魚吧捕魚、絕地戰警、這不是刀塔等）

• 都是基於原生版本的改進；未來，兩者會合併成一個外掛

開源專案地址：

4.3、sLua

• 靜態方法，效能優

• 核心程式碼簡潔

• 資源較少，開發平臺不夠成熟穩定

• 無成功商業產品案例成功商業產品案例

• 基於原生版本的改進

開源專案地址：

4.4、C#Light(L#)

• 淡出主流，想要了解的小夥伴點選這裡：

4.5、 uniLua

• c#實現的Lua虛擬機器，非完整方案

• 淡出主流

4.6、各位專家給出的分析

下圖縱座標為測試用例，橫座標是消耗時間或記憶體分配( 對數座標 )。

綜合來看肯定是uLua & cstoLua會更好一些。

五、實踐

熟悉NGUI的小夥伴可以參考這裡：

熟悉UGUI的小夥伴可以參考這裡：