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

FinFish發表於2022-10-31
為了照顧萌新童鞋,最開始還是對熱更新的概念做一個通俗易懂的介紹。
熱更新用通俗的講就是軟體不透過應用商店的軟體版本更新稽核,直接透過應用自行下載的軟體資料更新的行為。在使用者下載安裝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 遺留的這些問題。
熱更新還有很多值得討論的,你的看法和觀點是什麼?


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70021577/viewspace-2921112/,如需轉載,請註明出處,否則將追究法律責任。

相關文章