背景

飛(fei)豬對(dui)(dui)小(xiao)程序業(ye)(ye)務(wu)的(de)(de)嘗試(shi)(shi)是比較早的(de)(de)，隨著(zhu)支付寶小(xiao)程序的(de)(de)出現飛(fei)豬的(de)(de)各條(tiao)業(ye)(ye)務(wu)線都在不斷(duan)嘗試(shi)(shi)小(xiao)程序化(hua)以更好的(de)(de)在支付寶端獲客、觸(chu)達、留存(cun)，但(dan)是因(yin)為眾所周知(zhi)的(de)(de)原因(yin)飛(fei)豬一直沒(mei)有嘗試(shi)(shi)過微信小(xiao)程序。隨著(zhu)21年反壟斷(duan)的(de)(de)風越(yue)吹越(yue)盛，阿里(li)的(de)(de)一些業(ye)(ye)務(wu)開(kai)始在微信領域伸出了觸(chu)角，飛(fei)豬也隨勢而動嘗試(shi)(shi)開(kai)墾“微信小(xiao)程序”這塊(kuai)對(dui)(dui)我們(men)來說是“處(chu)女地”的(de)(de)地方。

從(cong)獲客角度來(lai)看，微(wei)信(xin)(xin)小程(cheng)(cheng)序是(shi)一塊十分適合旅(lv)行類(lei)業務(wu)的(de)(de)(de)土地。19年(nian)全國門(men)票(piao)的(de)(de)(de)線上購(gou)買率僅有20%，絕大部分的(de)(de)(de)游(you)客仍然(ran)是(shi)到景(jing)(jing)(jing)(jing)區(qu)后再購(gou)票(piao)，基于這(zhe)個實際場景(jing)(jing)(jing)(jing)各廠的(de)(de)(de)門(men)票(piao)業務(wu)均推出了“碼上游(you)”業務(wu)——通過將購(gou)票(piao)二維(wei)碼部署(shu)在(zai)(zai)景(jing)(jing)(jing)(jing)區(qu)的(de)(de)(de)方式獲取線下(xia)(xia)用戶。與門(men)票(piao)類(lei)似(si)，汽車(che)票(piao)也(ye)有線下(xia)(xia)自助機、上車(che)掃碼購(gou)票(piao)的(de)(de)(de)場景(jing)(jing)(jing)(jing)。而微(wei)信(xin)(xin)在(zai)(zai)“掃碼”場景(jing)(jing)(jing)(jing)的(de)(de)(de)打開率是(shi)其他app都(dou)難以(yi)望其項(xiang)背(bei)的(de)(de)(de)，這(zhe)種線下(xia)(xia)的(de)(de)(de)場景(jing)(jing)(jing)(jing)只需(xu)要我們能在(zai)(zai)微(wei)信(xin)(xin)小程(cheng)(cheng)序上保持存在(zai)(zai)就可以(yi)獲得立竿(gan)見影(ying)的(de)(de)(de)巨(ju)大業務(wu)收益。另外，基于微(wei)信(xin)(xin)巨(ju)大的(de)(de)(de)用戶、活(huo)躍的(de)(de)(de)社交場景(jing)(jing)(jing)(jing)、優秀(xiu)的(de)(de)(de)觸達能力，線上運營(ying)也(ye)有廣闊的(de)(de)(de)空間和豐富的(de)(de)(de)工具。

在21年我們上線了第一版(ban)搶占5.1窗口的僅含門(men)票(piao)業務的微信小程(cheng)序后，其(qi)他像度假(jia)、汽車票(piao)、酒店、火車票(piao)等業務也(ye)在源源不斷進入。隨(sui)著(zhu)項目的不斷迭(die)代、業務的快速發展，前(qian)端(duan)也(ye)面對著(zhu)從開發模式選型(xing)、集成管理(li)，到技術生態建(jian)設、性(xing)能優(you)化(hua)、體積優(you)化(hua)等各個方(fang)面的挑(tiao)戰。

技術建設

開發模式選型

技術棧

