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

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

“ web-view是一(yi)個(ge)可(ke)以(yi)(yi)用來承(cheng)載網(wang)頁(ye)的(de)容(rong)器，會自(zi)動鋪(pu)滿整個(ge)小(xiao)程序頁(ye)面”，也就是說(shuo)，微信小(xiao)程序中可(ke)以(yi)(yi)直(zhi)(zhi)接運行web頁(ye)了。大膽(dan)猜想(xiang)，這一(yi)功能，可(ke)能直(zhi)(zhi)接導致小(xiao)程序數量增(zeng)長迎來一(yi)波(bo)高(gao)峰。畢竟磨刀(dao)霍(huo)霍(huo)卻(que)一(yi)直(zhi)(zhi)資源(yuan)不足的(de)團隊應(ying)該不少，現(xian)在可(ke)以(yi)(yi)把已(yi)有H5應(ying)用嵌入(ru)到(dao)小(xiao)程序webview容(rong)器中，以(yi)(yi)最低的(de)開(kai)發成本坐(zuo)蹭微信流量紅(hong)利(li)，何(he)樂而不為(wei)呢？

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

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

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

• 小程序頁(ye)面跳(tiao)轉軌(gui)跡和 web -view中web頁(ye)跳(tiao)轉軌(gui)跡會(hui)被連貫記錄，包括(kuo)hashchange；

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

• 經測試內(nei)嵌(qian)M頁調(diao)起(qi)轉轉APP正常；

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

從以上結果來看，僅(jin)以小程序 web-view組件為容(rong)器，遷(qian)移已有web應用到(dao)小程序中的方案(an)應該可行(xing)，包括(kuo)基于(yu)hash路由(you)的SPA。

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

以往的小程序開發體驗

過去(qu)幾(ji)個月筆(bi)者(zhe)一直在參(can)與小程(cheng)序項目，從個人觀點來說，之前小程(cheng)序的開發體驗還有(you)很大(da)提升(sheng)空(kong)間。

• 首先小程序推(tui)出時間不長，穩定(ding)性還不是(shi)特別(bie)理想(xiang)；

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

• 最重要一點(dian)是之前(qian)小程序(xu)組件化(hua)機制(zhi)不完(wan)善，代(dai)碼復(fu)用(yong)相(xiang)對困(kun)難。而(er)對于我(wo)們團隊并(bing)行開發(fa)多個(ge)小程序(xu)且功(gong)能復(fu)用(yong)頻繁的情況，高(gao)效的代(dai)碼復(fu)用(yong)方案又極為(wei)重要；

針對代碼復用問(wen)題，我們(men)選用了 wepy框架(jia)解決(jue)。  wepy提供了系(xi)統(tong)的組(zu)(zu)(zu)件(jian)化開(kai)發(fa)(fa)方(fang)案，類似Vue語(yu)法(fa)，支(zhi)持(chi)npm引(yin)用，能夠方(fang)便的引(yin)入ES6語(yu)法(fa)，CSS預處理器，打包(bao)過(guo)程支(zhi)持(chi)插(cha)件(jian)化擴展(zhan)。整體來說，wepy極(ji)大地提高了小(xiao)(xiao)程序組(zu)(zu)(zu)件(jian)化開(kai)發(fa)(fa)體驗(yan)，但是(shi)在具體組(zu)(zu)(zu)件(jian)開(kai)發(fa)(fa)中(zhong)，我們(men)也(ye)遇到了一些問(wen)題。由于小(xiao)(xiao)程序不(bu)支(zhi)持(chi)動態模板(ban)，且小(xiao)(xiao)程序的視圖(tu)更新只能基于  page data中(zhong)掛載的數據，這些與web開(kai)發(fa)(fa)不(bu)同(tong)的地方(fang)必然會對框架(jia)設計(ji)有(you)所限制(zhi)，在實際開(kai)發(fa)(fa)中(zhong)，對 slot模板(ban)片(pian)段，嵌(qian)套(tao)組(zu)(zu)(zu)件(jian)間(jian)  computed數據同(tong)步等(deng)復雜(za)組(zu)(zu)(zu)件(jian)應用上體驗(yan)還是(shi)有(you)些缺陷。

