Xcode 編譯速度對比：MacBook 與雲端 Mac mini M4 實測

為什麼全量編譯比增量更能說明機器上限

日常開發裡，Xcode 的增量建置掩蓋了大量硬體差異：改一個檔案、只重編幾個 target， 8 GB 的 MacBook Air 和 16 GB 的 Pro 看起來「都能用」。 但 merge 進主分支、CI 觸發 Clean Build，或者本地執行 xcodebuild clean build 驗證 Release 配置時， 編譯器會同時拉起所有 Swift 模組、跑全量型別檢查、連結全部 Extension—— 這才是記憶體、散熱與 CPU 持續負載的真正考場。

我們收到過不少獨立開發者的回饋：「筆電編到一半風扇狂轉，Simulators 卡死，Slack 都切不動。」 問題往往不在 Xcode 版本，而在全量建置把機器推到持續高負載， 而筆電的散熱與統一記憶體容量是為行動場景設計的，不是為 5–10 分鐘不間斷編譯設計的。 這篇對比聚焦「同一專案、同一命令、不同機器」的牆鐘差異， 幫你判斷：是升級本地硬體，還是把重編譯挪到雲端獨享節點更划算。

統一測試方法：避免「各編各的」

對比編譯速度最容易犯的錯，是讓三台機器處於不同狀態——一台開著 Chrome 四十個分頁，另一台剛重啟， 第三台還留著上週的 DerivedData。我們固定了以下基線，保證數字可橫向比較：

1. 01
   同一 Git commit

   三台機器均 git checkout v2.4.0-buildbench，鎖定依賴版本與 Package.resolved，避免 SPM 解析時間干擾。

2. 02
   命令列建置，關閉 GUI

   不透過 Xcode 介面點 Product → Build，統一用 xcodebuild 並配合 /usr/bin/time -l 採集牆鐘與峰值記憶體。

3. 03
   模擬「真實桌面」背景負載

   本地 MacBook 額外執行：Slack、Chrome（8 分頁）、Simulators 未啟動。雲端 M4 僅跑 SSH 工作階段與建置腳本，模擬無人值守 CI 環境。

4. 04
   兩類建置各測一輪

   Debug clean build（開發驗錯）與 Release archive（發版路徑），分別記錄耗時與 swap 頁數。

Debug 建置命令範例： xcodebuild -workspace MyApp.xcworkspace -scheme MyApp -configuration Debug clean build -destination 'generic/platform=iOS' -jobs 10。 計時從命令送出到 ** BUILD SUCCEEDED ** 輸出為止，不含 pod install 與證書匯入。

Clean Build 牆鐘耗時：M4 與兩代 MacBook

Debug 全量編譯的中位數結果如下。M4 雲端節點比 M1 Pro 本地機快約 15%， 比 M2 Air 快一倍還多——差距主要來自 M2 Air 在第三分鐘觸發記憶體壓縮與 swap， 編譯後期 CPU 頻率因過熱從 3.4 GHz 降到約 2.6 GHz。

Release Archive 的差距比 Debug 更明顯：最佳化級別更高、連結階段更吃記憶體。 M2 Air 在 Archive 時 swap 峰值達到 4.1 GB，牆鐘時間接近 9 分鐘； 同一專案在 M4 上全程未突破 16 GB 物理記憶體，編譯曲線平穩，沒有「後期突然變慢」的拐點。 若你的發版流程每週至少一次全量 Archive，這個差距會直接轉化成等待成本與筆電可用性成本。

增量編譯：日常體感與全量結論為何不同

為完整呈現開發體驗，我們額外測了「修改單個 Swift 檔案後增量建置」—— 這是你在 IDE 裡按 Cmd+B 最常見的路徑。三台機器差距顯著縮小： M4 雲端 17 秒，M1 Pro 22 秒，M2 Air 38 秒（背景 Chrome 仍開著）。 增量建置只重編受影響模組，記憶體峰值不超過 5 GB，M2 Air 也不會 swap。

這意味著：如果你 90% 的時間在做小步迭代，本地 8 GB Air 完全夠用； 痛點集中在發版週、依賴大升級、或切換分支後的首次全量編譯。 很多團隊把「日常編碼留在本地、全量建置丟給 CI」—— 但若 CI 跑在 GitHub 代管 Runner 上，排隊時間往往比編譯本身還長（高峰 20 分鐘以上）， 體感並不比本地 Air 更好。固定一台雲端 M4 獨享機跑全量，是介於「本地硬扛」與「公共佇列」之間的第三條路。

發熱、風扇與「編譯時能不能幹別的」

編譯不只是碼錶問題，還影響並行工作流。我們在全量建置進行中記錄機身溫度與風扇轉速（M4 mini 透過外接溫感，筆電用內建感測器）：