每個(ge)項目(mu)啟動之初技術(shu)都會面臨這個(ge)問題——如何選擇(ze)適(shi)合的(de)技術(shu)棧，飛(fei)(fei)豬微(wei)信(xin)小(xiao)程(cheng)序也不例外。一般(ban)選擇(ze)技術(shu)棧要看具體業務(wu)場(chang)景和項目(mu)核心訴(su)求(qiu)，就前端來說業務(wu)場(chang)景一般(ban)不會影響(xiang)技術(shu)棧選型，那么(me)飛(fei)(fei)豬微(wei)信(xin)小(xiao)程(cheng)序項目(mu)啟動時的(de)核心訴(su)求(qiu)是什么(me)呢：

快速實現(xian)：項目時間緊迫，2-3周(zhou)內要完成(cheng)開發(fa)

一碼多端：小程(cheng)序頁(ye)面(mian)有降級投放H5的需(xu)求

快速實現(xian)就(jiu)要求我(wo)(wo)們選(xuan)(xuan)擇的(de)(de)技術棧要么能快速上手最(zui)好是(shi)大家已(yi)經有(you)一定的(de)(de)熟(shu)練(lian)度，并且(qie)需(xu)(xu)要對(dui)這(zhe)個技術棧的(de)(de)穩(wen)定性(xing)有(you)信心(xin)或者(zhe)出了問(wen)題能得到及(ji)時(shi)(shi)(shi)的(de)(de)解決；一碼多端既有(you)歷(li)史(shi)原因(yin)（我(wo)(wo)們有(you)現(xian)存的(de)(de)H5頁(ye)面需(xu)(xu)要進入小(xiao)程序(xu)）也有(you)面向未(wei)來的(de)(de)考慮，未(wei)來飛豬前端需(xu)(xu)要面對(dui)H5、微(wei)信小(xiao)程序(xu)、支付寶(bao)小(xiao)程序(xu)多種(zhong)容器類型，因(yin)此選(xuan)(xuan)擇的(de)(de)技術棧必(bi)須要有(you)多端適配(pei)的(de)(de)能力以(yi)節省開發(fa)(fa)人(ren)力。因(yin)此我(wo)(wo)們毫無疑問(wen)的(de)(de)選(xuan)(xuan)擇了Rax1.0，一者(zhe)我(wo)(wo)們已(yi)經存在基于Rax的(de)(de)基礎組件(jian)庫(ku)以(yi)及(ji)大量(liang)的(de)(de)開發(fa)(fa)經驗，二者(zhe)Rax作為集團內(nei)的(de)(de)產品我(wo)(wo)們比較相信其對(dui)我(wo)(wo)們項目的(de)(de)支持度。這(zhe)里有(you)個伏筆，Rax的(de)(de)主推(tui)技術方案(an)是(shi)“運行(xing)(xing)時(shi)(shi)(shi)模式”（和taro@3.0、kbone類似都(dou)是(shi)利用(yong)template的(de)(de)遞歸渲染 + 模擬DOM BOM實現(xian)），加上我(wo)(wo)們依賴的(de)(de)部分(fen)二方頁(ye)面也是(shi)運行(xing)(xing)時(shi)(shi)(shi)方案(an)、商詳頁(ye)面動態化方案(an)不適應編譯時(shi)(shi)(shi)方案(an)等原因(yin)，我(wo)(wo)們一期(qi)是(shi)采(cai)用(yong)了全運行(xing)(xing)時(shi)(shi)(shi)方案(an)開發(fa)(fa)，這(zhe)個是(shi)后期(qi)做混編的(de)(de)背(bei)景。

合作模式

