前端開發:如何正確地跨端

来源:https://www.cnblogs.com/88223100/archive/2022/09/20/How-to-properly-cross-end.html
-Advertisement-
Play Games

導讀:面對多種多樣的跨端訴求,有哪些跨端方案?跨端的本質是什麼?作為業務技術開發者,應該怎麼做?本文分享阿裡巴巴ICBU技術部在跨端開發上的一些思考,介紹了當前主流的跨端方案,以及跨端開發的經驗心得。 ...


 

 導讀:面對多種多樣的跨端訴求,有哪些跨端方案?跨端的本質是什麼?作為業務技術開發者,應該怎麼做?本文分享阿裡巴巴ICBU技術部在跨端開發上的一些思考,介紹了當前主流的跨端方案,以及跨端開發的經驗心得。

 

跨端

 

Write once, run everywhere。


我們都聽說過這句經典的宣傳用語,後來我們都知道,沒有什麼東西是可以真正 run everywhere 的,充其量也只能做到 debug everywhere。
而當我們談論一次編寫多端運行時,顯然不可能真的指跨一切所有端,大多數情況下你不會需要在電腦和手環上同步開發一個功能。

  • 跨 PC 和無線端。

 

  • 跨多 Native 平臺:例如跨 Android 和 iOS,甚至跨 Windows。

 

  • 跨投放 APP:隨著超級 APP 越來越多,很多業務需要在多個 APP 中投放同一個頁面。

 

  • 跨 Web 和 APP:Web 在很多情況下仍然是不可避免的,我們的頁面可能需要分享、SEO 或者投放到 M 站上等等,這時候就需要同時能在 Web 和 APP 內運行。

 

  • 跨 Web、多小程式、QuickApp 等:其實本來類似跨 APP,但是奈何小程式本身是各家控制的封閉生態,故而有了開發一次適配到多種封閉生態的訴求。

 

  • 其他端的跨端訴求:例如跨 POS 機,手錶等。


與我們多種多樣的跨端訴求相對應的,是百花齊放的跨端方案。

 

 百花齊放的跨端方案
以 Web 為基礎的 H5 Hybrid 方案
這類方案最為直接,簡單來說就是用網頁來跨端。由於我們絕大多數端上(甚至包括封閉的小程式生態)都支持 Webview,所以只要開髮網頁然後投放到多個端即可,在桌面端對應的方案就是 Electron。
為什麼不直接全用 Web?
從開發成本低、標準統一、生態繁榮上來說,H5 Hybrid 方案基本是不二之選。然而這種方案難以避免在性能和體驗上存在差距。Web 的生態繁榮來自於其良好的歷史相容性,也意味著沉重的歷史包袱。

  • W3C 標準作為開放技術標準,歷史包袱多,邏輯複雜。

 

  • Web 標準在設計上不是 Design for Performance 的,導致很多地方難以進一步改善,例如 JS 執行和 Layout、渲染互斥無法並行,導致過長的 JS 執行任務會執行正常的渲染導致卡頓。

 

  • Web 的標準化在推進上也比較慢,新的能力可能要比較長的時間才能使用。


React-Native/Weex 類方案
在移動平臺上尤其是早期 WebView 的性能體驗非常糟糕,前面我們也提到這種差距主要來自於 Web 生態本身沉重的歷史負擔。
而 React-Native/Weex 這類方案通過儘可能的取長補短,通過結合 Web 的生態和 Native 的組件,讓 JS 執行代碼後用 Native 的組件進行渲染。由於拋棄了 Web 的歷史包袱,這類方案可以做一些大刀闊斧的改動。
例如 RN 就如下圖中,把 JS 執行、佈局(Yoga)和渲染(Native 組件)放在三個進程分開執行,避免了 JS 執行複雜任務時界面卡頓。通過拋棄 CSS 中的大量標準,只支持部分 flex 佈局能力來減少佈局和渲染的複雜度。

 

 這種方案同樣存在一些缺陷:

  • iOS/Android 雙端本身不一致的組件和佈局機制,讓雙端一致性難以得到保障。

 

  • 依賴於 Native 機制也讓一些 CSS 屬性實現起來比較困難,例如老大難的 z-index 問題。


