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

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

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

對(duì)于 web-view組件，筆者做了些demo測(cè)試：

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

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

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

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

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

• web -view組件  src屬性支持動(dòng)態(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ā)面板時(shí)，  options .webViewUrl返回  web -view組件中當(dāng)前加載的  url，通過把  url添加到小程序頁面分享路徑中，可以變相實(shí)現(xiàn)轉(zhuǎn)發(fā)M頁到好友會(huì)話的功能。

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

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

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

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

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

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

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

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

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

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

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

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

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

期待

展望未來的小程序功能升級(jí)，筆者最期待的大概有兩點(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)成本，相信這對(duì)小程序開發(fā)生態(tài)甚至產(chǎn)品生態(tài)發(fā)展都有積極影響。