RexCode logo
← AI 隨筆
2026-06-23

iPhone 15 又自己重開了一次:這次是 SpringBoard 卡死 180 秒

iPhone 15 Rebooted Again: This Time SpringBoard Hung for 180 Seconds

同一支 iPhone 15、隔天又自己重開一次——但這次跟過熱無關。log 顯示是 userspace watchdog timeout:負責桌面的 SpringBoard 卡住 180 秒沒回報,系統為了自救強制重開。這篇把這次的狀況講清楚。

iPhone 15 Watchdog Timeout SpringBoard log 解讀

📌 一句話結論

這次不是過熱。log 顯示是一次 userspace watchdog timeout:負責整個桌面與 UI 的 SpringBoard 行程卡住了,連續 180 秒沒向系統「回報還活著」。其他系統服務(藍牙、音訊、Wi-Fi、溫度監控…)全都正常運作,所以系統判定是 SpringBoard 自己鎖死,為了把畫面救回來,由軟體層的看門狗強制重開。簡單說:這是一次「桌面卡死 → 自動重啟」,不是手機壞掉。

🕓 當時的情況

事發時間是 下午 16:27,手機已經開機運作約 15 小時(log 裡的 uptime 約 53,815 秒)。這次不是在大太陽下、也沒有滿載錄影——跟前一天那次「正午高溫熱當機」的情境完全不同。

體感上就是:畫面突然卡住、點什麼都沒反應,過了一段時間(約 3 分鐘)手機自己黑屏重開,重開後一切正常。

🔍 這份 log 在說什麼

① 關鍵那一行

userspace watchdog timeout: no successful checkins from SpringBoard (1 induced crashes) in 180 seconds

翻成白話:iOS 內部有個「看門狗」會要求每個重要服務定期「打卡報平安」。這行說的是——SpringBoard 已經 180 秒沒打卡了,看門狗認定它徹底卡死。後面那句 (1 induced crashes) 代表系統其實先試過「踹它一腳叫它重來」一次,沒救回來,最後才走到整機重開。

② 為什麼確定是 SpringBoard、不是別的

log 很貼心地列出所有受監控服務的「最後打卡時間」。除了 SpringBoard 是 180 秒前,其餘全部都是 0 秒前(剛剛才打卡):

backboardd、audiomxd、logd、thermalmonitord、runningboardd、wifid、configd、CommCenter → 全部 0 秒前正常。

這代表系統的「地基」其實都活得好好的,唯獨最上層的桌面(SpringBoard)卡住。問題集中在 UI 層,不是底層硬體或核心。

③ 這次跟「過熱」無關

負責監控溫度的 thermalmonitord 也是 0 秒前正常打卡,沒有任何過熱降頻的跡象。所以這次跟前一天那次「高溫熱當機」是兩種不同的當機:上次是硬體看門狗在關機過程被熱逼到極限,這次是軟體看門狗發現桌面卡死。

🤔 SpringBoard 為什麼會卡死

SpringBoard 是 iOS 的「桌面大腦」——主畫面、App 切換、通知、鎖定畫面、狀態列全都歸它管。它一旦卡住,整支手機看起來就像「死當」。常見的卡死原因有幾類:

· 主執行緒被卡住:某個動畫、某個畫面渲染、或等待某個系統回應時陷入鎖死(deadlock)或無限等待,導致 UI 執行緒動不了。

· 資源吃緊:長時間開機(這次約 15 小時)累積記憶體碎片、太多 App 在背景,瞬間的資源壓力讓 SpringBoard 反應不過來。

· iOS 本身的 bug:某些版本在特定情境(例如某個通知、某個外接裝置、某個 widget)會偶發讓 SpringBoard 卡住,屬於系統層級的偶發事件。

從這份 log 無法 100% 鎖定是哪一個,但可以確定:這是軟體層的偶發卡死,不是硬體損壞。

🛠️ 該怎麼處理

✅ 三個建議

1. 偶發一次:當成正常自我修復。重開後一切正常,就代表 iOS 的看門狗成功把卡死的桌面救回來了,這正是它該做的事,不用焦慮。

2. 偶爾手動重開機。長時間不關機(這次 15 小時其實不算長,但習慣養成有幫助),偶爾重開可以清掉累積的記憶體與背景狀態,降低 SpringBoard 卡死的機率。

3. 若「頻繁」發生才需要進一步查。如果一天卡死好幾次,再依序排查:更新到最新 iOS、移除最近新裝/可疑的 App 或 widget、必要時備份後「重置所有設定」。單一一次不必走到這步。

📄 Crash log(關鍵段落 · 已遮蔽)

以下是這次 panic 的關鍵段落(panic header + 服務打卡清單)。為了隱私,已遮蔽 incident_idcrashReporterKey 與所有 UUID。後面上萬行的 thread dump 與本次原因無關,已省略。

{"bug_type":"210","timestamp":"2026-06-23 16:27:39.00 +0800","os_version":"iPhone OS 26.5 (23F77)","incident_id":"████████-████-████-████-████████████"}
{
  "crashReporterKey" : "████████████████████████████████████████",
  "product" : "iPhone15,5",
  "kernel" : "Darwin Kernel Version 25.5.0: ... RELEASE_ARM64_T8120",
  "panicString" : "panic(cpu 0 caller 0x...): userspace watchdog timeout: no successful checkins from SpringBoard (1 induced crashes) in 180 seconds
service: backboardd,       last successful checkin: 0 seconds ago
service: SpringBoard (1 induced crashes), last successful checkin: 180 seconds ago
service: audiomxd,         last successful checkin: 0 seconds ago
service: logd,             last successful checkin: 0 seconds ago
service: thermalmonitord,  last successful checkin: 0 seconds ago
service: runningboardd,    last successful checkin: 0 seconds ago
service: wifid,            last successful checkin: 0 seconds ago
service: configd,          last successful checkin: 0 seconds ago
service: CommCenter,       last successful checkin: 0 seconds ago
...
",
  "socId" : "8120",
  "build" : "iPhone OS 26.5 (23F77)",
  "bug_type" : "210"
  ... (processByPid 完整 thread dump 共上萬行,與本次原因無關,此處省略 / full thread dump omitted) ...
}
分析方法:依 panic 的 panicString 與各服務的 checkin 時間判讀。本次為 userspace watchdog timeout(SpringBoard 卡死),與前一天的「高溫硬體看門狗重開」是不同事件,詳見 上一篇:烈日下錄影黑屏重開。kernel panic 不必然代表硬體故障,多數情況是系統自我保護的安全重開。