由(you)(you)于需(xu)要多條(tiao)業務(wu)(wu)線(xian)的(de)前(qian)端團(tuan)隊同(tong)學共(gong)榮開(kai)(kai)發(fa)(fa)，勢必需(xu)要采用業務(wu)(wu)線(xian)獨(du)立開(kai)(kai)發(fa)(fa) + 小(xiao)(xiao)程序(xu)主體集(ji)成(cheng)(cheng)的(de)合作方(fang)式(shi)(shi)。要實現這(zhe)種(zhong)模式(shi)(shi)有兩種(zhong)選擇：1. 頁面插件化(hua)；2. 頁面組(zu)件化(hua)。就(jiu)小(xiao)(xiao)程序(xu)來說插件化(hua)是(shi)將各個業務(wu)(wu)團(tuan)隊隔(ge)離(li)最徹底的(de)方(fang)式(shi)(shi)，并且插件的(de)發(fa)(fa)布也更(geng)自(zi)(zi)由(you)(you)不(bu)受集(ji)成(cheng)(cheng)節(jie)奏(zou)的(de)限制，業務(wu)(wu)線(xian)的(de)同(tong)學是(shi)比較傾向于這(zhe)種(zhong)自(zi)(zi)己掌握業務(wu)(wu)迭(die)代節(jie)奏(zou)的(de)方(fang)式(shi)(shi)的(de)。但是(shi)對于我們(men)需(xu)要做集(ji)成(cheng)(cheng)的(de)平臺同(tong)學看來這(zhe)種(zhong)太(tai)自(zi)(zi)由(you)(you)的(de)方(fang)式(shi)(shi)存在較大的(de)穩(wen)定性(xing)(xing)(xing)風險，因(yin)為(wei)太(tai)過自(zi)(zi)由(you)(you)信(xin)息互通(tong)的(de)必要性(xing)(xing)(xing)就(jiu)會降低，如果一些插件變更(geng)沒(mei)有同(tong)步(bu)到平臺同(tong)學或者平臺同(tong)學對框架(jia)的(de)改動(dong)沒(mei)同(tong)步(bu)到業務(wu)(wu)線(xian)同(tong)學就(jiu)容易引發(fa)(fa)線(xian)上問題，做集(ji)成(cheng)(cheng)的(de)同(tong)學天然(ran)反(fan)感這(zhe)種(zhong)失控感。最終我們(men)選擇的(de)依然(ran)是(shi)比較保守的(de)頁面組(zu)件化(hua)方(fang)案，但主要原因(yin)卻并不(bu)是(shi)穩(wen)定性(xing)(xing)(xing)，反(fan)而是(shi)微信(xin)小(xiao)(xiao)程序(xu)自(zi)(zi)身(shen)的(de)限制：

插件個(ge)數不能超出10個(ge)

只有(you)靜態插(cha)件(jian)：插(cha)件(jian)體積會(hui)計入包體積，因為(wei)插(cha)件(jian)無法天然共(gong)享(xiang)主包內(nei)公共(gong)模塊需要特殊處理

使(shi)用插件(jian)需要(yao)聲明具(ju)體版(ban)本：插件(jian)版(ban)本更(geng)新后主(zhu)體小程序需要(yao)修改依(yi)賴的插件(jian)版(ban)本號(hao)聲明并重新發(fa)版(ban)，業務(wu)線的迭代(dai)節奏(zou)依(yi)然需要(yao)依(yi)賴集成

研發平臺

核心迭代集成功能

在項目早期(qi)我們是通(tong)過人肉的方式(shi)來進行迭(die)代管控（紅色是人肉溝通(tong)）：

整(zheng)個過程充滿了(le)(le)讓程序(xu)(xu)員(yuan)深惡痛絕的(de)(de)(de)“人肉(rou)操作”，尤其是(shi)對做集(ji)(ji)(ji)成(cheng)的(de)(de)(de)同(tong)(tong)學(xue)(xue)來說簡直是(shi)個災難(nan)。為(wei)此(ci)我們拉動業務線開發(fa)&測(ce)試(shi)同(tong)(tong)學(xue)(xue)一起制定(ding)了(le)(le)《小(xiao)程序(xu)(xu)集(ji)(ji)(ji)成(cheng)規范(fan)》，清(qing)晰了(le)(le)每周一次(ci)的(de)(de)(de)集(ji)(ji)(ji)成(cheng)節奏，明(ming)確(que)了(le)(le)各(ge)業務的(de)(de)(de)測(ce)試(shi)邊界，約定(ding)了(le)(le)小(xiao)程序(xu)(xu)的(de)(de)(de)集(ji)(ji)(ji)成(cheng)、灰度(du)、回滾、緊急(ji)版本(ben)的(de)(de)(de)機制，讓流程規范(fan)化(hua)起來。然(ran)后借力集(ji)(ji)(ji)團的(de)(de)(de)“王守義”釘釘機器人實現了(le)(le)通(tong)過釘釘消(xiao)息（開發(fa)分支(zhi)號）打(da)微(wei)信小(xiao)程序(xu)(xu)預(yu)覽(lan)碼的(de)(de)(de)能(neng)力，開發(fa)同(tong)(tong)學(xue)(xue)只(zhi)需要將分支(zhi)號給(gei)到測(ce)試(shi)同(tong)(tong)學(xue)(xue)，測(ce)試(shi)同(tong)(tong)學(xue)(xue)可以自(zi)行(xing)通(tong)過釘釘打(da)預(yu)覽(lan)碼，降低了(le)(le)開發(fa)&測(ce)試(shi)同(tong)(tong)學(xue)(xue)的(de)(de)(de)溝通(tong)成(cheng)本(ben)。

