Xcode Clean Build 耗時評比：本機 MacBook 對照雲端 M4 裸機

為什麼要看 Clean Build，而不是增量編譯

日常開發中，你改了一個 Swift 檔案，Xcode 只會重新編譯受影響的模組，這個時間可能只有十幾秒。 但這種「增量編譯」高度依賴快取，你在 A 機器上積累的派生資料放到 B 機器上毫無用處。 而以下幾個場景不可避免地需要從零開始：

• CI/CD 流水線中每次 Job 啟動時清空 DerivedData
• 切換 Xcode 版本或升級 macOS 後舊快取失效
• 更換開發機，新機器無任何歷史快取
• 執行 xcodebuild clean build 或 xcodebuild archive 的 Release 打包

因此，clean build 時間才是衡量「這臺機器能不能扛住 iOS 建置流水線」的真實基準。增量編譯的快慢， 更多反映的是開發者本人的使用習慣和程式碼改動頻率，而非硬體效能的天花板。本文的所有資料均來自完整 clean build， 確保三臺機器站在相同的起跑線上。

實測環境與測試工程說明

為了讓比較有意義，三臺機器使用完全相同的工程、相同的 Xcode 版本，並在相近的室溫下獨立完成三輪測試， 取中位數作為結果。每輪測試前都執行 rm -rf ~/Library/Developer/Xcode/DerivedData， 徹底清除本機派生資料，保證從零編譯。

MacBook Air M2 選擇了 8 核版本（市場上最常見的設定），而非 10 核的頂配款。 MacBook Pro M1 Pro 與 VPSRox M4 Mini 均為 10 核，這樣可以在相近的 CPU 核心數下， 重點觀察晶片代際差異（M1 Pro 對 M4）以及散熱能力對持續建置的影響。

Clean Build 全量編譯計時結果

下表記錄了三輪 clean build 的中位數牆鍾時間（wall-clock time）、峰值記憶體壓力及 Xcode 報告的 CPU 使用率峰值。 記憶體峰值透過 memory_pressure 工具和 Activity Monitor 在建置過程中取樣得出。

最值得注意的一列是「第 3 輪 vs 第 1 輪偏差」。MacBook Air 的第 3 次 clean build 比第 1 次慢了整整 38 秒， 原因是無風扇被動散熱在連續建置後讓晶片觸發了溫控降頻。MacBook Pro 由於有主動散熱，偏差收窄到 14 秒， 但依然存在。而執行在資料中心機櫃裡的 VPSRox M4 Mini，三輪之間僅差 2 秒，基本在測量誤差範圍內。

Archive 流水線耗時對比

Archive 比普通 clean build 更接近生產場景：它在編譯之外還需要完成程式碼簽署、bitcode 編譯（若開啟）、 dSYM 產生與符號表打包。在相同的工程上，Archive 耗時通常是 clean build 的 1.2–1.4 倍。

從 Archive 資料可以看出，M4 晶片在 dSYM 產生與符號表處理階段的速度優勢更為突出， 比 M1 Pro 縮短了約 19%，而不僅僅是 CPU 核心頻率帶來的線性提升。 這與 M4 在記憶體頻寬和 Neural Engine 輔助處理方面的架構改進有直接關係。

對於使用 Fastlane 的團隊，每次 fastlane gym 實際上等於一次完整 Archive + 匯出， 兩步合計在 M4 Mini 上約為 5 分 30 秒，同等設定下 MacBook Air M2 需要約 10 分鐘。 當一天內需要出多個版本（比如 dev/staging/production 三套包），這個差距會直接影響發版節奏。

散熱節流與記憶體壓力：本機機的隱藏變數

許多開發者測評文章只報告單次冷啟動成績，卻忽略了一個關鍵變數：熱積累（thermal accumulation）。 Apple Silicon 的晶片有智慧溫控策略，當機身溫度超過設定閾值時，會自動降低 CPU 和 GPU 頻率， 直到散熱能力跟上為止。這對無風扇設計的 MacBook Air 影響尤其明顯。

MacBook Air M2 的散熱節流觀測

在我們的測試中，MacBook Air M2 的機身底部在第二次 clean build 結束時（約 11 分鐘後）溫度已明顯升高， 可用 pmset -g thermlog 觀察到 CPU 功率限制（CPU_Speed_Limit）從 100 降至約 78， 第三次建置因此比第一次慢了超過 30 秒。如果你在 MacBook Air 上連續跑多次 CI 任務， 實際耗時會比冷機狀態系統性偏高 15%–30%，且難以預測。

MacBook Pro M1 Pro 的主動散熱邊界

