微信小程序內嵌網頁的一些（最佳）實踐

前言

3 個月前，微信小程序推出了 web-view 組件引起了一波小高潮，筆者所在的大前端團隊寫過一篇淺析，詳情可見：淺談微信小程序前端生態。

咱們曾大膽猜測，這一功能，可能直接致使小程序數量增加迎來一波高峯。

畢竟磨刀霍霍卻一直資源不足的團隊應該很多，如今能夠把已有 H5 應用嵌入到小程序 web-view 容器中，以最低的開發成本坐蹭微信流量紅利，何樂而不爲呢？

咱們也曾暢想也許「小程序頁面+ web 頁」混合開發（甚至 web 更重）會成爲之後的新趨勢。

2M 代碼限制（現在已更新至 4M）使得像「轉轉官方」這樣功能繁複的小程序必須考慮引入 web 內容，再有就是小程序審覈發佈機制使得它終究不能像 web 同樣迭代迅速。

正好筆者所在的業務線，存在已有的 H5 應用卻無對應小程序的狀況。咱們在開發對應小程序時也算收穫了很多經驗（踩了很多坑），分享給有小程序需求的朋友們~

最大的坑：不支持服務通知

是的，web-view 不支持推送服務通知（或稱模板消息)。

如圖所示，相似訂閱號在對話列表的模式

爲何能稱爲最大的坑？咱們先了解一下服務通知，如下引用所有來自微信官方小程序文檔。

基於微信的通知渠道，咱們爲開發者提供了能夠高效觸達用戶的模板消息能力，以便實現服務閉環並提供更佳的體驗。

看起來很厲害，若是我們的小程序沒這個功能會怎樣？

1. 「用完即走」是小程序的口號，沒有服務通知表明失去了高效觸達（召回）用戶的能力，而後用戶就再也回不來了，促活和留存怎麼辦？

2. 不少功能不是像訂閱號裏看篇文章同樣，幾分鐘就能搞定的，好比絕大部分電商的行爲：從搜索、瀏覽比價、跟賣家交流，到加入購物車僅僅是走完了不到一半的生命週期；而後纔是下單支付評價，還不包括推薦復購取消退款等等，沒個15-30分鐘哪裏夠。然而，沒有用戶會一直開着某個小程序，別人還要切出去聊天刷朋友圈呢。沒有了化同步爲異步的能力，絕大部分產品邏輯如何實現服務閉環？

一篇教你突破小程序模板消息推送限制的文章中，也總結了服務通知的「多、快、好、省」等特色。這些先不展開，咱們還能看到：

1. 該小程序近 30 天訪問來源數據顯示，有 20% 左右的用戶經過模板消息進入小打卡，在各類來源中排名第 3 位（若是分母去掉新用戶的來源，比率和排名會更高）；

2. 何況，用戶基本都不會關閉微信的消息推送，相較 App 的推送和短信推送來講，小程序的推送觸達率會高不少。

so，沒有哪一個（正經的）小程序會不支持服務通知（流氓些的好比拼多多，看了個商品能給你連着推 N 條）。試想一下沒有推送通知的 APP，你的產品、運營和老闆們會贊成麼？

爲何不支持

然而，爲何 web-view 不支持服務通知？哪裏坑了？還請繼續看微信官方文檔裏的定義。

下發條件：用戶本人在微信體系內與頁面有交互行爲後觸發

總結起來就是，支付3條、提交表單（該表單需聲明爲要發模板消息）1條，7天有效。

1. 首先，這裏區別了支付和提交表單兩種行爲，要分不一樣的狀況上報，開始了看到沒…

2. 而後，web-view 不支持支付能力（其 JSAPI 能力不包含微信支付），這個在微信的文檔裏沒有顯式的聲明，不過能在微信的 web-view 問題彙總中看到，這個也挺坑的…

3. 其實，支付行爲對小程序自己而言只是極少數的交互，大多數小程序甚至不含支付。因此咱們基本還得靠表單，可問題就出在這：小程序的 web-view 和表單（form 組件） 不兼容！！！

PS：咱們先區分下 form 組件，它跟 web-view 內網頁的表單（form 標籤）沒有任何關係。

PS：RN 和 Weex 也沒有 form 組件。爲何筆者一看到 form 就想到以下的圖？

1999年12月發佈的 HTML 4.01 Specification 就支持了 form，自 AJAX 在2005年風靡世界後，跨域、文件上傳都有了 form 以外的解決方案，誰沒事還用這玩意？

先不吐槽微信文檔裏 form 組件的定義是有多簡陋，再看其 web-view 組件的定義~

web-view 組件是一個能夠用來承載網頁的容器，會自動鋪滿整個小程序頁面。

何止鋪滿，嘗試把 web-view 放在 form 組件內，form 組件都鋪沒了。so，自動鋪滿 = 頁面獨佔 = 全部其餘元素都被直接覆蓋…好吧，別人在文檔最下方的 Bug & Tip 裏寫了行小字~