但僅(jin)是(shi)這樣還不(bu)夠，我們希望(wang)(wang)能有更自(zi)(zi)動(dong)化(hua)的(de)方(fang)式將溝(gou)通(tong)成(cheng)本和重(zhong)復人(ren)工(gong)(gong)盡量降低到0，希望(wang)(wang)能有工(gong)(gong)具化(hua)的(de)方(fang)法(fa)讓規(gui)范自(zi)(zi)動(dong)run起來而不(bu)是(shi)簡單(dan)的(de)文檔化(hua)。于是(shi)我們誕生了做一個“研發平臺”的(de)想法(fa)，不(bu)僅(jin)要將集成(cheng)規(gui)范化(hua)、自(zi)(zi)動(dong)化(hua)起來，還希望(wang)(wang)將其打造(zao)為“小(xiao)程序開發者的(de)日常(chang)工(gong)(gong)作平臺”。

目前“研發平(ping)臺”已(yi)經(jing)包(bao)含迭代(dai)集成管理、包(bao)信息展示、包(bao)依(yi)賴分析、在線抓包(bao)、自動化(hua)測(ce)試(shi)、性能&穩定性數據大盤等(deng)功(gong)能。基本涵蓋(gai)了一個(ge)小(xiao)程序的(de)業務需求從開發=> 測(ce)試(shi) => 集成 => 數據的(de)全生命(ming)周期。其核心的(de)迭代(dai)管理功(gong)能流程已(yi)基本實現自動化(hua)，人肉溝通不再是(shi)必(bi)要手段，各(ge)職責(ze)同學按照節奏&通知進(jin)行(xing)在研發平(ping)臺進(jin)行(xing)相應(ying)操作即可：

界面展示

迭代日歷

迭代集成

迭代完成

其他輔助工具

除了迭代集成外，我們在研發平臺(tai)還為開發者(zhe)提供了一(yi)系列(lie)的小程序開發工具(ju)，希望一(yi)個平臺(tai)能滿足(zu)日常開發所需(xu)：

掃碼在線抓包

掃碼在線驗證埋點

微信域短鏈生成服務

小(xiao)程序源代碼包依賴變更分析

小程序包(bao)(bao)結構信(xin)(xin)息圖表：分(fen)(fen)(fen)包(bao)(bao)數(shu)、頁(ye)面數(shu)、分(fen)(fen)(fen)包(bao)(bao)技術(shu)棧、分(fen)(fen)(fen)包(bao)(bao)業(ye)務信(xin)(xin)息

集成版本自動化測試報告

小程序二維碼生成工具

技術生態

套殼

我(wo)們這邊把(ba)使用web-view組件方式引入H5頁(ye)(ye)面的(de)小程序頁(ye)(ye)稱之為套殼頁(ye)(ye)以和小程序頁(ye)(ye)面、H5頁(ye)(ye)面區分。眾(zhong)所周知，taobao.com的(de)域名是(shi)無(wu)法在(zai)微(wei)信體系(xi)內打(da)開的(de)，因此我(wo)們只能(neng)通過代理(li)的(de)方式繞過這層限制，代理(li)本身沒什么好說(shuo)的(de)，這里主(zhu)要講下套殼頁(ye)(ye)面的(de)登錄態怎么處(chu)理(li)。如果讓用戶

進入需要(yao)登錄(lu)的套殼H5頁面時，跳(tiao)轉H5的登錄(lu)：做法簡單；但這種做法會造成(cheng)用戶需要(yao)二(er)次登錄(lu)并且無法保(bao)障用戶兩次登錄(lu)的賬號一致，嚴重影響用戶體驗，完(wan)全不可取。

