?作者 ｜ 攜程前端框架團(tuán)隊(duì)，為攜程集團(tuán)各業(yè)務(wù)線在PC、H5、小程序等各階段提供優(yōu)秀的Web解決方案。產(chǎn)品涉及各類前端/Node端應(yīng)用框架、研發(fā)工作臺(tái)、前端中臺(tái)化、靜態(tài)資源發(fā)布系統(tǒng)等。當(dāng)前主要專注方向包括：新一代研發(fā)模式探索，Rust構(gòu)建工具鏈路升級、Serverless應(yīng)用框架開發(fā)、在線文檔系統(tǒng)開發(fā)、低代碼平臺(tái)搭建、適老化與無障礙探索等。

一、背景

眾所周知，無論是微信小程序、支付寶小程序或者其他類型的小程序，代碼包都是有大小限制的。目前微信官方規(guī)定，整個(gè)小程序不超過20M，單個(gè)分包或主包大小不超過2M。之所以這樣限制，是對小程序啟動(dòng)速度的考慮，微信希望用戶在使用任何一款小程序時(shí)，都能獲得一種”秒開“體驗(yàn)，這也正是小程序的優(yōu)勢所在，但同時(shí)也對開發(fā)人員提出了更高的要求。

攜程小程序涉及30+條業(yè)務(wù)線，上百個(gè)開發(fā)人員，目前包體積已經(jīng)向著微信限制的20M邁進(jìn)，包體積過大必將導(dǎo)致新增業(yè)務(wù)受限、啟動(dòng)慢等問題，這些都給用戶帶來了不好的使用體驗(yàn)，因此對Size的治理勢在必行。

為了能夠合理有效的利用有限的Size，我們設(shè)計(jì)了一套自己獨(dú)有的Size治理方案，如圖1所示：

圖1 攜程小程序Size治理

從圖中可以看出，Size治理包括Size監(jiān)控機(jī)制和主包文件管理機(jī)制，這兩個(gè)機(jī)制的實(shí)現(xiàn)離不開小程序管理平臺(tái)的支持。小程序管理平臺(tái)是攜程內(nèi)部用于管理各類小程序（微信、百度、支付寶等）的官方系統(tǒng)，是一個(gè)集小程序配置、發(fā)布、審批、數(shù)據(jù)統(tǒng)計(jì)于一體的系統(tǒng)。接下來我們將對其進(jìn)行詳細(xì)的介紹。

二、Size監(jiān)控機(jī)制

2.1 Size分配

在《攜程微信小程序如何協(xié)同開發(fā)?》一文中我們提到過，攜程將整個(gè)小程序劃分?jǐn)?shù)十條業(yè)務(wù)線（即Bundle），每個(gè)Bundle可以擁有多個(gè)分包。我們?yōu)槊總€(gè)Bundle設(shè)置一個(gè)約定好的閾值，該值包括兩部分：永久Size + 臨時(shí)Size。顧名思義，永久Size是Bundle的固有Size，臨時(shí)Size是指到了約定日期將自動(dòng)回收的Size，這些信息都在小程序管理平臺(tái)系統(tǒng)中進(jìn)行配置，如圖2所示：

圖2 Size分配

從圖中可以看出，pages/train 的Size為：1888KB(永久Size) + 155KB(臨時(shí)Size)。在到達(dá)約定日期之前，該Bundle的開發(fā)人員必須調(diào)整代碼至永久Size大小(即1888KB)，否則該Bundle提交新的代碼時(shí)，將不能通過Size檢查階段。

2.2 Size檢測      

每當(dāng)業(yè)務(wù)方提交代碼至發(fā)布分支時(shí)，都會(huì)自動(dòng)觸發(fā)pipeline的構(gòu)建，此時(shí)會(huì)對當(dāng)前Bundle的實(shí)際Size進(jìn)行檢測，如果超過約定的Size值，會(huì)強(qiáng)制中斷構(gòu)建過程，并發(fā)送失敗信息至相關(guān)發(fā)布群及開發(fā)人員，強(qiáng)制不讓代碼提交至發(fā)布分支，以此實(shí)現(xiàn)Size檢測的能力，報(bào)錯(cuò)信息如圖3所示：

圖3 Size檢測結(jié)果通知

通過Size分配和Size檢查，強(qiáng)制業(yè)務(wù)方主動(dòng)優(yōu)化代碼、自行下線流量較少的老業(yè)務(wù)代碼，為新業(yè)務(wù)提供空間。同時(shí)，我們也提供了Size申請審批流程，業(yè)務(wù)方可通過申請臨時(shí)Size獲取額外的Size空間，如果臨時(shí)Size達(dá)到了內(nèi)部相關(guān)要求，也可以申請轉(zhuǎn)換為永久Size。

2.3 Size申請審批   

