?譯者 | 布加迪

審校 | 孫淑娟

與許多大規(guī)模公司一樣，隨著代碼庫不斷變大，愛彼迎也在打包工具方面經(jīng)歷了陣痛。即使代碼庫增至四倍，愛彼迎在2018年將JavaScript代碼打包工具從Webpack遷移到Metro后，還是加快了對前端的UX更改。

構(gòu)建性能顯著提升后，從交互時間（TTI）這個指標(biāo)來看，UI更改速度加快了80%。即使是最慢的生產(chǎn)級構(gòu)建，編譯49000個模塊（JavaScript文件）現(xiàn)在也快了55%，從使用Webpack時的30.5分鐘縮短至13.8分鐘。

至于使用Metro構(gòu)建的那些頁面，愛彼迎自己的頁面性能得分（PPS）也有所提高（提高約1%）。

圖1

作為參考，在2018年左右代碼庫增至四倍之后，簡單一行代碼更改的平均頁面刷新時間在30秒到2分鐘之間，具體取決于項目大小。

愛彼迎軟件工程師Rae Liu在最近的這篇??博文??(中介紹了Webpack和Metro的一些差異，并討論了一些遷移挑戰(zhàn)。

一、Metro簡介

Metro由Meta開發(fā)，是面向React Native的開源JavaScript代碼打包工具。本文介紹Metro的自定義版本，因為愛彼迎的架構(gòu)不包含React Native。降了與本公司的團隊合作外，愛彼迎的工程師還直接與Meta的Metro工程師合作，進一步開發(fā)這項技術(shù)。

Metro按以下順序?qū)⒋虬譃槿齻€步驟：解析、轉(zhuǎn)換和序列化。

• 解析：解析import/require語句。
• 轉(zhuǎn)換：轉(zhuǎn)譯代碼（源到源編譯器將現(xiàn)代Typescript/JavaScript源代碼轉(zhuǎn)換成JavaScript，并與舊瀏覽器向后兼容），典型的工具是babel。
• 序列化：將轉(zhuǎn)換后的文件組合成包。

在開發(fā)過程中，愛彼迎工程師創(chuàng)建了一個帶自定義端點的Metro服務(wù)器系統(tǒng)，以處理構(gòu)建依賴圖和源映射、轉(zhuǎn)換以及捆綁JS和CSS文件。至于生產(chǎn)級構(gòu)建，他們將Metro作為Node API來運行，以處理解析、轉(zhuǎn)換和序列化。

遷移分兩個階段進行。最要緊的是Metro開發(fā)服務(wù)器，因為緩慢的Webpack開發(fā)服務(wù)器是導(dǎo)致開發(fā)生產(chǎn)力成本高昂的根源。第二個遷移階段致力于讓Metro在功能上與Webpack相當(dāng)，并在生產(chǎn)環(huán)境下在Metro和Webpack之間運行A/B測試。

二、Metro和Webpack的兩大區(qū)別

按需處理JavaScript包

Webpack在啟動時預(yù)編譯整個項目，而Metro只編譯需要的內(nèi)容。也就是說，JavaScript包嚴(yán)格上來說就是序列化的依賴圖，其中入口點是這張圖的根（root）。

在愛彼迎，每個前端項目都有一個Node服務(wù)器來匹配通向特定入口點的路由。請求網(wǎng)頁時，DOM包含帶有開發(fā)JavaScript URL的腳本標(biāo)簽。Webpack需要知道所有頁面的所有入口點，之后才能開始打包，而Metro只需要一個入口點，就可以根據(jù)請求處理JavaScript包。

開發(fā)人員對頁面A進行了更改，但下圖中看不到：

圖2

在上圖的1a和1b中，瀏覽器加載頁面A（1），從打包工具請求entryPageA.js文件（2），打包工具使用適當(dāng)?shù)陌憫?yīng)瀏覽器（4）。圖1a和圖1b的區(qū)別在于操作（3），因為 Webpack圖編譯了頁面B和C的入口點，而Metro并非如此，因為開發(fā)人員在示例中只修改了頁面A。

愛彼迎最大的前端項目之一有26000個獨特的模塊，每頁的模塊中位數(shù)約7.2個模塊。由于使用了服務(wù)器端渲染，愛彼迎最終要處理的模塊數(shù)量翻番，達到大約48000個。在將Metro的按需編譯模型付諸實施之后，現(xiàn)在減少了大約70%的工作量。

多層緩存

圖2

愛彼迎利用Metro的多層緩存功能以及持久性和非持久性緩存。Metro允許工程師定義緩存實現(xiàn)，包括混合不同類型的緩存層，這樣提供了更高的緩存靈活性。

愛彼迎按優(yōu)先級對緩存層排序。如果在一個緩存層中沒有找到結(jié)果，將使用下一層，直至找到結(jié)果。與沒有緩存的默認(rèn)Metro實現(xiàn)相比，在一個編譯22000個文件的項目中，命中遠(yuǎn)程只讀緩存可使服務(wù)器構(gòu)建速度提高56%。

第三個緩存層是遠(yuǎn)程只讀緩存而不是讀寫緩存，因為寫入到遠(yuǎn)程緩存會帶來昂貴的網(wǎng)絡(luò)調(diào)用，尤其是在慢速網(wǎng)絡(luò)上。這個決定在開發(fā)中另外節(jié)省了17%的構(gòu)建時間。

Webpack有一個緩存層，不過它與Metro提供的緩存層不一樣。

三、包拆分

愛彼迎的博文中詳述的技術(shù)挑戰(zhàn)之一是包拆分（Bundle Splitting）。這是通過動態(tài)導(dǎo)入邊界拆分包的過程（又叫代碼拆分）。開箱即用的Metro解決方案為每個入口點生成約5MiB 的巨大包，這對瀏覽器資源和網(wǎng)絡(luò)延遲造成了負(fù)擔(dān)，無法進行HTTP緩存。

在上圖中，import(‘./file’) 表示動態(tài)導(dǎo)入邊界。左側(cè)的包（3a）被拆分成右側(cè)的三個小包（3b）。執(zhí)行import('./file') 語句時請求額外的包。

假設(shè)fileA.js發(fā)生了更改，需要重新下載整個包，以便瀏覽器獲取fileA.js中的更改。如圖3b所示，由于包由動態(tài)導(dǎo)入拆分，fileA.js中的更改只導(dǎo)致重新下載fileA.js包。其余的包可以重用瀏覽器緩存內(nèi)容。

在生產(chǎn)環(huán)境下，沒有開發(fā)服務(wù)器，包是預(yù)先構(gòu)建的。愛彼迎工程師從Webpack的包拆分算法中獲得了靈感，實現(xiàn)了一種類似的機制來拆分Metro依賴圖。與動態(tài)導(dǎo)入邊界的開發(fā)拆分相比，愛彼迎上生成的包大小減少了約20%（由1549 KB變成1226 KB）。

開發(fā)包的優(yōu)化方式不一樣，因為運行包拆分算法需要時間，工程師們不想在開發(fā)中浪費時間來拆分包大小。在開發(fā)情形下，頁面加載性能的優(yōu)先級高于包大小實現(xiàn)最小化。

Metro和Webpack在包大小方面的指標(biāo)具有可比性。

標(biāo)題：??Airbnb Moves from Webpack to Metro, Enjoys Shorter Build Times???，作者：Jessica Wachtel?