# PiP 保活模式渲染效能
## 發現與修正
- 保活目標為 0.2 FPS，但排程以 `1 / max(currentFPS, 1)` 計算，實際至少每秒喚醒一次。現在使用完整低幀率值，無覆蓋層時每 5 秒更新一次時間畫面。
- 遞迴 `asyncAfter` 沒有取消控制代次；停止後立即重啟會讓舊 callback 通過共用布林檢查，可能增加渲染迴圈。現在取消待執行工作並使舊代次失效，在主執行緒進入及離開渲染時都確認代次。
- `rescheduleRenderTimer` 原本是空函式。現在真正提前下一次更新，重複事件不會持續推遲畫面更新。
- 聊天、觀眾數及一般版面更新不再提升純保活畫面的幀率。保活模式原本不顯示聊天，現在也直接跳過聊天加入流程。
- 贊助覆蓋層顯示期間維持 6 FPS 以支援翻頁與淡出；結束時立即補畫保活畫面，再回到 0.2 FPS。
- 原本每次成功重繪都刷新活動時間，連時鐘重繪也會阻止聊天模式降頻。現在只用內容／動畫活動更新活動時間。
- 停止時清除快取像素緩衝；舊工作階段的 attach、啟動與停止回呼不會干擾新工作階段。
- 第一幀立即送出，不需等 5 秒才嘗試啟動 PiP。
## 驗證
`liveAPPTests/PIPRenderPolicyTests.swift` 檢查低幀率換算、保活忽略聊天活動、覆蓋層結束降頻、聊天降頻、無效幀率及停止／重啟後舊排程代次失效。
開啟 PiP 日誌後，每約 60 秒記錄一次渲染統計，包含模式、目標 FPS、排程次數、重繪與送幀數。統計共用原有渲染排程，不增加計時器。
在 iPhone 上仍需執行：
1. 開啟「保活組」，無贊助訊息時觀察 2–3 分鐘；每分鐘應約 12 次更新，啟動及回到前景可多一次。
2. 持續傳送聊天室訊息與觀眾數更新，確認保活仍約 0.2 FPS。
3. 傳送多頁贊助訊息，確認顯示、翻頁與淡出正常，結束後恢復每 5 秒更新。
4. 連續停止／啟動十次、切換聊天與保活模式，確認排程次數未累加且新 PiP 不會被舊停止回呼關閉。
5. 背景維持至少十分鐘，檢查 PiP 與 Socket 可用性；切回前景確認立即更新。
6. 用 Instruments Time Profiler／Energy Log 比較相同裝置、亮度及訊息流量下的 CPU 與喚醒次數。
以上修正降低的是 App 自己的保活渲染頻率；整個 App 的 CPU、耗電與 iOS 背景維持效果仍需實機量測。測試組 `PIPTestService` 的 30 FPS 白畫面屬獨立測試功能，不是保活組路徑。