API 28+ 的 onSaveInstanceState 和 onStop 順序發生變化的原因是什么？

Question

在 API 28 之后onSaveInstanceState()和onStop()的執行順序發生了變化。

參考文檔中的本段：

該更改的原因是能夠首先執行片段事務，然后保存 state。 參考文檔中的本段：

• 這次改動后有什么收獲？
• 這種變化背后還有其他原因嗎？

Answer 1

這確實是一個一致性問題，因為方法onStop()仍然可以修改實例 state。
當將onSaveInstanceState()移動到時間線的末尾時，這些更改不會丟失。

Answer 2

雖然我不是谷歌員工，也沒有為此做出貢獻，但如果我沒記錯的話，這一變化也會影響活動，我想原因與這樣一個事實有關，即在此變化之前，保存 state 的調用是如果/當框架在onPause之后認為有些合適時，可能會發生。

這種行為是非常不可預測的，並且使得生命周期方法不可靠。

隨着（Google Devs）對整個FragmentManager及其行為的重構，這種變化很可能是由一致性驅動的。 （也許我不知道我們不熟悉的其他技術細節）。

簡而言之，框架現在在調用中是一致的，因為它們保證在onStop之后發生（對於 API 28+），這確保當您重新創建活動/片段時，state 將正確（並保存）。

就像我在開頭提到的那樣，我不是 Google 開發人員，但以前的方式是一個不確定的集群，而這種變化帶來了一些希望，使 Fragment api 從最終消亡中拯救出來。

在這中間的某個時候，使用多個活動不再酷了，我們都想要一個包含許多片段的單個活動，並且導航組件可以無縫地跨堆棧移動（不必擔心原始設計中的“缺陷” )，因為這個和許多其他細節在 go 我們在這里的旅程中得到了完善，如果您願意使用它，可以使用更穩定的 Fragment 平台。

在所有這些“修復”之前，框架 API 容易出現許多錯誤和不一致，有時會導致運行時崩潰。 我可以想象這個和許多其他修復是如何旨在將這個 API 減少到一個完美的功能特性，以便其他工具（如導航組件、生命周期、視圖模型等）都可以和諧地工作，而不必擔心“哦，片段是特殊的，需要進一步的邏輯來處理它的錯誤行為”。

盡管如此，隨着越來越多的應用程序開始整合 Jetpack Compose，Fragment 正慢慢開始成為“舊事物”。