而最麻煩的一點在於,這套方案意味著非常高的維護支持成本。

  • 借用了 Web 的生態但並不完全是 Web 生態,很多地方不一致,最常見的吐槽就是慣用的 CSS 佈局方式無法使用。

 

    • 相比於瀏覽器新增一個感測器 API 都要配套完善的 devtool,這類方案大部分情況下的開發體驗保障可以說是刀耕火種(下圖為 Chrome 的方向感測器 API 的 devtool)。

       

       在 WebView 性能差距逐漸縮小的今天,維護這一套複雜方案的 ROI 是否值得,需要根據我們場景的具體訴求考量。

Flutter
Flutter 要解決的問題和上面的方案不同,完全不打算繼續在 Web 生態上借力,從設計之初也並沒有把 Web 生態考慮進去。相比於 RN 依賴 Native View 渲染,Flutter 則是自繪的組件,直接通過 Skia 繪製到屏幕上。
由於可以完全發揮 GPU 的能力,也不需要去 Native 繞一圈。Flutter 理論上能做到更好的性能和兩端一致性,這一意味著理論上未來可能基於 Flutter 的 JS 動態化方案能夠在樣式上支持的比 WEEX 更好。
從前端的視角看仍然更像是一個 Native 開發方案而非跨端方案(雖然其實是跨 Android/iOS 的)。目前最主要的問題是 Flutter for Web 從技術原理上來說離生產可用可能還非常遙遠。除此之外動態化能力的確實也會讓部分場景不適用。


研發框架 for 小程式
小程式是被創造出來的問題,各家小程式出於商業上的考量主動在 Web 生態的基礎上構造了相對封閉的生態。導致和 Web 生態格格不入。然而有多端小程式投放,或者同時投放小程式和 Web 端的場景難以接受使用。
由於小程式的端封閉且不受控,要解決小程式的跨端問題往往只能從研發框架層面出發。


編譯時方案
比較知名的編譯時方案是 Taro,大致的原理可以解釋為將 JSX 編譯到小程式的 WXML/WXSS/JS 上,而這類框架的實現原理其實並非真的是一個 React 或者類 React 框架,而是把看起來像是 JSX 的模板通過靜態編譯的方式翻譯成小程式自身的模板。
這樣做的限制非常明顯,那就是 JSX 是 JavaScript 的拓展語言(React Blog 寫的是 is a syntax extension to JavaScript),而小程式所採用的 WXML 卻是一個表達能力非常受限的模板語言,我們不可能完成從一個通用編程語言到模板語言的編譯。
而靜態編譯類框架為了做到這一點,採取的方式就是限制開發者的寫法,這也是為什麼 taro 對 JSX 的寫法做出了諸多限制。這一點直接導致了無窮盡的維護成本和嚴重受損的開發體驗,而後 taro/next 也轉向了運行時方案 + 靜態編譯優化的結合。


運行時方案
不謙虛的說,針對小程式的運行時方案應該是最早我在寫下 remax 第一個 issue 時[1]提出的。
通過 React Reconciler(類似於 Rax Driver)我們可以讓運行在小程式容器中的 React 不去直接操作 DOM,而是把操作的數據通過 setData 傳遞給小程式的 View 層映射到最後的界面上。
雖然 Remax、Rax 運行時、Taro Next 等幾種方案不盡相同,但是思路大同小異,就是利用小程式模板一定程度上的動態化能力 + 類 React 框架的 VirtualDOM 來進行渲染。當然這種做法相對於小程式原生的渲染方式存在一定的性能損耗。

 

 

                                                                                    remax 的支付寶端性能測試

