微信小程序去年剛推出內測，就刷屏了筆者朋友圈好幾天，而后來幾個月單從技術生態來看，并不像人們預期那般火熱。不過最近剛推出的web-view組件，算是再次引發了一波小高潮。

web-view組件中運行純web應用

“ web-view是一個可以用來承載網頁的容器，會自動鋪滿整個小程序頁面”，也就是說，微信小程序中可以直接運行web頁了。大膽猜想，這一功能，可能直接導致小程序數量增長迎來一波高峰。畢竟磨刀霍霍卻一直資源不足的團隊應該不少，現在可以把已有H5應用嵌入到小程序webview容器中，以最低的開發成本坐蹭微信流量紅利，何樂而不為呢？

對于 web-view組件，筆者做了些demo測試：

• 所測試的線上M頁功能未見異常，dom，bom操作API未被屏蔽；

• 頂部欄顯示M頁title，且優先級高于小程序頁面title；

• 小程序頁面跳轉軌跡和 web -view中web頁跳轉軌跡會被連貫記錄，包括hashchange；

• M頁間跳轉層級不受限，不同于小程序頁面最多5層的限制；

• 經測試內嵌M頁調起轉轉APP正常；

• web -view組件  src屬性支持動態賦值；

從以上結果來看，僅以小程序 web-view組件為容器，遷移已有web應用到小程序中的方案應該可行，包括基于hash路由的SPA。

還有一點值得注意，隨著 web-view組件推出，  Page .onShareAppMessage (options ) 函數參數中新增了 webViewUrl屬性值，當用戶調起轉發面板時，  options .webViewUrl返回  web -view組件中當前加載的  url，通過把  url添加到小程序頁面分享路徑中，可以變相實現轉發M頁到好友會話的功能。

以往的小程序開發體驗

過去幾個月筆者一直在參與小程序項目，從個人觀點來說，之前小程序的開發體驗還有很大提升空間。

• 首先小程序推出時間不長，穩定性還不是特別理想；

• 其次小程序與web同構的需求逐漸顯現，雖然 wepy、  mpVue等框架在嘗試從語法層面盡可能做到與  vue技術棧的web項目同構，但是兩端特性API兼容依舊是個棘手問題；好在現在  web -view組件的推出，一下使得同構問題不那么嚴峻了；

• 最重要一點是之前小程序組件化機制不完善，代碼復用相對困難。而對于我們團隊并行開發多個小程序且功能復用頻繁的情況，高效的代碼復用方案又極為重要；

針對代碼復用問題，我們選用了 wepy框架解決。  wepy提供了系統的組件化開發方案，類似Vue語法，支持npm引用，能夠方便的引入ES6語法，CSS預處理器，打包過程支持插件化擴展。整體來說，wepy極大地提高了小程序組件化開發體驗，但是在具體組件開發中，我們也遇到了一些問題。由于小程序不支持動態模板，且小程序的視圖更新只能基于  page data中掛載的數據，這些與web開發不同的地方必然會對框架設計有所限制，在實際開發中，對 slot模板片段，嵌套組件間  computed數據同步等復雜組件應用上體驗還是有些缺陷。

好在從基礎庫SDK v1.6.3開始，小程序新增了  Component 構造器 ，開始原生支持自定義組件開發。正當筆者還在想 wepy等以往的組件化框架是不是會逐漸過渡到基于  Component 構造器 時，發現蘑菇街團隊已經高效的開源了基于 Component的組件化方案  Min，Min采用單文件的方式來開發組件, 在單文件編譯環節提供了CSS預處理器等一些額外的賦能，同時也支持插件擴展。很期待新版基礎庫覆蓋率足夠高后，能夠嘗試 Component構造器的組件化方案，相信開發體驗一定會大有提升。

未來的混合開發需求

小程序隔離了JSCore和webview渲染內核，通過中間層數據傳輸接口異步的將數據從JS邏輯層發送到視圖層；這使得微信可以更好的對小程序數據傳遞和響應時間等做監控，但在渲染性能和開發體驗方面并未明顯優于web開發。同時，2M代碼限制也使得像“轉轉官方”這樣已經2000+KB的小程序必須考慮引入web內容，再有就是小程序審核發布機制使得它終究不能像web一樣迭代迅速。綜上，也許“小程序頁面+web頁”混合開發（甚至web更重）會成為以后的新趨勢。

考慮混合開發，必然會遇到“web-view網頁與小程序頁面通信”的場景，而現在兩者之間不支持除JSSDK提供的接口之外的通信。

• 從web頁新開一個小程序頁面: 可使用 wx .miniProgram .navigateTo等幾個跳轉接口，通過path參數攜帶數據跨頁面；

• 從小程序頁面新開一個web頁：可以把攜帶數據的url動態賦值給 <web-view/> .src 屬性實現數據傳遞。這里有一點要說明， <web-view/>.src屬性是一個單向傳遞的數據，  web -view內的url變更并不能反饋到src屬性值中；

而對于回退到上一頁面需要攜帶數據的場景，目前能想到的通信方式只有通過服務端中轉，在回退到的頁面 onShow鉤子中拉新數據；因為  navigateBack或者  wx .miniProgram .navigateBack等方法并沒有能夠攜帶跨頁面數據的參數。在之前的小程序頁面開發中，兩個小程序頁面的返回場景下我們可以在  A 頁面 中把數據存入 storage或者js模塊，返回  B 頁面后在 onShow中獲取數據。而混合模式下  web -view組件環境中  localstorage和小程序  storage并不共用存儲空間，  web -view中JS執行引擎和小程序頁面的JSCore環境也不能共享JS模塊。

期待

展望未來的小程序功能升級，筆者最期待的大概有兩點：

• 小程序頁面和 web -view頁面間的通信能有比較系統高效的接口支持；

• 支持打包部分web靜態資源到小程序包中，并可在 web -view內嵌網頁中本地加載。

總結來說，在筆者看來，最希望小程序的功能迭代能夠往“提供更高效、微信開放功能更強大的定制化webview容器”方向發展。盡可能減小web應用與小程序的同構成本，相信這對小程序開發生態甚至產品生態發展都有積極影響。