Android Activity 生命周期深度解析：為什麼 B 未銷毀 A 先可見？

標準流程回顧

A 啟動 B，按 Back 返回 A：

// 啟動 B
A.onPause() → B.onCreate() → B.onStart() → B.onResume() → A.onStop()

// 返回 A
B.onPause() → A.onRestart() → A.onStart() → A.onResume() → B.onStop() → B.onDestroy()

核心疑問

為什麼不是「B 完全銷毀後 A 才重啟」？即為什麼 B.onPause() 後直接執行 A.onRestart()，而非等待 B.onStop()/onDestroy()？

系統設計原理

1. 用戶體驗優先：用戶按 Back 期望「立即看到上一個頁面」。若等 B 完全銷毀 (含耗時清理)，A 重啟會有明顯延遲/黑屏。
2. 並行執行：B.onPause() 後，系統同時啟動 A 的恢復流程和 B 的銷毀流程。兩者在不同線程/消息隊列中並行。
3. 內存管理：B 的 onStop()/onDestroy() 主要釋放資源、解註冊，不影響 UI 線程渲染 A。
4. 狀態保存：B.onPause() 是 B 最後一次保存持久化數據的機會 (官方建議)，之後進程隨時可能被殺。

圖解時序

時間 →
B: |---onPause()---|-----onStop()-----|--onDestroy()--|
A:                 |-onRestart()-onStart()-onResume()-|
用戶視覺:          A 界面已可見/可交互         B 徹底消失

實戰啟示

• onPause() 輕量快速：只存關鍵狀態，耗時操作放 onStop() 或工作線程。
• 不要在 onPause() 做網絡/數據庫同步操作，會阻塞前一個 Activity 恢復。
• onStop() 後進程處於「可回收」狀態，系統內存緊張會直接殺進程不再調用 onDestroy()。

結論：並行生命周期 是 Android 為流暢體驗做出的權衡，而非 Bug。