?譯者 | 布加迪

審校 | 孫淑娟

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

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

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

圖1

作為參考，在2018年左右代碼庫(kù)增至四倍之后，簡(jiǎn)單一行代碼更改的平均頁(yè)面刷新時(shí)間在30秒到2分鐘之間，具體取決于項(xiàng)目大小。

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

一、Metro簡(jiǎn)介

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

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

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

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

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

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

按需處理JavaScript包

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

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

開(kāi)發(fā)人員對(duì)頁(yè)面A進(jìn)行了更改，但下圖中看不到：

圖2

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

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

多層緩存

圖2

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

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

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

Webpack有一個(gè)緩存層，不過(guò)它與Metro提供的緩存層不一樣。

三、包拆分

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

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

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

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

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

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

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