在部分場景下,這種損耗是值得的。這些運行時框架也都在陸續通過允許關掉編譯產生的模板中的不用的屬性、部分靜態編譯、虛擬列表等方式來改進性能。
當然了,最後內嵌 Webview 仍然是一個方案。


作為業務技術團隊,我們該做什麼
上面介紹的都是針對某些具體的場景的一些解決方案,然而對於業務技術團隊來說,跨端的本質是提效。針對新的變化提出新的方案是一方面,更重要的如何讓這種提效真的長治久安,讓我們的提效不會變成從一個新方案跳到另外一個新方案。
讓我們重新看上面這張圖,可以確定的是,跨端的訴求和與之對應的方案仍然會處於頻繁的變化中,也不會出現一個解決所有跨端問題的方案。而其中相對不變的部分是值得我們為了長治久安必須要投入的。

 

 

 WebView & H5 Hybrid
WebView 可能是眾多容器中最為特殊的一個,雖然很難滿足部分場景對於性能和體驗的極致要求,但是會是最穩定、長期存在且得到支持的方案。
從開發效率和未來長期的維護演變來看,在能夠滿足性能體驗要求的前提下,Web 方案仍然是最優先應該考慮的。
同時,在 APP 的 WebView 容器上我們能做更多的工作,例如通過容器來提供一些端內的能力,結合 Native 能力實現的並行數據載入,頁面保活等等。


基礎建設
無論採用何種跨端方案,在哪個容器中,性能、穩定性、效能都是繞不開的三駕馬車。


性能
對於不同的方案往往存在不同的性能方案,上面我們也提到在小程式的運行時方案中就會有減少編譯模板產出的欄位這樣的優化。然而,其實除了這種特定方案的優化外,大部分優化手段是大同小異的:離線緩存、數據預取、快照、SSR、NSR 等等方案。
對於不同的端和容器,對於性能問題的度量和發現也應該是一致的,我們需要對頁面在不同端的性能究竟如何有明確的感知和橫向對比。
性能的端側建設(端能力、具體到某一個端的性能測算方案、性能打點等)可能需要根據不同的端、不同的跨端方案而不同。但性能的基礎建設(首屏標準、數據分析、基礎優化能力)在跨端中應該是相對穩定的。
在端側能力方面,ICBU 早期在 WEEX 性能優化時引入了並行載入的能力,通過 wh_prefetch 協議來使用容器的並行載入能力。而後在新的容器(WebView、瀏覽器)中,雖然底層能力存在差異,但仍然識別相同的協議。

 

 

 在數據採集和分析方面,我們通過統一跨端基礎庫,讓不同端不同技術方案可以在同樣的標準下分析、度量和對比。

 

 

 穩定性建設
在無線端我們常常把性能 & 穩定性並稱為 “高可用”,穩定性主要涵蓋的範圍包括灰度能力、業務監控、報警、錯誤監控、白屏檢測等等。
這些能力相比起來對具體端和跨端方案的依賴更少,除了在端側的數據採集邏輯稍有區別外其他建設部分相對也是比較穩定的。集團針對這些場景也存在一些跨端可用的方案、例如 iTrace 等。


工程基建
對於不同場景的跨端,雖然在方案上存在一定的差異,但是我們的工程基建是可以保持統一的。

  • 容器層提供統一的 API 和文檔能力

  • 統一的研發流程

  • 研發工具提供統一的抓包、debug 能力等

  • 一致的工具庫等等


這樣,當有新的容器或者方案出現時,我們只需要按照相應的能力進行對齊,就能讓我們上層的業務代碼和開發體驗維持相對穩定的狀態。

 

 

 業務邏輯跨端
