技術實踐| Hybrid模式下的熱更新方案

做過開發的小夥伴應該對“熱更新”不陌生吧！熱更新就是指在遊戲或軟體更新的時候，不用再重新下載安裝包進行安裝，而是在啟動應用程式的時候，在內部進行資源或程式碼的更新。那麼如今，市場為什麼越來越多地選擇熱更新技術呢？

要知道，釋出一個app的新版本，要上架到應用市場是需要稽核的。ios應用市場稽核很嚴格，而且稽核過程需要一定的時間，android市場也一樣，遇到一些節假日甚至會往後延期。因此，對於一些緊急的bug修復以及實時性較強的功能釋出（比如運營活動），熱更新的方式是更優的選擇，這樣可以繞過應用市場的稽核。

背景是什麼

早在2017年，App Store稽核團隊便針對App Store中“熱更新”的App開發者傳送郵件，要求移除所有相關的程式碼、框架或SDK，並重新提交稽核，否則就會在AppStore中下架該軟體。由於軟體熱更新繞過了蘋果的稽核，駭客開發者有可能會透過提交正常的版本之後，透過熱更新的方式修改APP導致安全隱患，利用這個“後門”來竊取使用者裝置中的隱私資訊。

與此同時，各行各業的業績卻需要應對千變萬化的市場需求背景下加速增長。移動網際網路背景下，APP這個主流觸達使用者的工具，變成為了商家流量競爭的主戰場。技術作為業務的市場觸達及活躍的保障手段，對於業務應用，尤其是 高頻引流及活躍的應用需要保持快速迭代更新。基於這個背景，可以說開發者們從未放棄探索及尋找熱更新的最優技術解決方案。

App熱更新技術方案

市面上App熱更新技術方案可歸納為兩大類：純原生（Native）的，以及Hybird（混合開發）模式下的技術方案。

純原生（Native）的熱更新技術解決方案典型的有Dexposed、AndFix、KKFix.....很多且應用也不錯，但隨著市場上“敏捷開發”，“一端開發，多端上架”等研發概念探索成型並有一些成功實踐被廣而告之以後，Hybird（混合開發）的移動研發模式便開始流行起來。

因此，我們在本文中重點探討一下 混合式App開發模式下的熱更新方案。

混合App開發模式之「Native+小程式」

介紹混合App的熱更新方案前，還得先介紹一下混合App開發模式都有哪些。

在微信把小程式帶火之前，H5在微信中“漫山遍野”。這些在類似微信的社交中心化平臺上生存的業務應用，主要目的是給企業主的業務做引流和活躍。既然已經開發了一套應用在微信上，為什麼不能應用於App的研發管理上呢？這樣是不是更服務敏捷開發的理念？

於是，混合App開發模式–「Native+H5」誕生了。

如今，微信全網小程式數量超過700萬，微信小程式日活超過4.5億，真正進入了業務應用小程式流行的年代，於是開始有人研究「Native+小程式」的App開發模式。

相比於「Native+H5」，「Native+小程式」的App開發模式優勢在哪裡呢？關鍵在於 小程式相比於H5，有其自身的優勢：

1、開發成本更低：小程式技術是前端容器技術的一種應用，其元件及UI都有明確的規範，開發者不用考慮相容性及類似H5開發時複雜工具及框架的選擇。
2、載入速度更快：小程式是基於App端實現的應用，自身對於App有一定的親和度，使用時不像H5的網頁載入方式，使用者主觀感覺會更流暢。
3、與宿主環境結合更緊密： 如上所述，小程式是基於App端實現的應用，故只能在特定的平臺內執行，可想而知其獲取系統(App)的許可權也會多於H5（H5是網頁,只要有瀏覽器就可以使用）。
4、使用者體驗更佳： H5網頁是在瀏覽器內使用，如果網速不佳或者網頁載入東西過多就會出現卡頓。 小程式只需在首次使用時是載入，也不會太精準，初次載入後頁面再載入就會很流暢了。另外，元件及UI都是有預設元件，展示體驗也會更佳。

基於上述資訊，小程式應用能火起來，或者說各大平臺競相“棄H5從小程式”也不是沒有其道理所在。

上述說的只是說了小程式自身比H5具備更優的技術解決方案，那麼放到混合App開發模式下比較， 「Native+小程式」的App混合開發模式的優勢可以總結為：

• 遠超過 H5 的體驗（支援本地快取，Webview，有豐富的元件與支援庫）；

• 能獲取更多系統許可權，完成更加豐富的產品設計；

• 可以避免 DOM 洩露（不使用常用的 window 物件與 document 物件）；

• 包尺寸有效減少，節省流量和儲存

                     圖示題：「Native+小程式」的App混合開發模式有許多優勢

「Native+小程式」的App熱更新技術方案