當(dāng)Bundle必須通過申請臨時(shí)Size才能上線新的需求時(shí)，Bundle Owner可以在小程序管理平臺(tái)上創(chuàng)建臨時(shí)Size申請單，由相關(guān)委員會(huì)審批后決定是否通過臨時(shí)Size申請。如果以后想將臨時(shí)Size轉(zhuǎn)換為永久Size，需要理由足夠充分，并且約定好業(yè)績指標(biāo)，才可以申請永久Size。申請平臺(tái)如圖4所示：

圖4 Size申請審批

通過提高Size的申請成本，促使業(yè)務(wù)方更合理的利用有限的Size，防止無限制的代碼堆砌、造成代碼冗余。

2.4 Size提醒   

為了督促各業(yè)務(wù)方能夠按時(shí)歸還臨時(shí)Size，防止Size不足導(dǎo)致發(fā)布失敗，我們設(shè)計(jì)了一套Size提醒機(jī)制，每天會(huì)給滿足以下任意一條的Bundle Owner發(fā)送消息提醒：

• 含有臨時(shí)Size的Bundle；
• 臨時(shí)Size到期的Bundle；
• Size超限的Bundle。 

提醒消息如圖5-6所示：

圖5 臨時(shí)Size倒計(jì)時(shí)提醒

?圖6 Size超限提醒

通過消息提醒，促使Bundle Owner合理排期優(yōu)化代碼、縮減Size，起到了預(yù)警、監(jiān)督、告示的作用，防止臨時(shí)Size的回收致使新業(yè)務(wù)無法正常發(fā)布的情況。

2.5 Size數(shù)據(jù)統(tǒng)計(jì)       

在小程序管理平臺(tái)中，我們也提供了數(shù)據(jù)統(tǒng)計(jì)的功能，可以多維度的展示Size的趨勢變化，比如BU維度的、Bundle維度、分包維度等；也可以查看小程序中各個(gè)BU的Size占比情況等，如圖7-8所示。通過統(tǒng)計(jì)可以讓我們直觀的了解各個(gè)業(yè)務(wù)線的活躍程度以及Size的分配情況。

圖7 BU總體Size趨勢圖

圖8 Bundle Size趨勢圖

三、主包文件管理機(jī)制

 每個(gè)小程序必定都有一個(gè)主包，所謂的主包，即放置默認(rèn)啟動(dòng)頁面或TabBar 頁面，以及一些所有分包都需用到公共資源。小程序啟動(dòng)并進(jìn)入非獨(dú)立分包頁面時(shí)，默認(rèn)會(huì)下載主包，并且自動(dòng)執(zhí)行主包的腳本，主包的體積直接影響首屏渲染性能，關(guān)乎用戶初次使用的體驗(yàn)，因此對主包文件的管理有著重要的意義。接下來，我們將從主包文件的管理和檢查兩方面進(jìn)行詳細(xì)介紹。

3.1 主包文件管理

小程序管理平臺(tái)提供了對主包文件的可視化管理功能，主包文件的查看、增加、刪除操作均可在管理平臺(tái)上進(jìn)行配置，如圖9所示：

圖9 主包文件管理

通過管理平臺(tái)，我們可以快速獲取主包中的文件內(nèi)容以及文件的歸屬情況，配置后的數(shù)據(jù)將作為參照用于主包文件的檢查。

3.2 主包文件檢查

每當(dāng)代碼提交進(jìn)行pipeline構(gòu)建時(shí)，我們會(huì)通過微信的規(guī)則篩選出可能會(huì)打包到主包中的文件，將該列表與小程序管理平臺(tái)上配置過的主包文件列表進(jìn)行對比，如果存在未配置過的文件，會(huì)強(qiáng)制中斷構(gòu)建過程，并將構(gòu)建結(jié)果發(fā)送至相關(guān)發(fā)布群即開發(fā)人員，以此實(shí)現(xiàn)主包文件的管理，報(bào)錯(cuò)信息如圖10所示：

圖10 主包文件檢查

通過對主包文件進(jìn)行清理，并對主包中的文件進(jìn)行嚴(yán)格限制之后，主包Size下降了46.5%，如圖11所示，目前已趨于穩(wěn)定狀態(tài)。主包管理機(jī)制防止業(yè)務(wù)線隨意向主包中添加文件，做到了可感知、可控制，同時(shí)對提升首屏渲染性能有著重大意義。

圖11 主包文件Size變化趨勢圖

三、總結(jié)

綜上所述，攜程小程序Size治理方案主要包括Size管控機(jī)制和主包文件管理機(jī)制，實(shí)現(xiàn)了對Size的分配、檢測、申請、提醒、統(tǒng)計(jì)能力，該方案在微信小程序中被充分地實(shí)踐著，小程序的Size去向、占比都更加直觀透明的展示出來，防止隨意濫用。目前微信小程序的Size已趨于穩(wěn)定狀態(tài)，后續(xù)將逐步應(yīng)用于其他類型的小程序中。