將小(xiao)程序(xu)的(de)登錄態(tai)同步(bu)到(dao)套殼H5頁面(mian)：最符合(he)用戶直覺保障(zhang)業務正常流轉的(de)做法，但(dan)由于小(xiao)程序(xu)容(rong)器內沒有(you)cookie的(de)概念(nian)，并且小(xiao)程序(xu)的(de)容(rong)器和webview容(rong)器也不互通，需(xu)要(yao)有(you)“小(xiao)程序(xu) => H5”登錄態(tai)傳遞(di)的(de)方案(an)。

“小程(cheng)序(xu) => H5”登(deng)錄態(tai)(tai)(tai)傳(chuan)遞(di)比(bi)較常(chang)規的做法是：在(zai)用(yong)戶(hu)登(deng)錄小程(cheng)序(xu)后打開(kai)一(yi)(yi)個空白的H5鏈接專門(men)同步登(deng)錄態(tai)(tai)(tai)（將cookie種在(zai)webview中）。但是這種做法，一(yi)(yi)來(lai)(lai)影響用(yong)戶(hu)體驗(yan)二(er)來(lai)(lai)也無法保障webview中的登(deng)錄態(tai)(tai)(tai)時效(xiao)和小程(cheng)序(xu)一(yi)(yi)致，如(ru)果(guo)為(wei)了(le)webview的登(deng)錄態(tai)(tai)(tai)時效(xiao)讓用(yong)戶(hu)每次(ci)進入小程(cheng)序(xu)都同步一(yi)(yi)次(ci)登(deng)錄態(tai)(tai)(tai)則用(yong)戶(hu)體驗(yan)更差，因此我們最(zui)終使(shi)用(yong)了(le)比(bi)較曲(qu)折的方式(shi)：

域名防封殺

和傳統意義上(shang)的(de)(de)頁面域名(ming)防封殺不(bu)同(tong)，我(wo)們(men)在(zai)去年的(de)(de)國慶(qing)遇到了甘肅(su)地區因接口域名(ming)被(bei)舉報涉嫌(xian)詐騙被(bei)運營(ying)商封殺的(de)(de)問題（后向公安部門申訴解封了），導致(zhi)當地微信小(xiao)程序(xu)無法使用。雖然只是甘肅(su)某個流量(liang)不(bu)大(da)的(de)(de)景(jing)區但(dan)也是給(gei)我(wo)們(men)敲響了警鐘，域名(ming)池(chi)必須要做(zuo)起(qi)來。飛豬微信小(xiao)程序(xu)面對(dui)的(de)(de)域名(ming)封殺和一般意義上(shang)的(de)(de)微信域名(ming)封殺有較大(da)的(de)(de)區別，其特點我(wo)歸納如下：

運營(ying)商層面(mian)的封殺是(shi)對主(zhu)域(yu)名做了(le)DNS劫持，不是(shi)微(wei)信小程序無法打開，但是(shi)會導致接口請(qing)求失敗

封(feng)殺(sha)有地域性特點的點狀爆(bao)發，并(bing)且(qie)可(ke)以申(shen)訴可(ke)以解封(feng)，不是永久封(feng)禁

我(wo)們線下(xia)的競對較多，防(fang)封殺(sha)策略必須穩定保證所有用(yong)戶可用(yong)，避免用(yong)戶流失

根據上面的特(te)點(dian)，我們設計了(le)一個(ge)純端側(ce)版本的域(yu)名池方案：

接口和(he)登錄(lu)的域名(ming)池事先配套，并配置在靜態代碼中

用戶(hu)出(chu)現域(yu)名(ming)(ming)被封殺的特征(zheng)后立即切換端側全局域(yu)名(ming)(ming)配置，更新接(jie)口和登錄的請(qing)求域(yu)名(ming)(ming)，并(bing)為用戶(hu)重新發送請(qing)求

建立報(bao)警機制，出現點狀(zhuang)爆發后(hou)立即走(zou)申請解封流程

這套機制(zhi)保障了(le)用戶的可用性并(bing)且基本(ben)用戶無感，并(bing)且成本(ben)較(jiao)低也比較(jiao)健壯(zhuang)。

url統一化