相對來說,我們會發現在多種跨端方案的演化中,如何渲染、如何佈局等 UI 層面的變化要遠遠大於業務邏輯層面。甚至是小程式和 Flutter,其大致的開發範式都沒有發生太大的改變。例如 Flutter 開發範式和 React 非常相似,同樣是聲明式 UI,同樣存在 VirtualDOM。
考慮到 SEO 和性能等問題和 Flutter 本身基於 Skia 的渲染模式,Flutter for Web 在相當長一段時間內可能都不會是一個生產環境可用的方案。
而在統一了業務邏輯代碼的組織方式後,我們可以通過 Hooks for ALL 的方案讓 Flutter 和 Web 端可以共用一份基於 Hooks 的業務邏輯代碼。

 有時候你不需要真的 run everywhere,能夠提高效能、保持一致就已經達到目的了。


視圖層
目前來看視圖層的跨端仍然充滿了變數,在我們的業務邏輯層跨端做的足夠原子化後,也許我們部分交互邏輯不是特別重的視圖層能夠通過 DX + 綁定原子化邏輯 + 數據參數的方式覆蓋更多的跨端場景。從而同時滿足性能、效能方面的訴求。
然而對於通用場景的視圖跨端,仍然沒有銀彈。


總結
總體來說,跨端處於且將長期處於多方案並存且不斷變化的狀態。除了針對新的變化新的場景選擇或創造合適的方案,我們更要做好這種動態變化中長治久安的部分:

  • H5 Hybrid。

  • 性能、穩定性、效能三駕馬車的統一性和延續性。

  • 在不強求 write once 的場景下,考慮比 UI 跨端更簡單的業務邏輯跨端。

參考資料 [1]https://github.com/remaxjs/remax/issues/1

 

作者: 當軒

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/How-to-properly-cross-end.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 1.創建容器併進行持久化處理 #拉取鏡像 docker pull mysql:8.0.20 #啟動鏡像,用於拷貝配置文件到宿主機 docker run -p 3306:3306 --name mysql -e MYSQL_ROOT_PASSWORD=123456 -d mysql:8.0.20 #查 ...
  • 更多技術交流、求職機會,歡迎關註位元組跳動數據平臺微信公眾號,回覆【1】進入官方交流群 摘要 位元組數據中台DataLeap的Data Catalog系統通過接收MQ中的近實時消息來同步部分元數據。Apache Atlas對於實時消息的消費處理不滿足性能要求,內部使用Flink任務的處理方案在ToB場景 ...
  • 2022 年 9 月 16 日,由中國信息通信研究院(以下簡稱“信通院”)主辦的“2022 OSCAR 開源產業大會"活動於北京成功舉辦。會上宣佈,StoneDB 發起廠商杭州石原子科技有限公司正式加入信通院“科技製造開源社區(TMOSC)”,未來石原子將與信通院及各成員單位一起聚焦可信開源全景,推 ...
  • 本篇為Redis性能問題診斷系列的第四篇,也是最後一篇,主要從應用程式、系統、伺服器硬體及網路系統等層面上進行講解,重點分享了哪些配置需要重點關註和調整優化,才能最大程度的發揮Redis的處理能力; ...
  • 一.起步 1.1 配置uni-app開發環境 什麼是uni-app,就是基於vue的一個開發框架,可以將我們寫的一套代碼,同時發佈到ios、安卓、小程式等多個平臺 ==官方推薦使用Hbuilderx來寫uni-app項目== 下載之後可以將預設改為vscode 進入hbuilder插件市場下載scs ...
  • 前端技術的發展不斷融入了很多後端的思想,逐步形成前端的 ”四個現代化“:工程化、模塊化、規範化、流程化。這個主題介紹 *模塊化* ,主要內容包括模塊化前傳(早期模塊化的實現)、模塊化的四個規範(Common JS、AMD、CMD、ESM)。本文就聊聊早期的模塊化。 ...
  • 現在的很多程式應用,基本上都是需要多端覆蓋,因此基於一個Web API的後端介面,來構建多端應用,如微信、H5、APP、WInForm、BS的Web管理端等都是常見的應用。本篇隨筆繼續分析總結一下項目開發的經驗,針對頁面組件化開發經驗方面進行一些梳理總結,內容包括組件的概念介紹,簡單頁面組件的抽取開... ...
  • 每日3題 1 以下代碼執行後,控制臺中的輸出內容為? // index.js console.log(1); import { sum } from "./sum.js"; console.log(sum(1, 2)); //sum.js console.log(2); export const s ...
