Xcode 全量編譯實測：本機 MacBook 與雲端 M4 獨享節點誰更快？

為什麼本機 MacBook 編譯越來越慢？

不少獨立開發者的主力機是 MacBook Air 或入門款 MacBook Pro：輕薄、續航佳，但記憶體常見 8 GB 或 16 GB。 當你同時開著 Xcode、Simulator、Chrome（十幾個分頁）、Slack 與 Preview， 留給 swift-frontend 與 ld 的實體記憶體已所剩無幾。 系統開始把 DerivedData 與索引快取換出到 SSD——表面上只是「多等幾分鐘」， 實際上是記憶體頻寬被 swap 吃掉，之後每一次增量建置都會更慢。

另一個常被忽略的變因是熱節流。筆電散熱空間有限，全量編譯持續 8–15 分鐘後， CPU 頻率可能從峰值回落 15–25%，風扇噪音也會干擾視訊會議。 雲端 Mac mini 放在機房機架上，散熱條件穩定，更適合當「專職編譯機」—— 本機專心寫程式，重負載交給遠端物理節點。

本文要回答的問題很具體：在真實專案規模下，把編譯搬到 SpinMac 雲端 M4 獨享節點，能快多少？ 代價是什麼？哪些情境不值得上雲？

測試環境與方法論

