操作 App 時畫面停頓，或非同步工作看似沒有依預期執行？
本週建議：用 Swift Executors instrument 固定重現步驟並錄製軌跡，再把可疑時間段對回程式碼；它能協助縮小排查範圍，不能自動證明根因，也不能取代重複驗證。
本文適合正在調查 Swift Task、Main Actor 或自訂執行器行為的 iOS、macOS 獨立開發者與小型團隊。
如果你只是想知道 App 為何卡頓，卻尚未建立可重做的操作條件，先從下方的復現紀錄開始。
最後更新於 2026 年 10 月 27 日；功能範圍與工具說明核對自 Apple Xcode 27 發布說明、Xcode 系統需求及 Instruments 工具資料。實際操作畫面與支援範圍仍應以你使用的 Xcode 版本為準。
SECTION 01 分析前：先把「卡住」變成可重現的症狀
不要一開始就把畫面停頓判定為執行器故障。先說清楚你要觀察的是任務的生命週期、執行器活動，還是主執行路徑；這三者可能同時出現在一段操作中，但不代表原因相同。
替問題寫一張簡短的復現紀錄，內容至少包含：
- 啟動 App 後要執行的操作，以及操作順序。
- 問題在哪個畫面或工作階段出現，使用者實際看見什麼。
- 預期行為與實際行為的差異，例如載入未結束、按鈕沒有回應，或資料更新延遲。
- 你準備在軌跡中留意的任務或執行器活動，以及能確認症狀是否再現的觀察點。
Swift Executors instrument 能看見哪些並發資訊？
依 Apple 對 Xcode 27 的說明，這項 instrument 可用來觀察執行器與執行緒池的軌跡；它提供的是執行活動的觀察線索，不是直接指出哪一行程式碼出錯的報告。功能敘述可參考 Xcode 27 發布說明與 Apple 的 WWDC 26 Instruments 分析示範。
SECTION 02 錄製前：確認工具鏈與目標環境
建置成功不等於分析環境已就緒。開始前先確認目前使用的 Xcode、Instruments、專案 SDK 與目標執行環境彼此相容；Apple 的系統需求會隨 Xcode 版本而變動，應直接核對目前的 Xcode 系統需求，不要依賴舊專案的安裝紀錄推定支援範圍。
接著確認專案可以在目標環境啟動，且分析時能辨識應用程式與可用的符號資訊。若你只安裝命令列工具，請先查閱 Apple 的命令列工具安裝說明及 Xcode 命令列工具參考，確認手上的工具是否符合這次要做的分析；不要假設命令列工具的存在就代表完整 Instruments 工作流程已可用。
如果你找不到選取目標或載入軌跡的預期介面，先核對 Xcode 版本與所選目標，再依該版本的官方說明調整操作。不要只因專案能編譯，就把問題歸因於 App 本身。
| 選項 | 適合的情況 | 開始分析前要確認 | 主要取捨 |
|---|---|---|---|
| 本機 Mac | 你已有符合需求的 Mac，且能在同一環境重現問題 | Xcode、Instruments、SDK 與目標執行環境是否相容 | 操作直接，但會占用本機資源；工具與專案環境由你維護 |
| 遠端 Mac | 你沒有本機 Mac，或想把分析環境與日常工作分開 | 遠端環境是否能使用所需工具、啟動 App，並保存軌跡與符號資料 | 不必先購買實機，但需考量連線方式、環境管理與資料交接 |
| 僅使用 CI 或既有記錄 | 你要先確認建置或自動化流程中的問題 | 現有產物是否包含能回答並發疑問的證據 | 適合檢查流程結果；若缺少互動式分析所需資料，仍可能要另行重現 |
SECTION 03 開始錄製：每次軌跡都對應一組操作
在 Instruments 中選擇 Swift Executors instrument，指定可供分析的目標 App，然後執行事先寫好的復現步驟。選擇方式與可用軌跡項目可能隨工具版本而異，請以 Apple 的 Xcode 27 說明及 WWDC 26 分析示範核對，不要把某個版本的介面名稱當成所有版本都相同。
錄製時避免同時加入未記錄的測試操作。若一次軌跡包含多種不同場景，事後很難判斷可疑活動究竟對應哪項操作。每次完成後，為軌跡檔案記下專案版本、Xcode 與目標環境、復現步驟、預期和實際現象；這些上下文能讓你重新開啟檔案時知道它代表什麼。
提醒：軌跡是特定執行條件下的觀察紀錄。若復現步驟、App 狀態或分析環境不同，兩次記錄就不宜直接當成同條件比較。
SECTION 04 讀取軌跡：先辨認活動，再提出假設
閱讀時，先用操作時間點定位，而不是先搜尋「哪條線看起來最忙」。把軌跡中可辨識的任務活動、執行緒池、Main Actor 或自訂執行器線索，對照復現紀錄中的事件：使用者何時開始操作、畫面何時停頓、背景工作何時開始或結束。
具體名稱、顯示方式與可觀察內容應按對應版本核實，不能把某種圖表外觀當作穩定的跨版本規則。若你正在調查主執行緒相關工作，可先觀察相關活動的時間段，再對照 App 的畫面症狀和程式碼；不要只憑一條軌跡線就推斷 UI 問題的來源。
怎麼在 Instruments 中找到 Main Actor 相關任務？
先以同一組操作重現問題，再在軌跡中檢視可辨識的 Main Actor 活動與對應時間段，並核對該版本實際呈現的欄位。之後把觀察到的時點對回畫面症狀和程式碼；不要只因活動出現在 Main Actor 附近，就認定主執行路徑是唯一根因。
SECTION 05 定位線索：用程式碼與產品行為交叉驗證
從可疑區段回到實際執行的程式碼，檢查相關任務如何建立、等待、取消或交接工作，並確認觀察到的區段確實對應你記錄的操作。接著選擇能回答假設的檢查方式，例如檢視相關呼叫路徑、增加針對性測試，或再次執行同一復現步驟。
Swift Executors instrument 的軌跡能直接證明程式碼根因嗎？
不能。軌跡可以指出值得檢查的時間段與執行器活動，但不足以單獨證明某段程式碼造成問題；你仍要把它和程式碼路徑、復現條件及使用者實際看到的結果對照。若線索彼此不吻合，調整復現步驟或補充其他診斷資料，比對單張圖下結論更可靠。
如果分析問題已進入持續整合與交付流程，可參考這篇關於 macOS CI 中 SBOM 產物管理的說明，釐清軌跡與建置交付資料各自回答什麼問題；不要把發布流程產物當成並發行為的直接證據。
SECTION 06 復測驗收：用同條件確認問題是否改變
修改完成後，回到原本的復現紀錄，以相同操作重新執行並錄製。比較修正前後與問題相關的任務或執行器活動，以及 App 實際表現；如果操作、目標環境或工具版本已有變化，先記下差異，再判斷兩份軌跡是否能直接比較。
驗收紀錄應保留工具版本、目標環境、復現步驟和觀察結果。若症狀不再出現，也要記錄你測了什麼，而不是只寫「已修復」；若症狀仍在但軌跡沒有提供新線索，調整觀察問題或補上其他證據，不要把沒有明顯變化當成根因已排除。
沒有本機 Mac，怎麼重現 Xcode 並發分析？
先確認你能取得可執行所需 Xcode 與 Instruments 的 macOS 環境，並能將專案、符號資料與軌跡檔案安全地放入及取回。遠端環境是否符合你的目標版本與工作流程，需要逐項確認；不要預設每種遠端連線都支援相同的操作，也不要在未測試前承諾可得到特定分析結果。
就方案取捨而言，單靠 Windows 或 Linux 開發環境，無法取代需要 macOS 工具鏈的分析步驟；只依賴 CI 記錄，可能缺少重現互動症狀所需的操作脈絡；而專門購買一台 Mac，則可能讓偶爾使用 Instruments 的開發者承擔閒置與維護成本。若你需要反覆執行 Xcode 分析、但尚未決定長期購置實機，可以先查看 VPSNIX 的方案資訊，確認可用環境與使用方式是否符合你的專案需求；若你會長期高負載使用，或必須直接連接特定實體裝置，仍應先評估自有 Mac 是否更合適。