綜上，web-view 跟服務通知已絕緣。so，小程序裏網頁的交互行爲不算在微信體系內！！？

我不由回想起 Google 以前推出的 PWA（Progressive Web App），在這又有那麼一絲神似。

1. 二者同是基於 Web 的技術，開發出（或許）可替代 APP 的僞原生應用；

2. PWA 的推送通知因其 API 太超前和一些不知名的服務被和諧用不了（你懂的）；

3. 小程序的服務通知嘛，你要想用 web-view 作殼就發佈上線也用不了。

扯遠了點，但你們都說：PWA 是引領下一代潮流的 Web 技術超集，而小程序是對 Web 技術進行修（閹割）補（Hack）的（黑）魔法…

不作展開，歡迎移步：如何客觀地評價「小程序」的體驗? Web 在繼續離咱們遠去

那怎麼辦？

因爲筆者團隊的業務對服務通知與支付有大量依賴，那麼咱們就要完全放棄 web-view，把以前的 H5 應用所有重寫至原生小程序了麼？顯然不是。

正如前文所說，支付僅是電商諸多環節中的一環，主要在商品 or 訂單詳情頁（這些必須重寫）。關於服務通知，經過幾個重寫後的原生小程序頁，也能收集到足夠的 form。

• 具體如何重寫，可參考咱們以前的像 Vue 同樣寫微信小程序-深刻研究 wepy 框架。雖然 wepy 框架嘗試從語法層面儘量作到與 vue 技術棧的 web 項目同構，可是兩端特性 API 兼容依舊是個棘手問題，並且畢竟二者的語法糖和生命週期函數都不同。這裏還有很多人工成本及學習與適應的過程，貼一個例子：

基於 wepy，模板部分就是個替換+適配的活，JS 麻煩些。離同構差距不小，美團您的 mpVue 呢？

• 具體如何收集，可參考教你突破小程序模板消息的推送限制這篇文章的作法。也如文章所說，通常你們都會在小程序頁中，**把全部能點擊的地方都換成 form。**若是以爲不夠簡單粗暴，也能在 form 中多層嵌套 form，而後讓點擊事件冒泡的方式來作！（誰讓此 form 非彼 form 呢…夠魔法麼…）

剩下的業務，理論上均可以用 web-view 來實現！！！運營活動頁就不說了，開放 web-view 能力最大的優點就是方便了這類需求。小程序首頁，甚至配置了 tabBar 的小程序頁均可以。由於咱們還發現一個神奇的 feature…

大概是用了原生的 UITabBar，web-view 和 tabBar 能共存

總結

虧了 web-view 組件的及時推出，咱們只需重寫部分詳情頁和其依賴的組件，最後覆盤一下。

1. 定位：小程序的 web-view 就像是 Hybrid 客戶端嵌 H5 頁同樣，須要一些基礎能力的時候，好比支付、服務通知（IM 和召回等場景）等等，最好使用原生小程序；

2. 兼容性：這個無須過多擔憂，最新的基礎庫統計數據，1.6.4+ 的覆蓋率已達 95% 以上；

3. 數據通訊：小程序 => web-view 能夠在 url 中用 search、hash 的方式，web-view => 小程序可用 bindmessage，通常用來解決分享信息傳遞的問題；

4. 登陸：a. web-view 內走微信受權，b. 小程序登陸後再進入 web-view，並把相關 cookie 經過 url 傳遞給 web-view。

其它 feature（歡迎討論和補充）：

1. web-view 跟小程序是獨立的兩個環境，數據徹底不通，包括 cookie、session、localStorage 等等；

2. 但小程序內嵌 web-view 跟微信內置瀏覽器是一套環境，也就是說你在 web-view 裏面留下的以上痕跡，到微信裏內置瀏覽器打開也有；

3. 在兩種環境下，不太容易區分究竟是什麼環境，小程序官方給的判斷方法是 window.__wxjs_environment === 'miniprogram'，可是在 web-view 進入第二頁時候，安卓機下這個變量就 undefined 了。

其它的坑（常見錯誤）：

1. 打開的域名沒有在小程序管理後臺設置業務域名(注意是業務域名，不是服務器域名)；

2. 打開的頁面 302 過去的地址也必須設置過業務域名；

3. 頁面能夠包含 iframe，可是 iframe 的地址必須爲業務域名；

4. 打開的頁面必須爲 https 服務；

5. 開發者本身檢查本身的 https 服務是否正常，測試方法：普通瀏覽器打開對應的地址； 等等，詳情請移步 web-view 問題彙總(https://developers.weixin.qq.com/blogdetail?action=get_post_info&lang=zh_CN&token=585555149&docid=ebfd9e5ec9986b4f23c41f8d8bbf2730)查閱，或在該帖子裏留言。