小程序攜程（攜程微信小程序如何進行Size治理）

2023-07-26 20:41:43

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

攜程小程序涉及30 條業務線，上百個開發人員，目前包體積已經向著微信限制的20M邁進，包體積過大必將導致新增業務受限、啟動慢等問題，這些都給用戶帶來了不好的使用體驗，因此對Size的治理勢在必行。

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

圖1 攜程小程序Size治理

從圖中可以看出，Size治理包括Size監控機制和主包文件管理機制，這兩個機制的實現離不開小程序管理平臺的支持。小程序管理平臺是攜程內部用於管理各類小程序（微信、百度、支付寶等）的官方系統，是一個集小程序配置、發布、審批、數據統計於一體的系統。接下來我們將對其進行詳細的介紹。

2.1 Size分配

在《攜程微信小程序如何協同開發》一文中我們提到過，攜程將整個小程序劃分數十條業務線（即Bundle），每個Bundle可以擁有多個分包。我們為每個Bundle設置一個約定好的閾值，該值包括兩部分：永久Size 臨時Size。顧名思義，永久Size是Bundle的固有Size，臨時Size是指到了約定日期將自動回收的Size，這些信息都在小程序管理平臺系統中進行配置，如圖2所示：

圖2 Size分配

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

2.2 Size檢測

每當業務方提交代碼至發布分支時，都會自動觸發pipeline的構建，此時會對當前Bundle的實際Size進行檢測，如果超過約定的Size值，會強制中斷構建過程，並發送失敗信息至相關發布群及開發人員，強制不讓代碼提交至發布分支，以此實現Size檢測的能力，報錯信息如圖3所示：

圖3 Size檢測結果通知

通過Size分配和Size檢查，強制業務方主動優化代碼、自行下線流量較少的老業務代碼，為新業務提供空間。同時，我們也提供了Size申請審批流程，業務方可通過申請臨時Size獲取額外的Size空間，如果臨時Size達到了內部相關要求，也可以申請轉換為永久Size。

2.3 Size申請審批

當Bundle必須通過申請臨時Size才能上線新的需求時，Bundle Owner可以在小程序管理平臺上創建臨時Size申請單，由相關委員會審批後決定是否通過臨時Size申請。如果以後想將臨時Size轉換為永久Size，需要理由足夠充分，並且約定好業績指標，才可以申請永久Size。申請平臺如圖4所示：

圖4 Size申請審批

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

2.4 Size提醒

為了督促各業務方能夠按時歸還臨時Size，防止Size不足導致發布失敗，我們設計了一套Size提醒機制，每天會給滿足以下任意一條的Bundle Owner發送消息提醒：

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

圖5 臨時Size倒計時提醒

圖6 Size超限提醒

通過消息提醒，促使Bundle Owner合理排期優化代碼、縮減Size，起到了預警、監督、告示的作用，防止臨時Size的回收致使新業務無法正常發布的情況。

2.5 Size數據統計

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

圖7 BU總體Size趨勢圖

圖8 Bundle Size趨勢圖

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

3.1 主包文件管理

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

圖9 主包文件管理

通過管理平臺，我們可以快速獲取主包中的文件內容以及文件的歸屬情況，配置後的數據將作為參照用於主包文件的檢查。

3.2 主包文件檢查

每當代碼提交進行pipeline構建時，我們會通過微信的規則篩選出可能會打包到主包中的文件，將該列表與小程序管理平臺上配置過的主包文件列表進行對比，如果存在未配置過的文件，會強制中斷構建過程，並將構建結果發送至相關發布群即開發人員，以此實現主包文件的管理，報錯信息如圖10所示：

圖10 主包文件檢查

通過對主包文件進行清理，並對主包中的文件進行嚴格限制之後，主包Size下降了46.5%，如圖11所示，目前已趨於穩定狀態。主包管理機制防止業務線隨意向主包中添加文件，做到了可感知、可控制，同時對提升首屏渲染性能有著重大意義。

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

綜上所述，攜程小程序Size治理方案主要包括Size管控機制和主包文件管理機制，實現了對Size的分配、檢測、申請、提醒、統計能力，該方案在微信小程序中被充分地實踐著，小程序的Size去向、佔比都更加直觀透明的展示出來，防止隨意濫用。目前微信小程序的Size已趨於穩定狀態，後續將逐步應用於其他類型的小程序中。

【作者簡介】

攜程前端框架團隊，為攜程集團各業務線在PC、H5、小程序等各階段提供優秀的Web解決方案。產品涉及各類前端/Node端應用框架、研發工作檯、前端中臺化、靜態資源發布系統等。當前主要專注方向包括：新一代研發模式探索，Rust構建工具鏈路升級、Serverless應用框架開發、在線文檔系統開發、低代碼平臺搭建、適老化與無障礙探索等。