MacBook Pro 的主動散熱系統使情況好很多，但並非完全免疫。當環境溫度較高（超過 28°C 的室內）， 或同時開著多個 Simulator 例項時，偶爾也會看到輕微的熱節流。我們的 14 秒偏差主要來自環境溫度略高的第三輪測試， 在 22°C 的受控環境下偏差縮減到約 8 秒。

資料中心環境的熱穩定性

VPSRox 節點執行在資料中心恆溫機櫃中（通常保持在 18–22°C），Mac mini M4 本身也配備主動散熱風扇。 這兩個條件疊加，使得建置耗時的一致性遠高於任何筆記型電腦。在我們的三輪測試中， 第 1 輪與第 3 輪的差距僅 2 秒，完全可以忽略。對於需要預測建置視窗的 CI 場景， 這種穩定性價值巨大：你可以基於 p99 時間而不是擔心某次意外超時。

記憶體峰值與 Swap 寫入對速度的影響

在 16 GB 統一記憶體的機器上，編譯大型 iOS 工程時記憶體壓力是真實存在的問題。 Xcode 在連結階段和程式碼簽署階段會同時開啟多個工具程式，Swift 編譯器本身也是記憶體大戶。 我們用 vm_stat 和 memory_pressure 兩個工具交叉驗證了記憶體峰值。

MacBook Air M2 在 clean build 過程中記憶體峰值達到約 11.8 GB，在兩個 Extension Target 同時編譯的並行視窗期出現了短暫的 swap 寫入（約 200–400 MB），此時 SSD 讀寫速度直接影響編譯進度。 MacBook Pro M1 Pro 的峰值約為 10.9 GB，三輪測試中均未觸發 swap，得益於 M1 Pro 更高效的記憶體排程。 VPSRox M4 Mini 的峰值僅約 9.4 GB，這主要反映了 M4 晶片對記憶體使用的進一步最佳化—— 相同的編譯任務在 M4 上需要更少的記憶體副本和中間物件。

對於工程規模更大（如超過 20 萬行）或依賴更多 Swift Package 的專案， 16 GB 在 MacBook Air 上會更容易遭遇記憶體瓶頸。此時若需要更大記憶體， VPSRox 提供 SSD 擴容選項（+1TB $2.6/天，+2TB $5.2/天），但暫時未提供超過 16 GB 的記憶體規格， 這一點需要在選型時提前考慮。

什麼情況下本機 MacBook 仍然夠用

並非所有團隊都需要雲端節點，對於以下情況，你手邊的 MacBook 完全可以勝任：

• 工程規模較小（< 3 萬行 Swift）：clean build 在任何 Apple Silicon MacBook 上都能在 2 分鐘內完成，不存在效能瓶頸。
• CI 頻率低（每天 < 5 次建置）：即使每次 clean build 需要 7–8 分鐘，一天總建置時間也在 40 分鐘以內，還在可接受範圍。
• 個人獨立開發者、本機除錯為主：增量編譯大部分時候足夠，clean build 只在發版時才需要，MacBook Pro M1 Pro 以上完全勝任。
• MacBook Pro M3/M4 使用者：Apple 最新一代 MacBook Pro（M4 Max 版本）的散熱和效能已經與 Mac mini M4 相差無幾，差異主要體現在持續建置的穩定性而非單次速度。

需要認真評估雲端節點的場景，則主要集中在以下幾類：CI/CD 流水線每天觸發超過 20 次建置、 團隊共享同一套建置環境（避免「在我機器上能過」的問題）、開發者使用 MacBook Air 且工程在持續擴大、 或者需要同時維護多個獨立專案的建置隔離。

綜合判斷：成本與收益怎麼算

切換到雲端 Mac 的成本顯而易見：VPSRox 獨享 Mac mini M4 按天租賃是 $21.8/天， 按月連續使用約 $109.1/月，比一臺新 MacBook Pro 便宜，但需要持續支出。 但換個角度算，你節省的是什麼？

以一個 5 人 iOS 團隊為例：假設每天平均觸發 30 次 clean build/Archive， 在 MacBook Air M2 上平均每次需要 8 分鐘（含輕微散熱節流），總共 240 分鐘。 同等工作量在 VPSRox M4 Mini 上約需 123 分鐘。每天節省約 117 分鐘機器時間， 對於 CI 並行跑多個分支的團隊，這些時間直接轉化為更快的程式碼審查反饋與發版視窗。

此外還有一個常被忽視的隱性成本：開發者在等待建置時的注意力切換。5 分鐘以內的等待， 許多人會選擇盯著進度條；超過 8 分鐘，往往會切到其他任務然後忘記切回來。 按常見的心流（flow state）研究，一次主動打斷需要約 20 分鐘才能重新進入高效工作狀態。 相比之下，每月 $109 的節點費用更像是「保持專注的工具成本」，而非純粹的伺服器租賃。