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