「Native+H5」的App，其熱更新的機制大致是：把需要頻繁發版的業務應用H5化，並內嵌至 App 中。當含有頁面連結的App版本過審以後，這些H5 頁面可以隨時遠端熱更新，使用者在不更新App版本的基礎上，就能使用最新版的業務應用。

那麼「Native+小程式」的App， 其熱更新方案好在哪裡呢？其好處並不在於熱更新本身，而是在於「Native+小程式」給企業技術和業務的價值更優，所發揮的作用更大。

首先，說說技術層面

小程式技術作為前端容器技術的技術實踐之一，天生與雲原生的理念親和，且具備容器技術的優勢：容器安全。

小程式技術的核心功能是檢視層與邏輯層分離，這種分離有很多好處：

1、方便多個小程式頁面之間的資料共享和互動。在小程式的生命週期中具有相同的上下文可以為具備原生應用程式開發背景的開發人員提供熟悉的編碼體驗；
2、Service和View的分離和並行實現可以防止JS執行影響或減慢頁面渲染，這有助於提高渲染效能；
3、因為JS在Service層執行，所以JS裡面操作的DOM將不會對View層產生影響，所以小程式是不能操作DOM結構的，這也就使得小程式的效能比傳統的H5更好。

小程式技術的核心功能：檢視層與邏輯層分離

其次，說說業務層面

“容器化”就是將容器中的每個部分（應用、流程等等）都打包在自己的容器中，這有助於提升複用性、透明度以及改善資源隔離。

小程式作為容器技術之一，具備將業務應用打散再重整的能力，即 應用鬆散耦合。產品經理、業務大大們，試想一下， 原先的幾十個業務模組，可以單獨拆分出來，互不影響的執行，不同型別的業務模組，還可以嵌入到你所需要的兄弟App中進行引流或業務承接。

最後小結一下，市面上熱更新技術解決方案有很多，如何能夠兼顧技術實現且最大限度的支撐高效能技術架構及業務發展，也是需要我們綜合考慮的。

---

技術產品實踐示例

  FinClip小程式開放平臺，為企業提供“小程式執行能力”，它作為小程式執行的環境，為小程式提供安全沙箱、程式碼解析和渲染等服務。 為了讓更多 APP 輕鬆擁有“小程式執行能力”。凡泰極客將“小程式執行時”實現成一個可私有化部署的 iOS 和 Android 版本的 SDK，可以被第三方整合。也就是說，任何 APP 透過嵌入FinClip小程式SDK即可瞬間獲得執行小程式的能力。
僅需 5 行程式碼，即可讓你的 APP 快速啟動和執行小程式，而且小程式執行時 SDK，Android 端 1.3 兆，iOS端 1.8 兆，輕量無感，同時SDK採用多執行緒執行方式，極端情況下也不影響宿主 APP 的安全穩定執行。

企業實踐案例

券商：合規安全下的內聯外引，助力財富管理數字化轉型

背景：

券商App中通常整合的業務功能繁多，傳統技術實現方式是緊耦合，相對獨立的業務功能也無法獨立開發測試、獨立釋出；此外，券商App本身可運營能力弱，明明使用者就在App上活躍著，也無法線上向其進行產品營銷，無法透過活動進行觸達

解決方案:

1、在App中整合   FinClip小程式執行時SDK，從而獲得小程式執行能力，逐步把傳統緊耦合的功能小程式化，獨立可上下架管理，和App載體鬆綁。
2、利用   FinClip相容微信小程式的特性，App各類功能進行小程式改造後部分也在合規前提下能夠被分享至微信，並引導客戶迴流至App，提升App的活躍度。
3、小程式輕量、便捷，並能靈活的“上下架”釋出，滿足高頻的營銷活動需求，並能夠針對不同客群推薦不同的營銷活動，實現千人千面營銷，促進業務辦理。

銀行：加速生態融合，打造開放銀行

背景：

數字化時代的信用卡，既需要滿足傳統線下消費場景，更需要關注日益上漲的線上消費需求。過去是使用者帶信用卡到線下消費，現在是銀行將商戶引進到App中，透過營銷活動引導使用者使用信用卡。銀行數字信用卡如何低成本吸引商家進駐、如何線上運營促進使用者消費?

解決方案:

1、銀行App透過整合   FinClip小程式執行時SDK，可引入外部優質的商家服務小程式，結合自身的金融服務能力，打造特色化金融服務，且豐富App使用場景，從而達到提升App使用者活躍的效果。同時，可利用   FinClip相容微信小程式語法的特性，銀行可快速、低成本引入微信生態中的小程式商家，降低運營成本。
2、銀行App可根據已有使用者畫像對使用者進行精細化管理，靈活呈現不同小程式給使用者使用，輕易實現對使用者的個性化服務;
3、"用完即扔”的營銷活動類程式碼可以快速釋出，滿足高頻運營活動要求。

以上就是對混合開發模式下，熱更新技術方案典例、相關概念以及應用案例的介紹，歡迎感興趣的小夥伴們在評論區討論交流！