為了照顧萌新童鞋，最開始還是對熱更新的概念做一個通俗易懂的介紹。
熱更新用通俗的講就是軟體不透過應用商店的軟體版本更新稽核，直接透過應用自行下載的軟體資料更新的行為。在使用者下載安裝App之後，開啟App時遇到的即時更新，是一種各大手遊等眾多App常用的更新方式。
大家熟知的王者榮耀，經常就會採用熱更新的方式讓使用者直接在App內下載資料包得到更新，避免了使用者耗費時間和流量下載應用。
熱更新的技術價值
站在 App 開發者角度的“熱”是指在不發版的情況來實現更新，修復 BUG 和釋出功能，讓開發者得以繞開應用商店的稽核機制，避免長時間的稽核等待以及多次被拒造成的成本。
在熱更新出現之前，透過反射註解、反射呼叫和反射注入等方式已經可以實現類的動態載入了。熱更新的實質就是替換，需要替換執行時新的類和資原始檔的載入，就可以認為是熱操作了。
熱更新的技術選型
其實各家網際網路巨頭都有自己的熱更新技術，目前比較有代表性的技術可以分為兩類：類載入、底層替換。
1、類載入
只需要把 Bug 修復涉及到的類檔案插入到陣列的最前面去，就可以達到熱修復的效果。
類載入方案的時效性差 ，需要重新冷啟動才能見效，但修復範國廣，限制少。代表的有Qzone 超級補丁、微信 Tinker
2、底層替換
底層替換是一種native方案，其操作是在Native修改Filed指標的方式，實現方法的替換，達到即時生效無需重啟，對應用無效能消耗的目的。
底層替換方案限制頗多 ，可以不用重啟生效，載入經快，立即見效。代表的有阿里系的 AndFix 、Sophix
如果進一步對各個熱更新方案進行對比，可以用這張圖進行總結：
|
對比角度 |
Andfix |
阿里 Hattix |
Sophix |
Tinke |
|---|---|---|---|---|
|
方法替換 |
支援 |
支援 |
支援 |
-- |
|
方法增滅 |
不支援 |
不支援 |
冷啟動支援 |
-- |
|
反射呼叫 |
支援靜態方案 |
支援靜態方案 |
冷啟動支援 |
-- |
|
修復方式 |
即時生效 |
即時生效 |
自動判斷 |
冷啟動 |
|
安全機制 |
無 |
加密傳輸及簽名校驗 |
加密傳輸及簽名校驗 |
加密傳輸及簽名校驗 |
|
效能損耗 |
幾乎無損耗 |
幾乎無損耗 |
冷啟勁有低損耗 |
較高 |
|
補丁大小 |
小 |
小 |
小 |
小 |
熱更新就是一種熱操作，它是一種改變app執行行為的技術，其本質就是利用hook操作進行替換，在程式碼上是一種侵入性的操作。由於在安全性的考慮，Google 和蘋果是不支援熱更新的，在中國特殊國情下才出現了這種黑科技。
是否存在更加簡潔靠譜的熱更新機制呢？
答案是有的。
一種輕量的熱更新機制
也是因為國內網際網路企業和開發者的持續內卷，小程式形態的業務承載方式興起，至從2017年微信上線開放小程式以來，支付寶、百度、位元組等頭部廠商都投入到小程式的研發體系中，目前小程式已經受到市場的普遍認可，優質的操作體驗也改變了使用者原有第一時間下載App使用商家服務的習慣。
但是大家有想過嗎，小程式也是一種熱更新機制，對於微信、支付寶等平臺來講，可以透過管理後臺上下架的形式對小程式承載的業務進行管理，並且這種方式對於程式碼是完全沒有入侵的。相對於以上集中熱更新方式來講優勢也比較明顯，但是這種方式也是有門檻的。
不是每家公司都有像微信、支付寶等大廠商研發技術和成本讓自己的 App 具備小程式的執行能力，背後需要掌握複雜的編譯及渲染技術。
目前市場上有一些比較成熟的小程式容器技術是可以幫助任一App實現這種功能，例如 FinClip 是透過 SDK 整合的方式讓自有的 App 具備小程式執行能力。說的更淺顯易懂的話，這就是一種 「Native + 小程式」的混合開發模式，藉助這種開發模式可以讓小程式執行在自有 App 中，將臃腫的 App 功能打散，功能模組互相解耦實現模組化開發，各業務模組間互不影響，透過管理後臺即能實現實時動態更新與釋出。
推測大家現在想到的一個點：H5 也能實現，為啥還要去用小程式容器。
很簡單，H5 白屏卡頓等問題頻發，對使用者體驗造成極大影響，對於追求使用者體驗的 App 來講這點就很排斥。實話現在使用各家銀行 App 內嵌的 H5 頁面我是真的很煩，載入慢還各種卡。
小程式類似原生的使用體驗、各種許可權的獲取、儲存快取等正好能夠解決之前 H5 遺留的這些問題。
熱更新還有很多值得討論的，你的看法和觀點是什麼？