移動端混合開發(webview)
使用 Hybrid 原因
動態化內容需求增大。 當需求發生變化時，純原生應用需要通過版本升級來更新內容，但應用上架、審核是需要週期的，這個週期對高速變化的互聯網時代來說是很難接受的，所以，對應用動態化 （不發版也可以更新應用內容，或稱熱更新） 的需求就變得迫在眉睫了。
業務需求變化快，開發成本變大。 由於原生開發一般都要維護 Android、iOS 兩個開發團隊，版本反覆運算時，無論人力成本還是測試成本都會變大。(用 hybird 人力負擔較小)
但寫 Android、iOS Native 的人還是必須的，只是人數較少(因為共用部分用 hybird 做掉)
所以在如今移動端盛行的年代，技術選型上基本都是混合開發（Hybrid）
原生Native混合開發
這類框架的主要原理是將APP需要動態變動的一部分內容通過H5來實現，通過原生的網頁載入控件 Webview（Android） 或 WK Webview（iOS） 來載入 （以後若無特殊說明，本書將用Webview來統一指代 Android 和iOS中的網頁載入控件）。 這樣，H5 部分就可以隨時改變而不用發版，動態化需求得到滿足 ; 同時，由於 H5 代碼只需要一次開發，就能同時在 Android 和 iOS 兩個平臺上正常運行，這也可以降低開發成本，也就是說，H5 部分的功能越多，開發成本就越小。 我們稱這種 H5+ 原生的開發模式為混合開發，對於採用混合模式開發的 APP，我們稱之為混合應用或 Hybrid APP，如果一個應用的大多數功能都是採用 H5 實現的話，我們稱其為 Web APP。
混合開發技術重點（Jsbridge）
如之前所述，原生開發可以訪間平臺的所有功能，而在混合開發中，H5 代碼是運行在 Web View 中的， Webview 實質上就是一個 瀏覽器器內核、其 script 依然運行在一個許可權受限的沙箱中，所以對大多數系統能力都沒有訪向許可權、如無法訪向文件系統、不能使用藍牙等，所以，對於 H5 不能實現的功能，都需要原生來實現。
而混合框架一般都會在原生代碼中預先實現一些訪問系統能力的 API，然後暴露給 Webview 以供 Javascript 調用，這樣一來， Webview 就成為 Javascript 與原生 AP 之間通信的橋樑，主要負責 Javascript 與原生之間調用消息的傳遞，而消息的傳遞必須遵守一個標準的協定，其規定了消息的格式與含義，我們將依賴於 Webview 的、用於在 Javascript 與原生之間通信並實現了某種消息傳輸協定的工具稱為 Webview Javascript Bridge，簡稱 Jsbridge，它也是混合開發框架的核心.
對寫 Webview 的前端來說，一旦需要原生功能，就需要寫 Native 的大大提供 method 來橋接
參考資料
- https://juejin.cn/post/6936814903021797389 深入淺出JSBridge：從原理到使用