App 卡頓時，我讓 Agent 用 Instruments Skill 找原因

Syncnext 的「搜索」重構後，Apple TV 上的會明顯卡頓。

我把執行日誌交給 Agent，請它先分析、確認問題。

當時我也把搜尋併發當成懷疑方向。

看起來很麻煩的問題？

AI 看完日誌後，給我建議：

• JS Context 很多
• 可能存在 Promise 問題
• JavaScriptCore 生命週期是壓力

建議分三階段修，優先處理「無界排程」與「JSValue retain cycle」。不要先大改整個 Search UI。

如果只做一輪修復，我會選：有界雙 lane 排程 + JSPromise managed ownership + 對應回歸測試。這是風險最低、對卡頓改善最大的第一刀。

懷疑方向

我很好奇的想起 xcode 27 提供了一堆 Skil，就問起了 Skil 的問題，

就把 debugging-instruments 找到了，並且採集了性能數據。

然後 AI 在 Apple TV 真機上使用 Instruments 的 Time Profiler。

Instruments 找到繁簡轉換熱點

有效的 trace 抓到一次約 3.65 秒的 Severe Hang，其中約 88% 的時間花在 GBig.simplify——繁簡轉換函式。

沿著呼叫堆疊往回看，核心原因集中在一條很小的路徑：搜尋結果分批到達，每次讀取累積結果，都重新做匹配與繁簡轉換。已收到的結果被反覆處理，這些計算又在主執行緒上執行。

用快取修正，再驗證一次

看到這條路徑，我回它：

這是一個可 cache 的路徑。而不需要總是重做 繁簡 轉換。

接著讓它實作，並再用 debugging-instruments 驗證。修正很直接：搜尋關鍵字先處理一次，新結果到達時只匹配一次並保存結果，後續畫面更新直接讀取；繁簡轉換的對照表也改成字典查找。

在同一台 Apple TV、同一個搜尋關鍵字、同樣的 Debug 設定下重錄，搜尋期間的卡頓從 18 次降到 0 次，主執行緒 CPU 時間從 16.255 秒降到 1.477 秒。

結語

在當前的狀態下，AI 已經具備強大的推理能力。

但是，依然是證據很重要，如果跟隨 AI 的建議，我可能要做一次龐大的重構計劃。但是，這次直接找到 Hangs 的發生位置，就做也很小的修復就可以完成任務了。