Mobile Bridge：讓 WebView 擁有原生體驗
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
前言 如何解決傳統 WebView 所面臨的三大核心問題 —— 性能、外觀和集成性，以及 Mobile Bridge 如何成為我們移動開發策略中的關鍵轉折點，甚至幫助我們加速向 React Native 的遷移。今日前端早讀課文章由 @Mauricio de Meirelles 分享，@飄飄編譯。
Shopify 的移動應用大約有 600 個界面，雖然這些界面都對商家使用移動端體驗有所貢獻，但并不是每個界面對日常操作都同樣重要。 對于那些關鍵界面，我們毫無疑問地選擇使用原生或 React Native 來開發，以確保提供最好的使用體驗。但如果將同樣的開發方式應用到其他不那么關鍵的界面上，代價就非常高昂，同時還會嚴重拖慢開發進度。 我們的挑戰很明確：我們需要一種高效的方式，把這些 “非關鍵” 界面集成到移動應用中，而不需要再為 Web 和移動端分別開發。 WebView 看起來是一個合理的選擇，但它往往難以提供良好的用戶體驗 —— 經常顯得慢、不流暢，而且跟原生界面風格不一致，容易讓人感覺脫節。 我們不滿足于這些限制，而是把它當作一次機會：我們是否能 “重塑” WebView，讓它更快、更美觀、看起來更像原生界面？這也正是我們創建 Mobile Bridge 框架的出發點。這個框架專門用來增強 WebView，讓網頁內容可以無縫融入我們的移動應用。 在這篇文章中，我們會分享我們是如何解決傳統 WebView 在性能、外觀和集成方面的主要問題，以及 Mobile Bridge 如何成為我們移動開發策略中的關鍵工具，甚至幫助我們加速向 React Native 的遷移。 WebView 的難題WebView 一直不被看好，主要是因為用戶一眼就能看出它不是 App 的原生部分。它們看起來脫節、運行緩慢，給人不好的使用體驗。
為了改善這些問題，我們啟動了一個項目，設定了三個關鍵目標：
1、讓 WebView 更快 ??我們首先著手找出 WebView 為什么加載緩慢。結果發現，主要問題出在認證流程上。每次加載 Web 頁面時，WebView 都要經過好幾次跳轉來完成身份驗證，這就導致了明顯的延遲。 為了解決這個問題，我們提出了一個簡單的方案：在應用啟動時，就在后臺預加載并完成 WebView 的身份認證。 為此，我們分別為 iOS 和 Android 構建了原生模塊，可以實現以下功能：
通過這種方式，我們將 WebView 的加載時間提升了大約 6 倍 ——P75（75% 用戶體驗到的加載時間）從 6 秒縮短到 1.4 秒，這其中包括了網絡延遲和頁面渲染時間。
左圖為優化前，右圖為優化后 2、讓 WebView 看起來更像原生界面在解決了性能問題之后，我們開始著手提升 WebView 的外觀和使用感受，重點是去除那些讓它看起來不像原生界面的元素。我們主要改進了以下幾個方面：
經過這些改進，我們的 WebView 在視覺風格和交互方式上更加接近原生界面，遵循了統一的用戶體驗設計標準。
優化前（左）與優化后（右）對比圖 3、讓 WebView 用起來更像原生界面想要讓 WebView 真正 “用起來像原生應用”，關鍵是要實現 Web 與移動端之間的簡單通信。它們需要能夠輕松地共享數據、追蹤用戶操作，并快速做出響應，比如知道用戶何時導航、完成了什么操作，或者頁面發生了哪些變化。 為此，我們開發了 Mobile Bridge 框架，它基于 Shopify 的 @remote-ui/rpc 庫，能夠在 Web 與移動端之間建立順暢的雙向通信通道。 解決頁面標題和操作問題 我們首先處理的是標題欄的問題。在原生應用中，頁面的標題和操作按鈕（如 “保存”、“編輯”）通常顯示在導航欄，而不是頁面本身。為了讓 WebView 與這一原生模式一致，我們在 Mobile Bridge 中設計了可以設置標題欄和操作按鈕的 API。 接著，我們修改了 Polaris 的 Page 組件，讓它將自己的標題和操作按鈕傳送給 Mobile Bridge，然后由 Mobile Bridge 將它們渲染到原生導航欄中。這樣一來，WebView 瞬間看起來更像原生界面了。
解決 WebView 中的導航問題 導航功能是另一個關鍵挑戰。在瀏覽器中，點擊鏈接通常會重新加載整個頁面，但原生應用則是將新頁面 “壓入” 導航堆棧中。如果我們每次導航都創建一個新的 WebView，就會導致用戶的會話數據和動態內容丟失，體驗既慢又令人沮喪。 為了解決這個問題，我們開發了一個名為 TransportableView 的新組件。它可以讓我們在屏幕之間 “移動” 現有的 WebView，而不丟失任何狀態或數據。TransportableView 可以把當前 WebView 實例直接轉移到另一個屏幕上使用，這樣即使用戶返回上一個頁面，也不會丟失任何內容或連接。 處理返回導航的問題 TransportableView 成功解決了 “前進導航” 的問題，因為我們總是在 WebView 進入新頁面時展示一個全屏加載動畫，用戶不會看到前一頁的內容短暫出現。 但如果是 “返回導航” 呢？如果不加處理，用戶在返回或預覽某些頁面時可能會看到空白或損壞的界面，這就破壞了我們想要實現的原生體驗。 為了解決這個問題，我們在 WebView 移動前會快速拍一張當前界面的 “快照”。當用戶返回時，先顯示這張靜態圖片，確保界面內容是完整的。等到實際的 WebView 完全加載好之后，我們再將這張快照移除。 iOS 上快照的捕捉與還原示意圖：
以原生方式處理彈窗（Modal） Web 頁面中的彈窗通常是覆蓋在當前內容之上的，而在移動應用中，彈窗通常作為獨立的屏幕出現，并伴隨原生的過渡動畫。為了與這一行為保持一致，我們將彈窗處理為原生屏幕，并通過和前文頁面跳轉相同的方式來傳遞 WebView。 其中一個關鍵優化是：我們對 Polaris 的 Modal 組件進行了自定義處理，讓它在原生動畫完成之后再開始渲染內容。這樣能保持過渡過程流暢，避免內容閃爍。
更進一步的優化 在做完上述優化后，我們的 WebView 已經有了巨大的提升，但我們并沒有就此止步。為了讓體驗更加無縫，我們還把已有的原生功能直接集成到了 WebView 中。 一個很好的例子就是日期選擇器（Date Picker）。我們的很多分析類頁面都采用 WebView，而日期選擇器是查看報表的重要交互。雖然 Web 上的日期選擇器在瀏覽器中運行良好，但在 App 里卻不夠 “原生”。既然我們已有原生版本的日期選擇器組件，我們就通過 Mobile Bridge 把它集成進 WebView。 這種將原生與 Web 元素融合的方式，讓用戶體驗變得更加自然、順暢。
優化前（左）與優化后（右）對比圖 我們還讓 WebView 可以無縫調用原生功能?，F在，Web 內容不僅能直接觸發原生界面，還能輕松地獲取返回結果。 在我們目前的應用中，已有一些實際應用場景，例如：
條碼掃描器（左）和添加到錢包功能（右） 這種混合式方案讓我們能夠快速推出基于 Web 的新功能，同時為用戶提供更豐富、更接近原生體驗的使用感受。 Mobile Bridge 的未來發展目前，Mobile Bridge 可以讓 Web 觸發原生界面元素，但這些原生元素必須事先在 App 中實現。這在一定程度上限制了發布速度，也讓舊版本的 App 無法享受到新功能的升級。 為了解決這個問題，我們正在嘗試使用 Shopify 的 remote-dom 技術，讓 Polaris 組件可以通過 Web 代碼在 App 中以原生方式渲染。 這種方式可以讓我們在保留業務邏輯在 Web 端的同時，把界面組件交由原生端渲染。這樣不僅帶來更大的靈活性，還顯著提升了整個混合應用的用戶體驗。 下面是我們基于這一方案構建的原型示例，你能猜出哪一部分是 WebView，哪一部分是原生的嗎？
Mobile Bridge：Shopify 的變革者Mobile Bridge 所帶來的改進是如此顯著，以至于 WebView 現在已經成為我們移動端開發戰略中不可或缺的一部分。我們大量使用 WebView 來實現重要但非關鍵的功能，從而避免在 Web 和移動端重復開發。 而對于應用中所有關鍵功能，我們仍然堅持使用原生或 React Native 來提供最優質的體驗。 我們已經將 Mobile Bridge 開源為一個獨立的庫，并開始將其整合進 Shopify 的其他產品中，比如 Balance、POS 和 Shop。這意味著更多應用也能采用這種強大的混合開發模式，從而享受到更快的開發周期和更好的用戶體驗。 Mobile Bridge 徹底改變了我們對 Web 與移動集成方式的看法 —— 它讓我們可以擁有 Web 開發的靈活性與速度，同時為用戶提供接近原生的流暢體驗。它還釋放了大量工程資源，讓我們能將更多精力投入到提升關鍵原生界面的質量上。 閱讀原文：原文鏈接 該文章在 2025/5/26 12:30:08 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
?
