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

前言

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)查閱，或在該帖子里留言。