好(hao)在(zai)從(cong)基礎庫SDK v1.6.3開始(shi)，小程序新(xin)(xin)增(zeng)了  Component 構造器 ，開始(shi)原生支持自定(ding)義組(zu)件(jian)(jian)開發。正當筆者(zhe)還在(zai)想 wepy等(deng)以往的(de)組(zu)件(jian)(jian)化框架是(shi)不是(shi)會(hui)逐漸過(guo)渡(du)到基于  Component 構造器 時，發現蘑(mo)菇(gu)街團隊已(yi)經高效(xiao)的(de)開源了基于 Component的(de)組(zu)件(jian)(jian)化方案(an)  Min，Min采用單文(wen)件(jian)(jian)的(de)方式(shi)來開發組(zu)件(jian)(jian), 在(zai)單文(wen)件(jian)(jian)編譯環節提(ti)(ti)供了CSS預(yu)處(chu)理器等(deng)一(yi)些額(e)外的(de)賦(fu)能(neng)，同時也支持插件(jian)(jian)擴展。很(hen)期(qi)待(dai)新(xin)(xin)版基礎庫覆蓋率足夠高后，能(neng)夠嘗(chang)試 Component構造器的(de)組(zu)件(jian)(jian)化方案(an)，相信開發體驗一(yi)定(ding)會(hui)大有提(ti)(ti)升。

未來的混合開發需求

小(xiao)程(cheng)(cheng)序(xu)隔離了(le)JSCore和(he)webview渲染內(nei)核，通(tong)過中間層(ceng)數據傳輸接(jie)口異步的將數據從JS邏輯層(ceng)發(fa)送到視圖層(ceng)；這使(shi)得(de)(de)(de)微(wei)信可以更(geng)好(hao)的對小(xiao)程(cheng)(cheng)序(xu)數據傳遞和(he)響(xiang)應時間等做監(jian)控，但在渲染性能(neng)和(he)開發(fa)體驗方面并未明(ming)顯(xian)優(you)于web開發(fa)。同時，2M代碼限制(zhi)也使(shi)得(de)(de)(de)像(xiang)(xiang)“轉轉官(guan)方”這樣已經2000+KB的小(xiao)程(cheng)(cheng)序(xu)必須考慮引(yin)入web內(nei)容(rong)，再有就(jiu)是小(xiao)程(cheng)(cheng)序(xu)審核發(fa)布機(ji)制(zhi)使(shi)得(de)(de)(de)它終究不能(neng)像(xiang)(xiang)web一樣迭代迅速。綜上(shang)，也許“小(xiao)程(cheng)(cheng)序(xu)頁(ye)面+web頁(ye)”混合開發(fa)（甚(shen)至web更(geng)重）會(hui)成為以后的新趨(qu)勢。

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

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

• 從小程(cheng)序(xu)頁(ye)(ye)面新開一個web頁(ye)(ye)：可以把攜帶數據的(de)url動態賦(fu)值給 <web-view/> .src 屬(shu)性(xing)(xing)實現(xian)數據傳遞。這里有一點要(yao)說明(ming)， <web-view/>.src屬(shu)性(xing)(xing)是一個單(dan)向傳遞的(de)數據， &nbsp;web -view內的(de)url變更并(bing)不能(neng)反饋到src屬(shu)性(xing)(xing)值中(zhong)；

而對于回退到上一頁(ye)(ye)(ye)面(mian)需(xu)要攜帶(dai)數據(ju)(ju)的(de)(de)場(chang)景(jing)，目前(qian)能(neng)(neng)想到的(de)(de)通(tong)信方式(shi)(shi)只有通(tong)過服務(wu)端中轉，在(zai)回退到的(de)(de)頁(ye)(ye)(ye)面(mian) onShow鉤子中拉新(xin)數據(ju)(ju)；因為  navigateBack或(huo)者  wx .miniProgram .navigateBack等方法(fa)并(bing)沒有能(neng)(neng)夠(gou)攜帶(dai)跨頁(ye)(ye)(ye)面(mian)數據(ju)(ju)的(de)(de)參數。在(zai)之(zhi)前(qian)的(de)(de)小程(cheng)序(xu)頁(ye)(ye)(ye)面(mian)開(kai)發中，兩個小程(cheng)序(xu)頁(ye)(ye)(ye)面(mian)的(de)(de)返回場(chang)景(jing)下我(wo)們可以在(zai)  A 頁(ye)(ye)(ye)面(mian) 中把數據(ju)(ju)存入 storage或(huo)者js模塊，返回  B 頁(ye)(ye)(ye)面(mian)后在(zai) onShow中獲取數據(ju)(ju)。而混合模式(shi)(shi)下  web -view組(zu)件(jian)環(huan)境中  localstorage和(he)(he)小程(cheng)序(xu)  storage并(bing)不(bu)共用(yong)存儲(chu)空間，  web -view中JS執行(xing)引擎(qing)和(he)(he)小程(cheng)序(xu)頁(ye)(ye)(ye)面(mian)的(de)(de)JSCore環(huan)境也不(bu)能(neng)(neng)共享JS模塊。

期待

展望未(wei)來的(de)小程序功能(neng)升級(ji)，筆者最期(qi)待(dai)的(de)大概有兩點(dian)：

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

• 支持打包部分web靜態(tai)資源到小程(cheng)序包中(zhong)，并可(ke)在(zai) ;web -view內嵌網頁中(zhong)本(ben)地加載。

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