為了照顧萌新童鞋，最開始還是對熱更新的概念做一個通俗易懂的介紹。

熱更新用通俗的講就是軟體不透過應用商店的軟體版本更新稽核，直接透過應用自行下載的軟體資料更新的行為。在使用者下載安裝App之後，開啟App時遇到的即時更新，是一種各大手遊等眾多App常用的更新方式。

編輯切換為居中

新增圖片註釋，不超過 140 字（可選）

大家熟知的王者榮耀，經常就會採用熱更新的方式讓使用者直接在App內下載資料包得到更新，避免了使用者耗費時間和流量下載應用。

熱更新的技術價值

站在 App 開發者角度的“熱”是指在不發版的情況來實現更新，修復 BUG 和釋出功能，讓開發者得以繞開應用商店的稽核機制，避免長時間的稽核等待以及多次被拒造成的成本。

在熱更新出現之前，透過反射註解、反射呼叫和反射注入等方式已經可以實現類的動態載入了。熱更新的實質就是替換，需要替換執行時新的類和資原始檔的載入，就可以認為是熱操作了。

熱更新的技術選型

其實各家網際網路巨頭都有自己的熱更新技術，目前比較有代表性的技術可以分為兩類：類載入、底層替換。

1、類載入

只需要把 Bug 修復涉及到的類檔案插入到陣列的最前面去，就可以達到熱修復的效果。
類載入方案的時效性差 ，需要重新冷啟動才能見效，但修復範國廣，限制少。代表的有Qzone 超級補丁、微信 Tinker

2、底層替換

底層替換是一種nativite方案，其操作是在Native修改Filed指標的方式，實現方法的替換，達到即時生效無需重啟，對應用無效能消耗的目的。

底層替換方案限制頗多 ，可以不用重啟生效，載入經快，立即見效。代表的有阿里系的 AndFix 、Sophix
如果進一步對各個熱更新方案進行對比，可以用這張圖進行總結：

對比角度	Andfix	阿里 Hattix	Sophix	Tinke
方法替換	支援	支援	支援	--
方法增滅	不支援	不支援	冷啟動支援	--
反射呼叫	支援靜態方案	支援靜態方案	冷啟動支援	--
修復方式	即時生效	即時生效	自動判斷	冷啟動
安全機制	無	加密傳輸及簽名校驗	加密傳輸及簽名校驗	加密傳輸及簽名校驗
效能損耗	幾乎無損耗	幾乎無損耗	冷啟勁有低損耗	較高
補丁大小	小	小	小	小

熱更新就是一種熱操作，它是一種改變app執行行為的技術，其本質就是利用hook操作進行替換，在程式碼上是一種侵入性的操作。由於在安全性的考慮，Google 和蘋果是不支援熱更新的，在中國特殊國情下才出現了這種黑科技。

是否存在更加簡潔靠譜的熱更新機制呢？

答案是有的。

一種輕量的熱更新機制

也是因為國內網際網路企業和開發者的持續內卷，小程式形態的業務承載方式興起，至從2017年微信上線開放小程式以來，支付寶、百度、位元組等頭部廠商都投入到小程式的研發體系中，目前小程式已經受到市場的普遍認可，優質的操作體驗也改變了使用者原有第一時間下載App使用商家服務的習慣。

但是大家有想過嗎，小程式也是一種熱更新機制，對於微信、支付寶等平臺來講，可以透過管理後臺上下架的形式對小程式承載的業務進行管理，並且這種方式對於程式碼是完全沒有入侵的。相對於以上集中熱更新方式來講優勢也比較明顯，但是這種方式也是有門檻的。

不是每家公司都有像微信、支付寶等大廠商研發技術和成本讓自己的 App 具備小程式的執行能力，背後需要掌握複雜的編譯及渲染技術。

目前市場上有一些比較成熟的小程式容器技術是可以幫助任一App實現這種功能，例如 
FinClip
 是透過 SDK 整合的方式讓自有的 App 具備小程式執行能力。說的更淺顯易懂的話，這就是一種「Native + 小程式」的混合開發模式，藉助這種開發模式可以讓小程式執行在自有 App 中，將臃腫的 App 功能打散，功能模組互相解耦實現模組化開發，各業務模組間互不影響，透過管理後臺即能實現實時動態更新與釋出。

編輯切換為居中

新增圖片註釋，不超過 140 字（可選）

推測大家現在想到的一個點：H5 也能實現，為啥還要去用小程式容器。

很簡單，H5 白屏卡頓等問題頻發，對使用者體驗造成極大影響，對於追求使用者體驗的 App 來講這點就很排斥。實話現在使用各家銀行 App 內嵌的 H5 頁面我是真的很煩，載入慢還各種卡。

小程式類似原生的使用體驗、各種許可權的獲取、儲存快取等正好能夠解決之前 H5 遺留的這些問題。

熱更新還有很多值得討論的，你的看法和觀點是什麼？

熱更新技術簡易原理及技術推薦

熱更新的技術價值

熱更新的技術選型

一種輕量的熱更新機制

相關文章