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

web-view組件中運(yùn)行純web應(yīng)用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而對于回退到上一頁面需要攜帶數(shù)據(jù)的場景，目前能想到的通信方式只有通過服務(wù)端中轉(zhuǎn)，在回退到的頁面 onShow 鉤子中拉新數(shù)據(jù)；因?yàn)?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模塊。

期待

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

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

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

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