為確保結果可複現，兩邊使用相同 Xcode 版本、相同 DerivedData 清理流程， 並透過 xcodebuild 命令列計時（/usr/bin/time -l）， 避免 Xcode GUI 偶發的索引或背景任務干擾。每輪測試前執行 rm -rf ~/Library/Developer/Xcode/DerivedData/*，並關閉非必要 App。

測試專案為自研 SwiftUI App「PulseTrack」：約 8.2 萬行 Swift，含主 App、Share Extension、 Widget Extension 與 Watch App 共 4 個 target；透過 Swift Package Manager 引入 6 個第三方套件 （含 Alamofire、Kingfisher 等）。屬於中型商業 App 的常見體量——不算超大 monorepo，但足以讓 8 GB 機器吃力。

三組建置情境與指令

我們設計三種開發者每天都會遇到的建置類型，涵蓋日常迭代到上架發佈的完整路徑。

情境一：全量 Clean Build（Debug）

模擬 CI 首次 checkout 或切換分支後的冷啟動編譯。指令如下：

xcodebuild -scheme PulseTrack -configuration Debug -destination 'platform=iOS Simulator,name=iPhone 16 Pro' clean build CODE_SIGNING_ALLOWED=NO

關閉簽名可排除憑證與鑰匙圈差異，專注比較編譯本身。每台機器連續跑 3 次取中位數。

情境二：單檔增量建置

修改一個 Swift 原始檔（約 40 行 UI 邏輯變更）後，不執行 clean，直接 build。 這是日常開發頻率最高的操作，對記憶體餘量與索引狀態極為敏感。

情境三：Release Archive

使用 Distribution 憑證執行完整 Archive，開啟編譯器最佳化（-O）與 bitcode 剝離。 此情境 CPU 佔用時間最長，也是本機筆電最容易觸發降頻的情境。

耗時對比：核心數據

下表為三輪測試中位數。雲端 M4 在三項情境均領先，且優勢在 Archive 最明顯—— 編譯器最佳化階段需要長時間滿載，雲端散熱穩定、無降頻。

MacBook Air M2 在全量編譯進行到第 6 分鐘時出現明顯 swap（memory_pressure 回報 system-wide memory free percentage 跌至 4%），隨後 swift-frontend 行程 平均 CPU 利用率從 680%（多核合計）降至約 420%。這不是 Xcode 變慢，是系統在換頁。 雲端 M4 全程實體記憶體充足，10 核在編譯峰值期維持 85–92% 利用率，無降頻紀錄。

值得注意的是：M1 Pro 16 GB 本機的全量編譯僅比雲端 M4 慢約 34%，差距小於 Air 8 GB 的 2.2 倍。 這表示記憶體容量往往比晶片世代更早成為瓶頸。若你已擁有 16 GB 以上的本機， 雲端價值更多體現在「專職編譯、不干擾日常」，而非絕對速度碾壓。

並行負載：Simulator + 編譯的真實情境

上表是「乾淨環境」下的理想數據。更貼近日常的是：開著 iOS Simulator 預覽 UI， 同時觸發一次全量編譯（例如切換 Build Configuration 或清理 DerivedData 後重建）。

在此組合負載下，MacBook Air M2 的 Simulator 多次出現幀率跌至 20 fps 以下， 編譯時間從 11′42″ 延長至 14′28″；M1 Pro 延長至 8′45″，仍可用。 雲端 M4 在 VNC 遠端預覽 Simulator 的同時編譯，耗時僅增加約 40 秒（5′58″）， 因為 Simulator 與編譯行程各自有充足的記憶體與 CPU 餘量，互不干擾。

我們也記錄了 DerivedData 體積：三輪全量編譯後，本機 Air 的 DerivedData 達 4.7 GB， 在 256 GB 硬碟上尚可接受，但搭配 8 GB 記憶體會讓索引快取與編譯產物搶空間。 雲端節點可選購 +1 TB SSD 擴容（按日 $2.5 起），適合需要保留多分支建置快取的團隊。

踩坑紀錄：讓對比失效的幾個變因

複現測試時，以下細節若不一致，結果可能相差 30% 以上：

1. 01
   索引未完成就觸發編譯

   Xcode 首次開啟專案時，背景索引可能佔用 2–4 GB 記憶體。應等索引进度結束，或透過 xcodebuild 繞過 GUI 索引。

2. 02
   Build System 設定不一致

   確認兩邊均使用 New Build System，且 COMPILER_INDEX_STORE_ENABLE 設定相同；否則增量建置時間無可比性。

3. 03
   雲端原始碼同步方式

   用 rsync --delete 保持工作區一致；避免在編譯中途透過 FUSE 網碟掛載原始碼，網路 I/O 會成為隱形瓶頸。

4. 04
   模擬器架構差異

   Apple Silicon 模擬器預設建置 arm64 slice；若一台機器額外建置 x86_64，耗時可能接近翻倍。

遠端編譯工作流：本機寫程式，雲端跑建置

若你用的是 8 GB 或需要兼顧會議與開發的 16 GB 筆電，不必賣掉本機去換 Mac Studio。 更務實的做法是：把 Xcode 編譯與 Simulator 重負載遷到雲端，本機只保留編輯器與 Git。

典型痛點是這樣的：下午三點要 Demo，同事剛 push 了一個需要全量編譯的分支， 你的 Air 風扇拉滿、Google Meet 畫面開始卡頓——這不是技術問題，是算力被編譯搶走了。 雲端 M4 節點按天計費（$21.2 起），發版週開通、日常關閉，往往比升級筆電更划算。

1. 01
   開通 SpinMac 節點

   在控制台選擇就近區域（新加坡 / 日本 / 韓國 / 中國香港 / 美國東部），付款後 1–5 分鐘取得 SSH 與 VNC 入口。詳見說明中心。

2. 02
   同步程式碼與相依套件

   首次用 rsync -avz --exclude DerivedData ./ user@host:~/PulseTrack/ 推送儲存庫；SPM 相依在雲端執行 xcodebuild -resolvePackageDependencies 解析。

3. 03
   本機編輯，遠端建置

   可用 VS Code Remote SSH 或 Cursor Remote 編輯遠端檔案；編譯指令在 SSH 工作階段執行。需要 UI 預覽時透過瀏覽器 VNC 開啟 Simulator。

4. 04
   掛載為 CI Runner（選用）

   若團隊需要自動化建置，同一節點可註冊 GitHub Actions self-hosted runner。設定步驟見雲端 Mac Xcode CI/CD 實戰指南。

五個節點均提供 1 Gbps 獨享頻寬與獨立公網 IPv4。我們在台北辦公網路對新加坡節點做 rsync 增量同步 （約 120 個變更檔案），耗時 3–6 秒，對增量建置流程幾乎無感。 若你在台灣或港澳開發、使用者主要在亞太，新加坡或日本節點通常是延遲與頻寬的平衡點；距離更近可優先選中國香港節點。

成本與選型：什麼時候值得上雲？

簡單算一筆帳：一次全量編譯從 12 分鐘縮到 5 分鐘，每天 6 次建置可節省約 42 分鐘。 以開發者時薪估算，半天即可覆蓋一天 $21.2 的節點費用——還沒計入風扇噪音、會議卡頓與電池損耗的隱性成本。 雲端方案不是取代本機開發機，而是給編譯任務一台不被打擾的專職物理機。

若你正計畫把建置鏈路自動化，建議繼續閱讀 GitHub Actions 與 Jenkins 實戰指南； 需要多機並行 Archive 時，可參考 Thunderbolt 5 叢集實測。