在微信小程序(xu)一期時我們就經歷過痛(tong)苦的(de)(de)分包(bao)策略(lve)變更導致的(de)(de)頁(ye)面(mian)(mian)路由變化(hua)，更新(xin)路由雖(sui)然不難但是很耗時間也(ye)(ye)很容易(yi)遺(yi)漏，在后續在多次經歷了分包(bao)/頁(ye)面(mian)(mian)變動(dong)后，我們決定(ding)啟動(dong)URL統一化(hua)的(de)(de)建設。url統一化(hua)后小程序(xu)內可以直接(jie)使用H5的(de)(de)鏈接(jie)打開(kai)對應的(de)(de)小程序(xu)頁(ye)面(mian)(mian)，業務(wu)不再需要判斷端來打開(kai)不同的(de)(de)頁(ye)面(mian)(mian)地址，也(ye)(ye)無需擔心小程序(xu)頁(ye)面(mian)(mian)路徑變化(hua)引起大(da)范圍修改問題。

url統一化有(you)兩種做(zuo)法，一是(shi)純端側配(pei)置二(er)是(shi)服務(wu)端下(xia)發(fa)配(pei)置。微信小(xiao)(xiao)(xiao)程(cheng)序(xu)(xu)考慮到如果使用服務(wu)端下(xia)發(fa)會出現數據緩存和小(xiao)(xiao)(xiao)程(cheng)序(xu)(xu)版本(ben)不一致問題，導致可(ke)能會因(yin)為沒找(zhao)到H5鏈接對應的(de)(de)小(xiao)(xiao)(xiao)程(cheng)序(xu)(xu)路由配(pei)置而誤打開套殼，而微信小(xiao)(xiao)(xiao)程(cheng)序(xu)(xu)的(de)(de)套殼限(xian)制比(bi)較大(da)無(wu)法保證正常瀏覽，因(yin)此(ci)采用了本(ben)地配(pei)置的(de)(de)做(zuo)法。

技術方(fang)案比(bi)較簡單(dan)，我們在統一(yi)的(de)(de)(de)頁面(mian)open方(fang)法中(zhong)引入了這段(duan)H5鏈接和小(xiao)程序(xu)頁面(mian)的(de)(de)(de)一(yi)一(yi)對(dui)應的(de)(de)(de)配置(zhi)，判(pan)斷當前需要open的(de)(de)(de)H5鏈接如(ru)果hostname + pathname + query（如(ru)果配置(zhi)中(zhong)出(chu)現(xian)query）均能(neng)和某個配置(zhi)匹配的(de)(de)(de)話則打開對(dui)應的(de)(de)(de)小(xiao)程序(xu)頁面(mian)并透傳query。

性能優化

混編&獨立分包

由于框(kuang)架(jia)(jia)的(de)限制，我(wo)們無法(fa)在一個(ge)項目中(zhong)同時(shi)(shi)(shi)存(cun)在運(yun)行(xing)時(shi)(shi)(shi)方(fang)案(an)頁面(mian)和編(bian)譯時(shi)(shi)(shi)方(fang)案(an)的(de)頁面(mian)，框(kuang)架(jia)(jia)提供的(de)運(yun)行(xing)時(shi)(shi)(shi)頁面(mian)使用編(bian)譯時(shi)(shi)(shi)組件(jian)的(de)方(fang)案(an)不支(zhi)持(chi)分包(bao)處理(li)，該方(fang)案(an)會(hui)將所(suo)有(you)的(de)編(bian)譯時(shi)(shi)(shi)組件(jian)統(tong)一放在主包(bao)內，而我(wo)們的(de)開發模式(shi)是頁面(mian)既組件(jian)，所(suo)以這(zhe)個(ge)方(fang)案(an)也無法(fa)滿足我(wo)們，因此(ci)我(wo)們最終利用框(kuang)架(jia)(jia)提供的(de)工程hook自己“外掛(gua)”了(le)一套(tao)工程解(jie)決(jue)(jue)，這(zhe)套(tao)“外掛(gua)”的(de)工程同時(shi)(shi)(shi)解(jie)決(jue)(jue)了(le)框(kuang)架(jia)(jia)不支(zhi)持(chi)獨立分包(bao)的(de)問題(ti)，具體實踐和框(kuang)架(jia)(jia)綁定較強(qiang)就不再贅述(shu)，以下僅(jin)貼(tie)出在DOM較多的(de)場景(jing)下運(yun)行(xing)時(shi)(shi)(shi)&編(bian)譯時(shi)(shi)(shi)的(de)性能對比。

編譯時

運行時

prefetch

