借助 RAM disk 技術，加快前端工程打包速度

背景

以 Jenkins 伺服器為例，在建構内部的這個項目時，CE 每部署一次服務，最快 6 分鐘，最

慢将近 13 分鐘左右。遇到多個項目并發打包會因為資源占用等問題時間會延長，甚至出現過

幾次 20 分鐘以上的情況。

是以經常收到一些友情提示：比如像這樣的截圖，往往對方隻發一張圖，卻什麼都不說：

原因

在了解原因之前，我們先回顧一下曆史，也就是當年為什麼要用 Yarn。從這段曆史中，我們

可以分析出來慢的原因。

Yarn 工具沒有推出之前，通常是使用 NPM 進行依賴管理的，早期的 NPM 它有一個緻命的

缺陷；需要等一個包，完全安裝好後，在對下一個包做處理；它沒有并發能力，是以才不會

涉及到高 IO 的問題，犧牲的是等待時間。

NPM 遇到相同版本的依賴庫時，會重新下載下傳一遍這個包；因為它原生不具備緩存能力，是以

隻能重新下載下傳。這也不會涉及 IO 問題，因為它犧牲了下載下傳時間和 node_modules 檔案夾的體

積（這裡是提前引用概念，下面第四條中有介紹）。

是以當時，我們引用了 Yarn 工具來提升安裝依賴的速度。

(1) 它最特殊的是，具備鎖（lock）檔案，你從哪下載下傳檔案，你團隊的人就從哪下載下傳檔案，避

免包版本不一緻的問題。能解決我線下好使啊，怎麼到你那就不行，諸如此類的問題。

(2) 會緩存它下載下傳的每個包，是以無需重複下載下傳。

(3) 具備離線模式，之前安裝過的包會被寫入緩存目錄，以後安裝就直接從緩存中複制過來，

這樣做的本質是減少重複下載下傳，減少不必要的網絡請求。

(4) 為了減少 node_modules 體積，會對依賴次數做選舉，把引用頻率高的類庫放到頂級目錄。

我們已經了解，它是依賴檔案緩存的方式，提升了效率問題；僅僅是做選舉，就已經引發了

高頻 IO 的操作，因為它要分析引用次數來回的移動目錄。Webpack 打包建構情況也是類似，

具體就不在展開細說。

現象

是以我們有了一個印象，前端工程下載下傳後，會做很多 IO 操作。這對 SSD 磁盤很有效。如果

是機械硬碟，遇到高頻讀寫，性能就會很慢。這是 Yarn 在做依賴庫選舉而優化磁盤占用時，

機械硬碟所消耗的時間耗時 13 分鐘：