作者簡介
思語，攜程高級(jí)前端開發(fā)工程師，關(guān)注互動(dòng)營銷領(lǐng)域；
Olivio，攜程高級(jí)前端開發(fā)工程師，關(guān)注React Node 組件化；
Stone，攜程高級(jí)研發(fā)經(jīng)理，關(guān)注跨端解決方案，云原生落地等領(lǐng)域。
一、背景
這篇文章將向大家分享團(tuán)隊(duì)在小程序 webview 方面的開發(fā)心得，以微信小程序?yàn)橹饕h(huán)境，介紹在業(yè)務(wù)開發(fā)中處理小程序webview內(nèi)嵌H5所遇到的問題及解決方案。具體將從小程序平臺(tái)與H5差異、小程序內(nèi)嵌webview通信、小程序webview常見問題展開敘述。
二、平臺(tái)差異
下面將淺析并回顧一下小程序和H5在渲染方面的幾點(diǎn)差異。
2.1 小程序方面
以微信小程序?yàn)槔?，相信今天大部分的讀者對(duì)微信小程序的系統(tǒng)架構(gòu)都比較熟悉了，總體來講分為兩部分：
- iew 視圖端通過小程序的框架，將用戶采用 WXML 和 WXSS 描述的UI信息處理成 H5 元素，最終交給 WebView 去渲染；
- 邏輯層運(yùn)行JS邏輯，并且可以調(diào)用具有微信開放能力的 JSAPI。邏輯和視圖分離，通過事件和數(shù)據(jù)彼此之間建立聯(lián)系。
微信小程序使用 WebView 渲染，與原生客戶端的是兩套不同的視圖渲染體系。一個(gè)小程序存在多個(gè)界面，所以渲染層存在多個(gè) WebView。邏輯層采用 JSCore 線程運(yùn)行 JAVAScript 腳本。這兩個(gè)線程間的通信經(jīng)由小程序 Native 側(cè)中轉(zhuǎn)，邏輯層發(fā)送網(wǎng)絡(luò)請(qǐng)求也經(jīng)由 Native 側(cè)轉(zhuǎn)發(fā)。
如此設(shè)計(jì)的初衷是為了管控和安全，微信小程序阻止開發(fā)者使用一些瀏覽器提供的，諸如跳轉(zhuǎn)頁面、操作 DOM、動(dòng)態(tài)執(zhí)行腳本的開放性接口。將邏輯層與視圖層進(jìn)行分離，視圖層和邏輯層之間只有數(shù)據(jù)的通信，可以防止開發(fā)者隨意操作界面，更好地保證了用戶數(shù)據(jù)安全。同時(shí)小程序設(shè)計(jì)一套組件框架—— Exparser ，基于這個(gè)框架內(nèi)置了一套組件，以涵蓋小程序的基礎(chǔ)功能，便于開發(fā)者快速搭建出任何界面，同時(shí)也提供了自定義組件的能力，開發(fā)者可以自行擴(kuò)展更多的組件，以實(shí)現(xiàn)代碼復(fù)用。
值得一提的是，內(nèi)置組件有一部分較復(fù)雜組件是用客戶端原生渲染的，同時(shí)微信團(tuán)隊(duì)又通過結(jié)合 Flutter 和 LV-CPP，把實(shí)現(xiàn)代碼收斂在 C++ 和 Dart 上，進(jìn)一步簡化了基于小程序技術(shù)棧實(shí)現(xiàn)跨平臺(tái)業(yè)務(wù)開發(fā)的框架維護(hù)成本，以提供更好的性能。
2.2 小程序WebView內(nèi)嵌H5
H5頁面投放在小程序WebView，在配置完合法域名后，即可在小程序應(yīng)用中展示。那么，針對(duì)不同廠商小程序，可能法務(wù)、廠商合規(guī)有所差異，需要H5判斷所在的環(huán)境，去調(diào)用不同 api 方法，展示不同的業(yè)務(wù)頁面。
在攜程內(nèi)部封裝了小程序CWX的SDK，小程序端主要采用原生+Taro框架，H5這塊主要是NFES(React)和Vue，無論是哪一段端都通過一個(gè)CWX來連接，內(nèi)部封裝了各端通用的功能比如登錄、發(fā)布、支付、個(gè)人中心等功能，這些功能都可以直接通過CWX這個(gè)中間件進(jìn)行調(diào)用。
并且，H5在檢測(cè)到當(dāng)前處于小程序webview環(huán)境下時(shí)，會(huì)根據(jù)環(huán)境異步加載SDK文件、及其廠商的JS-SDK，初始化小程序版本wx.config。這里的關(guān)鍵點(diǎn)是我們要做個(gè)api調(diào)用的隊(duì)列，因?yàn)閟dk加載異步的過程，如果期間頁面內(nèi)發(fā)生了api調(diào)用，那肯定得不到正確的響應(yīng)。因此要做個(gè)調(diào)用隊(duì)列，當(dāng)sdk初始化完畢之后再處理這些調(diào)用。其實(shí)CWX原理很純粹，如果你想實(shí)現(xiàn)多端適配，那么只需要根據(jù)所在的環(huán)境去加載不同的sdk就可以了。
> 下面簡要列舉一下工作中常用的幾個(gè)小程序環(huán)境判斷：
使用時(shí)的注意事項(xiàng)：
使用前，最好查閱相應(yīng)小程序的文檔，因?yàn)楦鱾€(gè)小程序?qū)PI的支持程度不同。引用bridge.js的方式視情況而定，因?yàn)?bridge.js 引入JSSDK的方式是 為 head標(biāo)簽添加 script標(biāo)簽，若在 head標(biāo)簽中引入bridge.js，就會(huì)報(bào)錯(cuò)若打開h5，顯示“頁面訪問受限”之類的提示信息，可嘗試下方的操作：（這種情況，一般是打開測(cè)試環(huán)境的h5 url 時(shí)出現(xiàn)）勾選IDE中的“忽略webview域名合法性檢查” 和 “忽略request域名合法性檢查”。
【快應(yīng)用相關(guān)】
目前Vivo、Oppo、華為三家廠商已支持新版快應(yīng)用，Vivo、OPPO已上線，華為正在測(cè)試中，小米不支持。對(duì)于新版快應(yīng)用，若H5頁面需要調(diào)用新版快應(yīng)用JS-SDK中提供的API，需要提前將該H5鏈接的域名配置到可信任的網(wǎng)址里（應(yīng)寫成正則表達(dá)式的形式進(jìn)行配置）。
【頭條相關(guān)】
頭條小程序的redirectTo、navigateTo 等頁面跳轉(zhuǎn)的 api 只支持 url 為 / 開始的絕對(duì)路徑。
【支付寶相關(guān)】
目前的1.0.73版 bridge.js 判斷是否處于支付寶小程序的方法，會(huì)將h5處于支付寶小程序、h5處于支付寶內(nèi)置瀏覽器都判斷為處于支付寶小程序內(nèi)。因此，在調(diào)my.XXXX之前，需要先調(diào)環(huán)境工具函數(shù)判斷一下，確保確實(shí)是處于支付寶小程序內(nèi)，而非支付寶內(nèi)置瀏覽器內(nèi)。
三、小程序內(nèi)嵌WebView通信
3.1 小程序中h5頁面onShow和跨頁面通信的實(shí)現(xiàn)
首先想到的是onShow方法的實(shí)現(xiàn)，之前有人提議用visibilitychange來實(shí)現(xiàn)onShow方法，但調(diào)研過后，發(fā)現(xiàn)這種方式在IOS中表現(xiàn)符合預(yù)期，但是在Android/ target=_blank class=infotextkey>安卓手機(jī)里，是不能按預(yù)期觸發(fā)的。
于是就有了下面的方案，這個(gè)方案需要h5和小程序的webview都做處理。核心思想：利用webview的hash特性。
- 小程序通過hash傳參，頁面不會(huì)更新（這個(gè)和瀏覽器一樣）
- h5可以通過hashchange捕獲最新參數(shù)，進(jìn)行自定義邏輯處理
- 最后執(zhí)行window.history.go(-1)
為什么要執(zhí)行window.history.go(-1) ? 因?yàn)閔ash變更會(huì)導(dǎo)致webview歷史棧長度+1，用戶需要多一次返回操作。但這一步明顯是多余的。同時(shí)window.history.go(-1)后，會(huì)把webview在hash中添加的參數(shù)去掉，還能保證和之前的url一致。
3.2 注意點(diǎn)
出于平滑接入的考慮，不能上來搞一刀切，要保證現(xiàn)有頁面不再做任何修改的情況下繼續(xù)訪問。新能力要通過額外參數(shù)區(qū)分，如：檢測(cè)url中的query部分，帶有 __isnotallow=1 再進(jìn)行通過hash方式傳參。改造原有邏輯，讓__isnotallow=1時(shí)，hash處理邏輯優(yōu)先級(jí)最高參數(shù)定義，在前面加入了兩個(gè)下劃線，目的是為了區(qū)分url中正常的參數(shù)。我們來看看h5端的sdk是怎么實(shí)現(xiàn)的。
總結(jié)下來是兩點(diǎn)：
- onShow方法的實(shí)現(xiàn)
綁定一個(gè)hashchange事件（這里做了防止重復(fù)綁定事件的處理），將傳入的onShow自定義事件緩存在一個(gè)數(shù)組中，hashchange觸發(fā)時(shí)，根據(jù)特有的標(biāo)志位__isonshow和__wachangehash確定是否觸發(fā)。
- serviceDone方法的實(shí)現(xiàn)
觸發(fā)條件：immediately表示最近的一次onShow觸發(fā)，或者自己指定url通過wx.miniProgram.postMessage發(fā)送數(shù)據(jù)。
瀏覽器訪問資源是通過 URL 地址，如果內(nèi)嵌 H5 的地址不發(fā)生變化，那么 web-view 訪問資源會(huì)從緩存里取，而緩存里并沒有最新的數(shù)據(jù)，這就導(dǎo)致了服務(wù)端的最新資源根本無法到達(dá)瀏覽器，這也解釋了為什么修改 Nginx 的 Cache-Control 配置也無法生效的原因。
所以，要想徹底解決及時(shí)刷新，必須讓 web-view 去訪問新的地址。我們假定小程序訪問的 URL 地址為：??https://www.yourdomain.com/101/#/index?? ，其中 101 就是構(gòu)建的一個(gè)版本號(hào)，每次遞增，保證次次不同即可。
四、WebView常見難題與解決方案
小程序和h5 之間的通信基本上常用兩種方式，一個(gè)是postMessage，這個(gè)方法大家都知道，只有在三種情況才可以觸發(fā)，后退、銷毀和分享。但也有個(gè)問題，就是需要注意這個(gè)方法是基礎(chǔ)庫1.7.1才開始支持的，1.7.1以下就只能通過第二種方法來傳遞數(shù)據(jù)，也就是設(shè)置和檢測(cè)webview組件的url變化，類似pc時(shí)代的iframe的通信方式。
sdk這塊怎么做呢，定義一個(gè)share方法，首先需要檢測(cè)下基礎(chǔ)庫版本，看是否支持postMessage，如果支持直接調(diào)用，如果不支持，把分享參數(shù)拼接到url當(dāng)中，然后進(jìn)行一次重載。也就是說，通過url傳遞數(shù)據(jù)有個(gè)缺點(diǎn)，就是頁面可能需要刷新一次才能設(shè)置成功。
目前在webview環(huán)境下支持支持的幾種通用業(yè)務(wù)：
4.1 左上角返回
在訪問小程序webview頁面時(shí)，首先進(jìn)入的是一個(gè)空白的中轉(zhuǎn)頁，然后進(jìn)入h5頁面，這樣左上角就會(huì)出現(xiàn)返回按鈕了，當(dāng)用戶按左上角的返回按鈕時(shí)候，頁面會(huì)被重載到小程序首頁去，這個(gè)看似簡單又微小的動(dòng)作，對(duì)業(yè)務(wù)其實(shí)有很大的影響。
經(jīng)過我們的數(shù)據(jù)統(tǒng)計(jì)發(fā)現(xiàn)，左上角返回按鈕點(diǎn)擊率高達(dá)70%以上，因?yàn)檫@種落地頁一般是被用戶分享出來的，以前純h5的時(shí)候只能通過左上角返回，所以在小程序里用戶也習(xí)慣如此；第二個(gè)數(shù)字，重載到首頁以后，后續(xù)頁面訪問率有10%以上，這兩個(gè)數(shù)字對(duì)業(yè)務(wù)提升其實(shí)蠻大的。其實(shí)現(xiàn)原理很簡單，都是通過第二次觸發(fā)onShow時(shí)進(jìn)行處理。
4.2 H5和小程序登錄態(tài)同步問題
分兩種情況，接入的H5可能一開始就需要登錄，也可能開始不需要登錄態(tài)中途需要登錄，這兩種情況我們約定了h5通過自己的url上一個(gè)參數(shù)進(jìn)行控制。
一開始就需要登錄態(tài)的情況，具體來講就是在加載webview之前，首先進(jìn)行授權(quán)登錄，然后把登錄信息拼接到url里面，再去來加載webview，在h5里面通過adapter來把登錄信息提取出來并且存到cookie里，這樣h5一進(jìn)來就是有登錄態(tài)的。
一開始不需要登錄態(tài)的情況，一進(jìn)入小程序就直接通過webview加載h5，h5調(diào)用login方法的時(shí)候，把needLogin這個(gè)參數(shù)拼接到url中，然后利用api進(jìn)行重載，就走了第一種情況進(jìn)行授權(quán)登錄了。
Q：可能出現(xiàn)的登錄同步問題
A: 跳到個(gè)人頁登錄完成，此時(shí)是新開的webview同步兩端登錄態(tài)，點(diǎn)返回，到上一個(gè)webview，此時(shí)這個(gè)webview嵌套的首頁，沒有觸發(fā)react-imvc onshow事件。這個(gè)頁面是老的，退出登錄也是一樣，所以在首頁會(huì)去跳h5的登錄而不是小程序登錄，導(dǎo)致登錄不同步。
解決思路：需要返回首頁刷一下h5頁面。
誤區(qū)：直接在個(gè)人登錄之后，relaunch到首頁，會(huì)導(dǎo)致沒有直接調(diào)用注銷webview把token置換，無法退出。
解決方案：判斷從個(gè)人頁返回的時(shí)候，設(shè)置webview的url加個(gè)參數(shù)，重新刷一下。
4.3 WebView分享
在沒接入websocket之前，小程序主要通過bind。首先通過bindmessage事件接收h5傳回來的數(shù)據(jù)，然后在用戶分享的時(shí)候onShareAppMessage判斷有沒有回傳的數(shù)據(jù)，如果沒有就到webviewurl當(dāng)中取，否則就是用默認(rèn)分享數(shù)據(jù)。
4.4 支付
1）WebView頁面刷新問題
因?yàn)樾〕绦騱ebview里面不支持直接調(diào)起微信支付，所以基本上需要支付的時(shí)候，都需要來到小程序里面，支付完再回去。上面做好了以后，在h5這塊調(diào)用一句話就可以了。
針對(duì)產(chǎn)品有大量內(nèi)嵌H5頁面的情況下，最好根據(jù)業(yè)務(wù)分兩種支付頁面，一是有的業(yè)務(wù)h5有自己完善的交易體系，下單動(dòng)作在h5里面就可以完成，他們只需要小程序付款，因此我們有一個(gè)精簡的支付頁，進(jìn)來直接就拉起微信支付。
還有一種情況是業(yè)務(wù)需要小程序提供完整的下單支付流程，通過直接進(jìn)入小程序的收銀臺(tái)來，圖上是sdk里面的基本邏輯，通過payOnly這個(gè)參數(shù)來決定進(jìn)到哪個(gè)頁面。再看下小程序里面精簡支付怎么實(shí)現(xiàn)的，onload之后直接調(diào)用api拉起微信支付，支付成功以后根據(jù)h5傳回來的參數(shù)，如果是個(gè)小程序頁面，直接跳轉(zhuǎn)過去，否則就刷新上一個(gè)webview頁面，然后返回回去。
新的問題與挑戰(zhàn)：webview返回上一頁數(shù)據(jù)刷新問題
有客戶反饋在A頁面點(diǎn)擊任務(wù)后跳轉(zhuǎn)到B頁面，待任務(wù)完成后，手機(jī)手勢(shì)左滑返回或點(diǎn)擊默認(rèn)導(dǎo)航欄的左上角返回，上一個(gè)頁面不會(huì)觸發(fā)任務(wù)的更新。原因是上一個(gè)頁面已經(jīng)初始化并沒有執(zhí)行重渲染，在APP環(huán)境下JSBridge 沒有提供偵聽手勢(shì)左滑返回、左上角物理返回的回調(diào)事件，且在小程序webview頁面也會(huì)遇到上述同樣的情況。
由于微信并沒有提供偵聽手勢(shì)左滑返回、左上角物理返回的，且webview頁面也不支持自定義導(dǎo)航欄，這導(dǎo)致下一個(gè)頁面觸發(fā)的新事件，在返回上個(gè)頁面時(shí) 無法做到針對(duì)性的更新。前期可以簡單粗暴地通過約定參數(shù) doRefreshWhileBack=true 作為options，來通過webview頁面每次onShow刷新頁面，但是刷新整個(gè)頁面的成本太大，且用戶體驗(yàn)不好。
2）引入WebSocket?
帶著這些疑問，我們進(jìn)行一系列的嘗試與試驗(yàn)，最終采用了 websocket 的方式，解決并封裝出我們市場(chǎng)業(yè)務(wù)的輕量的websocket服務(wù)，主要用于解決webview跨頁面通信和游戲方面的業(yè)務(wù)。
在這個(gè)過程中，我們總結(jié)出了一些經(jīng)驗(yàn)，希望能給從事相關(guān)研究的同學(xué)帶來一些幫助。上述做法是針對(duì)不同的應(yīng)用環(huán)境，分別使用或約定不同的api派發(fā)給各自的事件系統(tǒng)，從而解決頁面物理回退時(shí)頁面不主動(dòng)刷新的方案。
簡要介紹一下websocket，websocket標(biāo)準(zhǔn)誕生于2011年，RFC 文檔編號(hào)是 6455。TML 5 規(guī)范定義了 WebSocket 協(xié)議，它可以通過 HTTP 的端口（或者 HTTPS 的端口）來完成，從而最大程度上對(duì) HTTP 協(xié)議通透的防火墻保持友好。但是，它是真正的雙向、全雙工協(xié)議，也就是說，客戶端和服務(wù)端都可以主動(dòng)發(fā)起請(qǐng)求，回復(fù)響應(yīng)，而且兩邊的傳輸都互相獨(dú)立。和上文的 Comet 不同，WebSocket 的服務(wù)端推送是完全可以由服務(wù)端獨(dú)立、主動(dòng)發(fā)起的，因此它是服務(wù)端的"真 Push"。
WebSocket 是一個(gè)可謂"科班出身"的二進(jìn)制協(xié)議，也沒有那么大的頭部開銷，這樣就解決了接線員要反復(fù)解析HTTP協(xié)議，還要查看identity info的信息，因此它的傳輸效率更高。同時(shí)，和 HTTP 不一樣的是，它是一個(gè)帶有狀態(tài)的協(xié)議，雙方可以約定好一些狀態(tài)，而不用在傳輸?shù)倪^程中帶來帶去。而且，WebSocket 相比于 HTTP，它沒有同源的限制，服務(wù)端的地址可以完全和源頁面地址無關(guān)，即不會(huì)出現(xiàn)的瀏覽器"跨域問題"。
優(yōu)勢(shì)：?
- 消息實(shí)時(shí)：真正的雙向、全雙工協(xié)議，完全的服務(wù)端推送保證了數(shù)據(jù)的時(shí)效性。
- 通信高效：可以由客戶端和服務(wù)端主動(dòng)發(fā)送請(qǐng)求，不會(huì)像輪詢那樣產(chǎn)生大量無效傳輸報(bào)文。
- 協(xié)議支持：標(biāo)準(zhǔn)誕生較早，瀏覽器支持度高，且沒有同源策略的限制。
劣勢(shì)：
- 開發(fā)與維護(hù)成本：服務(wù)器長期維護(hù)長連接需要一定的成本，且受網(wǎng)絡(luò)限制比較大，需要處理好重連。
借助websocket的輔助，在小程序webview內(nèi)嵌H5的業(yè)務(wù)場(chǎng)景中，可做的事情就更多了。在市場(chǎng)的webview容器加載流程中。
3）WebSocket背景下的WebView通信實(shí)踐
小程序webview初始化并在onLoad階段通過 options.useMktsocket 判斷是否需要加載 socket，同時(shí)判斷應(yīng)用環(huán)境通過 wx.connectSocket api 連接不同的 socket 服務(wù)；
初始化webview socket服務(wù)，接受服務(wù)器消息-對(duì)服務(wù)器消息進(jìn)行甄別，如果H5頁面通過socket傳遞給webview容器的數(shù)據(jù)data格式符合預(yù)期，且H5環(huán)境下登錄態(tài)中的openId與小程序環(huán)境一致，則認(rèn)為此次通信合法；
webview容器中綁定了 小程序分享miniShare 、小程序訂閱openScribe、 健康檢查health等常用業(yè)務(wù)API，用于處理廣告、訂閱、任務(wù)更新等業(yè)務(wù)實(shí)時(shí)回調(diào)；H5業(yè)務(wù)可通過此接口設(shè)置觸發(fā)小程序原生頁面的一些原生功能，為上層業(yè)務(wù)提供服務(wù)。
H5頁面就可以通過 socket 通信更改并調(diào)用小程序的膠囊欄分享、通知webview容器頁面調(diào)用小程序廣告、也可以調(diào)用喚起小程序頁面中的分享組件面板、觸發(fā)左上角物理返回時(shí)及時(shí)通知H5頁面觸發(fā)回調(diào)等諸多業(yè)務(wù)；同時(shí)小程序容器頁面原生事件完成后（比如廣告、分享）再次通過socket返回給H5頁面的回調(diào)，實(shí)現(xiàn)小程序webview跨頁面的實(shí)時(shí)通信。
在websocket加持下，此時(shí)的小程序webview賦予了更多和H5通信的功能。
4.5 自定義分享面板
H5頁面可以通過 websocket 通信更改并調(diào)用小程序的分享參數(shù)，不再依賴于頁面options參數(shù)，可以調(diào)用在webview頁面封裝的分享面板，提供更加靈活的分享方式。
4.6 H5調(diào)用小程序原生的激勵(lì)廣告
H5頁面可以通過 WebSocket 通信調(diào)用小程序原生的激勵(lì)廣告。
4.7 任務(wù)體系中用戶任務(wù)組件狀態(tài)的更新
用戶在訪問加載了webview-h5的頁面會(huì)與websocket的server A服務(wù)器連接、小程序原生頁面與server B連接時(shí)，這兩個(gè)頁面因?yàn)樵诓煌娜萜飨拢詿o法通信和告知；但是只要這兩個(gè)頁面加載的是同一個(gè)市場(chǎng)的websocket服務(wù)，服務(wù)端可以設(shè)置共享一個(gè)redis，通過redis的發(fā)布訂閱功能，連通集群內(nèi)部各個(gè)機(jī)器，那么在頁面前進(jìn)、回退時(shí)都可以綁定對(duì)應(yīng)的回調(diào)事件，實(shí)現(xiàn)任務(wù)組件的靈活更新，給用戶展示最新的任務(wù)狀態(tài)。
五、總結(jié)
在處理小程序webview的業(yè)務(wù)方面，可以通過封裝一個(gè)包含各端環(huán)境的SDK，在H5初始化時(shí)加載，打通H5和小程序webview之間的通道，實(shí)現(xiàn)H5控制分享、登錄態(tài)同步、支付信息同步等功能。
在遇到跨頁面數(shù)據(jù)刷新問題時(shí)，借助了websocket這把利器，通過redix的發(fā)布訂閱通知鏈接了websocket服務(wù)器的頁面，實(shí)現(xiàn)小程序webview物理返回上一頁而數(shù)據(jù)不刷新的問題，同時(shí)websocket使得H5與webview的通信更加便捷靈活，拓展了H5調(diào)用小程序原生激勵(lì)廣告、封裝并調(diào)用小程序原生的分享面板等功能。
【參考文獻(xiàn)】
- 《WebSockets 教程》，鏈接：https://www.tutorialspoint.com/websockets/
