淺談移動跨平臺開發框架的發展歷程

Lydiasq發表於2022-11-29

隨著移動網際網路技術的飛速發展,智慧終端迅速普及推廣,而原有的 Native App 有一個明顯痛點 —— 就是相同的功能需要在不同的平臺上都實現一遍,顯然,這種開發模式已經無法滿足企業和開發者對成本和效率的需求,由此便產生了混合 (Hybrid) 開發模式。混合 (Hybrid) 開發模式的開發成本低,一次開發多平臺執行,這些特性引起了越來越高的關注。

移動跨平臺的邏輯

跨平臺開發從本質上講是為了增加業務程式碼的複用率,減少因為要適配多個平臺帶來的工作量,從而降低開發成本。在提高業務專注度的同時,能夠為使用者提供一致的使用者體驗,實現“多快好省”的效果。

跨平臺是跨哪些平臺?怎麼樣的跨平臺邏輯?從當前的實際情況來看,移動端跨平臺需求主要集中在以下3點:

  • 桌面端跨移動端:桌面向移動端過渡的早期,希望 PC Web 與移動 Web 複用同一套程式碼。
  • Native 跨 Web:一套功能差不多的 Web 頁能夠在端外訪問,需要跨 Native App 與 Web。
  • 跨系統雙端:出於開發效率等原因,希望 Android、iOS 雙端複用一套業務程式碼,這也是目前主要的需求點。

而放眼未來,我們預見可能還會有這些跨平臺需求:

  • 跨小程式/輕應用:即用即走的輕量級應用,如各平臺的小程式、 Android 快應用、iOS App Clips。
  • 跨 IoT 裝置:各種有螢幕的裝置都會成為新的入口,如車載裝置、智慧電視等。

移動跨平臺方案的發展

不僅是移動應用的開發模式在持續的演變,跨平臺開發方案也緊緊的跟隨著開發模式的變化持續的演進,按照技術的發展,跨平臺方案可以分為三個時代。

1、Web 容器時代

基於 Web 相關技術透過瀏覽器元件來實現介面及功能,典型的框架包括 Cordova、Ionic 和微信小程式。Web 時代的方案,主要採用的是原生應用內嵌瀏覽器控制元件 WebView的方式進行 HTML5 頁面渲染,並定義 HTML5 與原生程式碼互動協議,將部分原生系統能力暴露給 HTML5,從而擴充套件 HTML5 的邊界。這類互動協議,就是我們通常說的 JS Bridge。

2、泛 Web 容器時代

採用類 Web 標準進行開發,但在執行時把繪製和渲染交由原生系統接管的技術,代表框架有 React Native、Weex 和快應用等。過渡到泛 Web 容器時代,最佳化了 Web 容器時代的載入、解析和渲染這三大過程,把影響它們獨立執行的 Web 標準進行了裁剪,以相對簡單的方式支援了構建移動端頁面必要的 Web 標準(如 Flexbox 等),也保證了便捷的前端開發體驗;同時,這個時代的解決方案基本上完全放棄了瀏覽器控制元件渲染,而是採用原生自帶的 UI 元件實現代替了核心的渲染引擎,僅保持必要的基本控制元件渲染能力,從而使得渲染過程更加簡化,也保證了良好的渲染效能。

3、自繪引擎時代

自帶渲染引擎,客戶端僅提供一塊畫布即可獲得從業務邏輯到功能呈現的多端高度一致的渲染體驗。Flutter,是為數不多的代表。Flutter 開闢了一種全新的思路,即從頭到尾重寫一套跨平臺的 UI 框架,包括渲染邏輯,甚至是開發語言。

移動跨平臺技術方案的對比

對比現有的跨平臺技術和解決方案也可以分為三類,分別是 Web 跨端、容器跨端、小程式跨端。

1、Web 跨端

Web 跨端比較好理解,因為 Web 與生俱來就有跨端的能力,因為只要有瀏覽器或 WebView,現在絕大多數端上(甚至包括封閉的小程式生態)都支援 Webview,所以只要開發網頁然後投放到多個端即可輕鬆跨平臺,例如 Web App、PWA(Progressive Web Apps)、Hybrid App、PHA(Progress Hybrid App)。

優點:

  • 沒有額外的學習成本,一套基礎技術吃天下
  • 不依賴特殊的配套設施,從開發、除錯到運維等所有工程化環節都是通用的
  • 背靠 npm 龐大的生態,百萬模組,應有盡有

缺點:

  • 經常會遇到白屏、卡頓等情況,使用者的體驗不佳
  • 無法呼叫系統的許可權,例如多媒體、藍芽、相機等
  • 效能不好,對記憶體的消耗大

2、容器跨端

另一種統一多端的思路是將 Native 定製成標準容器,讓同一份程式碼跑在一個個標準容器中。比較典型的代表是React Native 、Flutter、Weex,這類方案透過儘可能的取長補短,綜合了 Web 生態和 Native 元件,讓 JS 執行程式碼後用 Native 的元件進行渲染,以解決拋棄 Web 歷史包袱的問題。

具體來講 React Native 可以跨 Android、iOS、Web、Windows 四端,Flutter 可以跨 Android、iOS、Web、Linux 四端,Weex 可以跨 Android、iOS、Web 三端。

優點:

  • Flutter 快速的開發,富有表現力的精美UI和類似本機的效能
  • React Native 專注於使用者介面,使應用程式開發人員能夠構建高度可靠的介面
  • Weex 頁面就像開發普通網頁一樣;在渲染 Weex 頁面時和渲染原生頁面一樣

缺點:

  • React Native 沒有提供的需要自定義的應用,仍然需要使用原生開發
  • Flutter 構建的應用程式檔案很大,沒有廣泛的資源基礎,這意味著可能找不到開發所需的第三方庫和包
  • Weex 由於起步比較晚,社群活躍度不如RN,資料和開源專案也相對較少

3、小程式跨端

小程式跨端也比較好理解,就是讓同樣程式碼的小程式能夠執行在多個 App 中,例如開發完一個小程式除了讓其執行在微信之外,還能執行在支付寶、百度等超級App,甚至是自己的 App 中。

如果說小程式仍然是依靠 Web 技術執行的,那為什麼還要單獨去使用小程式呢?就像前面所說到的一樣,Web 始終沒法呼叫例如相機、藍芽等這樣的許可權,並且使用者使用體驗會收到一定的影響。而小程式則不同,小程式具有強大的 Web 渲染引擎、提供豐富元件、支援本地快取、避免 DOM 洩露等,並且其初衷是開放,例如微信、支付寶這樣的超級 App 也都相繼開放了小程式上架能力,小程式逐漸成為跨 App 的正規方式。

後期也甚至出現了例如 FinClip 這樣的小程式容器,可以讓個人或企業自己的 App 具備小程式的執行能力,讓其他 App 能夠具有超級 App 一致的小程式跨端能力。同時透過Flutter、Taro、 kbone等開發出來的小程式均可在   FinClip當中執行。

優勢:

  • 具備類似 Native App 的體驗度,使用較為流暢絲滑
  • 可以獲取使用者的相簿、多媒體、藍芽等基礎許可權
  • 可以透過便捷化的上下架方式完成相關頁面和業務的熱更新

缺點:

  • 大平臺的框架標準不統一,會稍微有影響,但都大同小異,W3C也在做小程式的標準化工作
  • 部分的外掛會用到原生相關的技術


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

相關文章