一周排行
    -Advertisement-
    Play Games
  • 人臉識別技術在現代社會中扮演著越來越重要的角色,比如人臉識別門禁、人臉識別支付、甚至人臉識別網站登錄等。 最近有群友問.NET有沒有人臉識別的組件,小編查閱相關資料介紹下麵幾種.NET人臉識別組件供大家參考。 **1、Microsoft Azure Face API** 簡介:Microsoft A ...
  • # 1. 與 .NET Core 緩存的關係和差異 ABP 框架中的緩存系統核心包是 [Volo.Abp.Caching](https://www.nuget.org/packages/Volo.Abp.Caching) ,而對於分散式緩存的支持,abp 官方提供了基於 Redis 的方案,需要安裝 ...
  • 最近ET做熱更重載dll的時候,返回登陸會重新檢測新的dll,首次登錄之前已經Assembly.Load()過一次dll,第二次返回登陸再次load dll到記憶體中,Invoke執行方法的時候,異常了,有些方法執行了,有些未執行,於是查資料,看到些老資料說Assembly.Load重覆載入同名dll ...
  • 1. 擴展方法 擴展方法使你能夠向現有類型“添加”方法,而無需創建新的派生類型、重新編譯或以其他方式修改原始類型。 擴展方法是一種靜態方法,但可以像擴展類型上的實例方法一樣進行調用。 對於用 C#、F# 和 Visual Basic 編寫的客戶端代碼,調用擴展方法與調用在類型中定義的方法沒有明顯區別 ...
  • 以前在隨筆《Winform開發框架之客戶關係管理系統(CRM)的開發總結系列1-界面功能展示 》的幾篇隨筆中介紹過基於WInform開發框架開發的CRM系統,系統的功能主要也是圍繞著客戶相關信息來進行管理的。本篇隨筆介紹在最新的《SqlSugar開發框架》中整合CRM系統模塊的功能。 ...
  • 隨著技術的發展,ASP.NET Core MVC也推出了好長時間,經過不斷的版本更新迭代,已經越來越完善,本系列文章主要講解ASP.NET Core MVC開發B/S系統過程中所涉及到的相關內容,適用於初學者,在校畢業生,或其他想從事ASP.NET Core MVC 系統開發的人員。 經過前幾篇文章... ...
  • [toc] 這篇文章是我之前總結的一篇文章,因為整理博客的原因,原有博客已經註銷,但這篇文章對一些讀者很有用,所以現在新瓶裝舊酒重新整理回來分享給大家。 最近一段時間生產環境頻繁出問題,每次都會生成一個hs_err_pid*.log文件,因為工作內容的原因,在此之前並沒有瞭解過相關內容,趁此機會學習 ...
  • # 前言 在上一篇文章中,給大家講解了泛型的概念、作用、使用場景,以及泛型集合、泛型介面和泛型類的用法,但受限於篇幅,並沒有把泛型的內容講解完畢。所以今天我們會繼續學習泛型方法、泛型擦除,以及通配符等的內容,希望大家繼續做好學習的準備哦。 *** 全文大約【**4600】** 字,不說廢話,只講可以 ...
  • 昨天遇到參數key大小寫不一致導致校驗簽名失敗的問題,查了很長時間才找到原因。看了一下FastJson源碼,發現JSON.toObject中轉換成對象的時候會忽略大小寫。 所以,當使用了JSON.toObject將json轉成Java對象後,再用JSON.toObject轉成json,key值就變了 ...
  • 基於java的線上商城設計與實現,線上購物平臺,校園購物商城,商品銷售平臺,基於Java的電商平臺;電商平臺,買家和賣家可以在此平臺上進行銷售和交易,節約了大量的線下時間成本,購物車的功能,校園交易平臺等等; ...