值得一提的(de)是我(wo)們統一各廠家小程(cheng)序(xu)(xu)實現的(de)接口預加載（prefetch）方案，通過配(pei)合微信(xin)小程(cheng)序(xu)(xu)提供(gong)的(de)“冷(leng)啟(qi)動(dong)數(shu)據預拉(la)取”功能(neng)，我(wo)們在(zai)微信(xin)小程(cheng)序(xu)(xu)完成(cheng)了從啟(qi)動(dong)到頁面瀏覽過程(cheng)中的(de)全(quan)生(sheng)命周(zhou)期預加載能(neng)力。

PS: 以下圖片中，rxpi為我(wo)(wo)們(men)的(de)(de)一碼多端組(zu)件庫，rxpi-mtop為我(wo)(wo)們(men)的(de)(de)統一接(jie)口請求(qiu)組(zu)件，配置平(ping)臺即(ji)研發平(ping)臺的(de)(de)prefetch配置中心

冷啟動

主動觸(chu)發(fa)prefetch

頁(ye)面(mian)跳轉(zhuan)時被動觸發prefetch

體積優化

隨著(zhu)接入的(de)(de)業務線越(yue)來(lai)越(yue)多，業務頁面越(yue)來(lai)越(yue)豐富，飛豬(zhu)微信(xin)小程序的(de)(de)體(ti)(ti)積(ji)不可避(bi)免的(de)(de)迅速膨脹起來(lai)，至10月份(fen)時(shi)體(ti)(ti)積(ji)已經膨脹到了18M+，已經無法承(cheng)擔(dan)火(huo)車票入微的(de)(de)要(yao)求，因此(ci)我(wo)們需要(yao)有(you)有(you)效的(de)(de)手(shou)段優化包體(ti)(ti)積(ji)、遏(e)制包體(ti)(ti)積(ji)的(de)(de)過(guo)分擴(kuo)張。

在此背景下(xia)，我(wo)們(men)出臺了一(yi)份微信小(xiao)程序《業務(wu)(wu)&分包(bao)(bao)(bao)體(ti)積(ji)分析和(he)規(gui)范(fan)》，分析了各(ge)個業務(wu)(wu)的(de)包(bao)(bao)(bao)體(ti)積(ji)現狀并對各(ge)業務(wu)(wu)提出了包(bao)(bao)(bao)體(ti)積(ji)要求，業務(wu)(wu)超出分配(pei)的(de)包(bao)(bao)(bao)體(ti)積(ji)則(ze)需要想辦法優化(hua)或者和(he)其他業務(wu)(wu)做空(kong)間置換。然后我(wo)們(men)從平(ping)臺角度(du)立刻(ke)著手從工程、業務(wu)(wu)兩個層面想辦法刪減體(ti)：

以(yi)上手段和(he)框架、業務相關性(xing)較大(da)所以(yi)不(bu)做(zuo)具體(ti)闡述，僅(jin)編譯時&運行(xing)時公共模塊主包(bao)化就讓我們成(cheng)功(gong)將體(ti)積(ji)(ji)(ji)從(cong)18M+縮減(jian)到了13M，而且其(qi)意義(yi)不(bu)僅(jin)限于這(zhe)個(ge)一次性(xing)的效果(guo)，后續(xu)新增的頁面(mian)(mian)都會從(cong)中受益。以(yi)目(mu)(mu)前小程(cheng)序的總體(ti)積(ji)(ji)(ji)和(he)頁面(mian)(mian)數(shu)(shu)相除，目(mu)(mu)前我們每個(ge)小程(cheng)序頁面(mian)(mian)約(yue)占體(ti)積(ji)(ji)(ji)172KB的體(ti)積(ji)(ji)(ji)，這(zhe)個(ge)數(shu)(shu)值并不(bu)太令人滿意，體(ti)積(ji)(ji)(ji)優化的路還(huan)是(shi)任重道遠呀~

未來

優(you)化是前端(duan)的(de)一(yi)個長期(qi)的(de)課題，只要(yao)微(wei)信小(xiao)程序項目存在一(yi)天都不可能停止(zhi)對優(you)化的(de)探(tan)索，無論是工具、技術、業務。從我個人的(de)體感(gan)出(chu)發，起碼(ma)這些方面還需要(yao)繼(ji)續優(you)化下去：

關(guan)注(zhu)「Alibaba F2E」微信公眾號(hao)把握阿里巴(ba)巴(ba)前端新動向(xiang)