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

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

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

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

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

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

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

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

  • 經(jīng)測試內(nèi)嵌M頁調(diào)起轉轉APP正常；

  • web-view 組件 src 屬性支持動態(tài)賦值；

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

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

以往的小程序開發(fā)體驗

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

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

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

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

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

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

未來的混合開發(fā)需求

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

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

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

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

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

期待

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

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

  • 支持打包部分web靜態(tài)資源到小程序包中，并可在 web-view 內(nèi)嵌網(wǎng)頁中本地加載。

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