M2 Air 無風扇設計在持續編譯場景下會主動降頻保護晶片—— 前 2 分鐘速度與 M1 Pro 接近，後 3 分鐘越拉越慢，這就是 7 分鐘總耗時的隱形來源。 雲端 Mac mini 是桌面散熱形態，M4 的 10 效能核可以長時間維持在高頻， 對你而言意味著：把全量編譯丟到 SSH 工作階段裡背景跑，本地 Windows 或 Linux 主力機繼續寫程式、開會、刷文件，互不干擾。

16 GB 統一記憶體：夠用與不夠用的分界線

本次專案的 Debug 全量建置峰值約 12.4 GB，落在 16 GB 機器的舒適區內。 當專案膨脹到 20 萬行以上、或同時開啟 Xcode + Simulators + Instruments 時， 16 GB 本地機也會踩線——我們在同一 M1 Pro 上疊加 iOS 17 模擬器跑 UI 測試， 峰值達到 15.6 GB 並出現 800 MB swap，全量編譯時間從 4m 18s 拉長到 5m 44s。

M2 Air 的 8 GB 則在編譯開始後 90 秒就觸及記憶體上限，系統開始積極壓縮與換頁。 memory_pressure 日誌裡出現大量 vm_compressor 事件， 編譯執行緒等待記憶體釋放，牆鐘時間被拉長近一倍。 這不是 Xcode「最佳化差」，而是物理記憶體硬頂—— 雲端 M4 的 16 GB 對多數中型 iOS 專案是「不 swap 的最低配」， 而不是過剩配置。

重現實測：腳本與計時注意點

你可以用下面最小腳本在自己的機器與雲端節點各跑一遍，結果寫入 CSV 方便對比。 在專案根目錄儲存為 scripts/bench_clean_build.sh：

#!/bin/bash
set -euo pipefail
SCHEME="MyApp"
WORKSPACE="MyApp.xcworkspace"
rm -rf ~/Library/Developer/Xcode/DerivedData/*
/usr/bin/time -l xcodebuild -workspace "$WORKSPACE" -scheme "$SCHEME" -configuration Debug clean build -destination 'generic/platform=iOS' -jobs "$(sysctl -n hw.ncpu)" 2>&1 | tee /tmp/xcode_bench.log
grep -E 'real|maximum resident set size' /tmp/xcode_bench.log

注意事項：首次在新機器上建置前先跑一遍 xcodebuild -runFirstLaunch； 確保 xcode-select -p 指向預期 Xcode； 計時期間不要手動開啟 Xcode GUI（會搶占 SourceKit 與索引程序）； 若對比雲端，透過 SSH 執行腳本，用 caffeinate -dims 防止合蓋休眠（筆電本地測試同樣適用）。 遠端桌面（VNC）僅用於觀察進度，不建議在 VNC 裡開 Xcode GUI 同時測命令列建置——圖形工作階段會額外佔用 1–2 GB 記憶體。

什麼時候把全量編譯挪到雲端 M4

升級本地 MacBook 到 M4 Pro 32 GB 要數千美元，而一年發版高峰可能只占幾十天。 若你的痛點是「每週一兩次全量 Archive 讓筆電燙到沒法放腿上」，而非「每次儲存都要等 30 秒」， 按天租用雲端獨享 M4 往往更經濟：$21.1/天、$57.1/週、$105.7/月，無合約鎖定， 付款後 1–5 分鐘開通，SSH 與瀏覽器 VNC 雙連線。

PixVPS 五地節點——新加坡、日本（東京）、韓國（首爾）、中國香港、美國東部——硬體同價； 台灣或港澳開發者連東京或新加坡節點 SSH 全量編譯，牆鐘與本地幾乎一致，只是把發熱與噪音留在機房。 可與 GitHub Actions 自架 Runner 或 Fastlane 腳本配合：本地 push 觸發雲端 xcodebuild archive， 編完傳回 .ipa 或直傳 TestFlight（流程細節見本站雲端 Mac Xcode CI/CD 實戰指南）。

另一種常見用法：主力機是 Windows，偶爾接 iOS 外包——不必為每月一兩次編譯買 MacBook， 發版週租兩天雲端 M4，裝 Xcode 與證書，完事即釋。16 GB 統一記憶體、1 Gbps 獨享頻寬、99.9% SLA， 7×24 真人支援，工單 1 小時內回覆。需要更大專案快取可加購 SSD +1TB（$2.9/天）； 多 App 夜間矩陣建置可參閱 Thunderbolt 5 並聯方案（$1.9/天起，80 Gbps 多機互聯）。

全量編譯測的不是「誰的晶片跑分高」，而是誰能穩定、可預期地在 5 分鐘內交卷且不犧牲並行工作流。 本地 MacBook 仍是最好的日常編碼終端；雲端 M4 獨享節點則是把「編譯高峰」從筆電上卸下來的專用算力—— 按天計費，不必為一年用幾十天的峰值買整機。