Hybrid App（混合 App）已經成為大家接觸最為廣泛的 App 形式，不管是我們用到的微信、支付寶還是淘寶、京東等大大小小的應用都非常熱衷於Hybrid App 帶來的研發效率提升和靈活性。

但我們正式進入到 hybrid App 的討論前，有必要先說下原生開發的一些基本情況，原因很簡單，因為我們日常接觸到的 hybrid App 就是在 Native App 原生應用基礎上所衍生出來的。

原生開發的流程

Native App 帶給使用者使用體驗非常好，整體的感受非常順滑，但是作為一個開發人員，我們談到原生開發的時候確很頭痛，因為意味著需要付出高額的開發成本和釋出週期。特別是對於需要頻繁迭代業務內容的企業來說，無論是更新功能模組還是修復有缺陷的版本，都需要重新測試、重新發版、重新提交第三方應用商店稽核上架，還要使用者配合，安裝新的版本，才能把舊版本覆蓋。

如果只用文字可能大家會比較難以有直觀的感受，我們通過下面這張圖來看看：

可以看到原生開發有一個比較大的弊端，就是不管是新開發還是應用的更新發版都需要經過比較繁瑣編譯、上架、安裝等過程，每一個過程都代表需要研發的重複投入。

這也是為什麼 Hybrid App 會成為大多團隊和開發者的第一選擇，原生雖好但是著實很費力費時。

Hybrid App的開發流程

Hybrid App 在一定程度上可以解決原生應用在流程上覆雜的問題，從架構上來講「原生+HTML5」是比較多的技術模式，但隨著這兩年小程式的發展，「原生+小程式」也成為了混合應用的一種新選擇，例如微信、支付寶等國民應用就是這樣的路線，當然在自己的 App 引入已有的小程式整體的效果會比 H5 好很多，至少從使用者體驗上來講，小程式有著接近原生的體驗避免了 H5 經常出現的白屏和卡頓問題。

雖然 App 執行小程式的技術會比H5難度高很多，但是目前也有 FinClip 等小程式容器技術可以直接上手使用，也算是比較便捷。

再來看 Hybrid App 的開發和上架流程，我們先用圖片流程看下：

Hybrid App 中對於經常變更、有業務運營屬性的內容，基本以 HTML5 或小程式的方式實現，融合在原生App中。

通常的做法是在原生 App 裡預先基於介面設計挖好一些洞，然後利用 WebView 在這些洞裡面渲染由標籤語言描述的內容，無縫呈現在 App 裡。

這些內容從哪裡來呢？它們通常預埋在 App 程式碼包，並且通過網際網路從伺服器端獲得更新。

Hybrid App 的核心價值

我們最前面也講了為了追求效率及靈活性，大家會越來越多的選擇 Hybrid App 開發模式，其背後的原因還為了更加高效實現更新上架，因為其帶有的熱更新能力是在開發環節極為重要的。

熱更新的原理大概是這樣的，通常應用內的伺服器端會監測這些內容的更新，繼而傳送內容更新的通知並通過網路向用戶端同步一些頁面內容的碎片，並且把這些下載的內容，通常是 HTML 和 JavaScript ，注入到之前挖好的這些洞洞裡。

另外需要說明的一點，上面我們講到的網路同步技術方案可供選擇的會比較多，例如通過雙向的 Web-Socket、HTTPlongpolling、SSE、PushtoPull 或者 CMS。一般來講裝置端通常通過 HMR 熱模組替換和程式碼注入等方式讓更新的程式碼在本地生效展示，也能夠避免我們應用的重啟。

以上就是關於 Hybrid App 開發上架的原理，如果你認為有用的話，也歡迎各為小夥伴在這裡交流和討論，另外也歡迎點贊。