為什麼「編譯慢」往往不是 Xcode 的鍋
在開發者社群裡，「Xcode 又卡了」是最常見的吐槽之一。但把同一份工程放到不同機器上跑， 總耗時可以差出兩三倍——這說明瓶頸往往在硬體資源與散熱，而不是編譯器本身寫得多爛。 典型場景包括：8 GB 記憶體的 MacBook Air 在 clean build 時觸發 swap，連結階段耗時翻倍； 老款 Intel MacBook Pro 風扇拉滿後 CPU 降頻；或者你一邊開著模擬器、Chrome 二十個分頁、 Slack 和 AI 程式設計工具，一邊點 Product → Archive，記憶體爭用讓 Swift 並行編譯根本跑不滿核。
雲端 Mac 的價值，不在於 magically 讓 Xcode 變快，而在於把編譯從日常辦公筆電上剝離出去：
專用機器、固定環境、無人值守時也不會因為合蓋或省電策略中斷任務。
這篇對比聚焦「全量編譯」——每次 rm -rf DerivedData 後的 Release Archive——
因為這是最能拉開機器差距、也最能體現記憶體與散熱上限的場景。
樣例工程：SwiftUI 中型 App（約 11.6 萬行 Swift，含 1 個 Widget Extension、1 個 Notification Service Extension；約 42 個 Swift Package 依賴）。
建置命令：xcodebuild clean archive -workspace RetailApp.xcworkspace -scheme RetailApp -configuration Release -destination 'generic/platform=iOS'
工具鏈：Xcode 16.4，macOS 15 Sequoia；每台機器各跑 3 輪，取中位數；輪次間重啟 Xcode 並清空 DerivedData。
對照組 A：MacBook Air 13" M2 · 8 GB · 256 GB（電池供電，室溫約 26°C）。
對照組 B：MacBook Pro 14" M3 Pro · 18 GB · 512 GB（接電源，室溫約 24°C）。
對照組 C：ZovCloud Mac mini M4 · 10 核 · 16 GB · 256 GB NVMe · 1 Gbps 獨享頻寬（新加坡節點，SSH 遠端觸發）。
測試方法：如何保證對比公平
效能對比最容易翻車的地方是「每台機器狀態不一樣」。我們固定了以下變數，盡量讓數字只反映硬體差異：
-
01
同一 Git commit，同一分支
三臺機器均
git checkout v2.4.0-buildbench，鎖定Package.resolved，避免 SPM 解析版本漂移。雲端節點透過 SSH 克隆私有倉庫，使用唯讀 Deploy Key。 -
02
真正的 clean build
每輪開始前執行
rm -rf ~/Library/Developer/Xcode/DerivedData與xcodebuild clean。不保留增量快取，模擬 CI 發版前的全量建置。 -
03
用
/usr/bin/time -l記錄總耗時與峰值記憶體腳本包裝
xcodebuild，輸出 real/user/sys 與 maximum resident set size。筆電端額外用 Activity Monitor 觀察 swap 與 CPU 溫度（透過powermetrics取樣）。 -
04
筆電關閉無關負載
測試期間不執行模擬器、瀏覽器與通訊軟體。現實中你很難做到——這正是後文「日常開發場景」要單獨討論的原因。
日常 ⌘B 的 Debug build 通常比 Release Archive 快 40–55%，且不會做完整的 bitcode / 最佳化連結。
我們選擇 Archive 是因為發版、TestFlight 與 CI 流水線最終都落在這裡——讀者更關心「今晚能不能打出包」，而不是「改一行程式碼要幾秒」。
全量 Archive 總耗時：三輪中位數
下表是三臺機器各跑三輪 clean Archive 的中位數。雲端 M4 與 M3 Pro 差距不大， 但 M4 在連結階段更穩定——三輪波動僅 ±4 秒；M3 Pro 有一輪因短暫降頻慢了 22 秒。 MacBook Air M2 8 GB 則是另一番景象：編譯中期開始大量使用 swap，連結階段 CPU 利用率長期低於 40%。
| 機器 | Archive 中位數 | 峰值記憶體 | 是否觸發 swap | 編譯階段 CPU 利用率 |
|---|---|---|---|---|
| MacBook Air M2 · 8 GB | 9 分 41 秒 | 7.8 GB + 4.2 GB swap | 是（三輪均觸發） | 峰值 68%，連結期降至 35–45% |
| MacBook Pro M3 Pro · 18 GB | 4 分 18 秒 | 14.1 GB | 否 | 峰值 92%，偶發降頻 |
| ZovCloud Mac mini M4 · 16 GB | 3 分 52 秒 | 12.6 GB | 否 | 峰值 96%，波動小 |
幾個值得細讀的數字：M4 比 M3 Pro 快約 10%，主要贏在 Swift 並行編譯能持續吃滿 10 個效能相關核心， 且 Mac mini 的散熱餘量比 14 吋筆電更充裕，長時間滿載不易降頻。 Air M2 並非 CPU 絕對慢——單核效能並不差——而是8 GB 記憶體在 2026 年的中型工程上已經明顯不夠， SPM 依賴一多，編譯器行程 + 連結器 + 系統快取輕鬆突破實體記憶體上限。
增量編譯與日常改程式碼：差距會縮小嗎？
全量 clean build 是壓力測試；日常開發更多是改幾個檔案後的增量編譯。 我們額外測了「修改一個 SwiftUI View 檔案後 Debug build」的耗時（保留 DerivedData）：
| 場景 | MacBook Air M2 | MacBook Pro M3 Pro | ZovCloud M4 |
|---|---|---|---|
| 單檔案增量 Debug build | 18–24 秒 | 11–14 秒 | 13–16 秒（含 SSH 觸發開銷） |
| 修改 SPM 依賴後全量解析 | 2 分 05 秒 | 1 分 12 秒 | 1 分 08 秒 |
| 同時開 iOS 模擬器 + 增量 build | 經常失敗或超 3 分鐘 | 38–52 秒 | 不適用（雲端不跑本地模擬器） |
增量場景下，本地 M3 Pro 往往比遠端 M4 更快——因為沒有網路往返，檔案系統也在本地 NVMe 上。 雲端 Mac 的優勢不在「改一行程式碼的回饋速度」，而在「不佔用你正在寫程式碼的那臺機器」： 把全量 Archive、夜間批次測試、多 scheme 打包丟到雲端，筆電繼續流暢跑模擬器與 IDE。 若你用的是 8 GB Air，連增量 build 在模擬器開著時都不穩定，拆分工作負載的收益更明顯。
發熱、風扇與「編譯時能不能好好寫程式碼」
總耗時只是一半故事。我們在每台機器編譯期間記錄了機身溫度與風扇轉速（Air 無風扇，以核心溫度與降頻代替）：
MacBook Air M2：編譯約 2 分鐘後 CPU 溫度升至 95°C 以上，出現明顯降頻； 鍵盤區域燙手，無法同時舒適打字。三輪測試後機身熱量殘留，後續增量 build 仍比冷機慢 8–12%。
MacBook Pro M3 Pro：風扇在編譯 30 秒後升至 4500–5200 RPM，噪音明顯； 接電源時效能穩定，但人耳可聞的風扇聲足以打斷影片會議。峰值溫度約 88°C，未嚴重降頻。
ZovCloud Mac mini M4：機房環境溫度恆定，編譯全程風扇轉速維持在低速區間（約 1800–2200 RPM）， 透過 SSH 遠端觸發時本地零噪音、零發熱。對我們這種「筆電就是唯一辦公裝置」的開發者來說， 這一點往往比快 30 秒更重要。
頻繁讓 MacBook 在 90°C 以上跑滿，會加速電池老化與鍵盤塗層磨損——很難量化，但在 2–3 年持有週期裡會轉化為維修或換機成本。 把重編譯挪到雲端，本質是保護你的主力裝置壽命，而不只是買幾分鐘速度。
遠端編譯工作流：SSH 觸發與結果回傳
測完效能，接下來是「怎麼用」。雲端 M4 在新加坡節點，測試者本地網路到機房的 SSH 往返約 38 ms（臺灣家用光纖）。 我們沒有在雲端開 Xcode GUI（VNC 可用，但日常沒必要），而是用腳本觸發編譯：
ssh zovcloud@node 'cd ~/RetailApp && git pull && ./scripts/ci-archive.sh'
ci-archive.sh 內部呼叫 xcodebuild archive，完成後把 .xcarchive 或匯出的 .ipa 透過 scp 拉回本地，
或上傳到團隊內網物件儲存。全鏈路（pull + clean archive + scp 180 MB 產物）總耗時約 5 分 10 秒——
仍快於 Air M2 本地編譯，與 M3 Pro 本地接近。
若你使用 GitHub Actions 或 Fastlane，可以把雲端 Mac 註冊為 self-hosted Runner（詳見本站 雲端 Mac Xcode CI/CD 實戰指南）， push 後自動在 M4 上編譯，本地完全無感。對於「只在發版日需要全量建置」的團隊，按天租用、用完即釋，比全年讓筆電當編譯機更划算。
成本對照：什麼時候值得為編譯單獨買一台機器
把效能數字換算成決策，需要同時看頻率與預算。假設每月 8 次全量 Archive（發版 + 熱修復）， 其餘時間做增量開發：
| 方案 | 單次全量 Archive 體驗 | 典型月成本 | 適合誰 |
|---|---|---|---|
| 繼續用 8 GB MacBook Air | 9+ 分鐘，swap，機身發燙 | $0 額外 | 業餘專案、極低頻發版 |
| 升級到 M3 Pro 筆電 | 4 分鐘左右，風扇吵 | 硬體 $2000+ 一次性 | 高頻本地開發 + 模擬器 |
| 發版日租用 ZovCloud M4（按天） | 約 4 分鐘，本地零負載 | 8 天 × $19.8 ≈ $158 | 已有筆電，月發版數次 |
| 常駐雲端 M4（按月） | 隨時可編，可當 CI Runner | $99.1 / 月 | 每天多次 push、小團隊 CI |
若你已經是 M3 Pro 使用者，雲端 M4 的編譯速度提升有限（約 10%），核心價值變成工作負載隔離與 CI 穩定。 若你還在 8 GB Air 上硬扛中型工程，雲端編譯幾乎是「立刻能感知」的體驗升級—— 單次建置從近 10 分鐘降到 4 分鐘以內，且筆電可以繼續跑模擬器查 UI。
把重編譯遷到雲端：實操路徑與選型建議
很多開發者並非沒有聽說過「雲端 Mac」，而是卡在兩個疑問：遠端會不會比本地更慢？按月租一台是不是浪費？ 這次實測給出的答案比較清晰： 全量 Release Archive 場景下，ZovCloud 獨享 M4 與高階 MacBook Pro 同檔，遠快於 8 GB 入門機型； 增量 Debug 仍建議本地；真正該上雲的是「clean build、Archive、夜間批次任務」這些吃資源的高峰。
ZovCloud 提供獨享物理 Mac mini M4（10 核 CPU、16 GB 統一記憶體、256 GB NVMe、1 Gbps 獨享頻寬）， 不做虛擬化、不超售。付款後 1–5 分鐘自動開通，五地節點可選——新加坡、日本、韓國、中國香港、美國東部。 按天 $19.8 起，無長期合約；發版週開通、淡季釋放，比為編譯單獨買一台 Mac mini 放家裡更省心。
連線方式三種：瀏覽器 VNC（臨時排除）、SSH（腳本觸發編譯，推薦）、掛載為 GitHub Actions / Jenkins Runner（團隊 CI）。 需要多 App 並行 Archive 時，可選購 Thunderbolt 5 並聯服務組叢集（參見 TB5 叢集實測）。
-
01
評估你的瓶頸在哪
8 GB swap → 優先遷全量建置；M3 Pro 但仍被 CI 佔用 → 遷夜間批次任務；主要痛點是排隊 → 直接掛 Runner。
-
02
選節點並開通
使用者主要在東南亞選新加坡；面向日本市場選東京。控制台付款後 SSH 憑據自動下發，詳見幫助中心。
-
03
同步工程與簽名環境
克隆倉庫、匯入 Distribution 憑證、跑通首次 Archive。把腳本固化進倉庫，後續本地一條命令觸發雲端編譯。
編譯效能沒有銀彈：雲端不會讓你的 Debug 增量快 10 倍，本地旗艦筆電也不會因為換了 Xcode 就告別風扇噪音。 理性做法是把互動式開發留在本地、把資源密集型建置交給專用機器—— 而 ZovCloud 這類按天計費的獨享 M4，正好填了「不想買第二臺 Mac、又不想筆電變成暖手寶」的空檔。