這兩個回調的時機不壹樣。
我們知道在屏幕旋轉時 Activity 和 Fragment 會重建，其實還有壹種情況會重建，就是我們時常看到博客裏說的，當應用在後臺時，進程被系統回收，用戶再次回到應用時，應用會被重建。
那麽應用什麽時候會被系統回收呢？我們需要清楚壹點，就是系統不會單獨地回收 Activity 或者 Fragment ，而是會在系統資源不足時，根據應用所在的進程的狀態來殺死進程，以回收資源。這裏涉及到了壹些進程狀態的概念：前臺進程、可見進程、服務進程 和 緩存進程( process lifecycle )。壹般緩存進程會最先被系統回收。
現在的手機 RAM 都非常大，我們怎麽模擬這個系統回收進程的過程呢？可以到 開發者選項 -> 應用 -> 後臺進程限制 ，將其從默認的 標準限制 改為 不得超過 1 個進程 。這樣我們就能夠觀察到 Activity 或 Fragment 重建時， Bundle 中帶有之前調用 onSaveInstanceState 時保存的值了。
Fragement 的數據恢復提供了另外兩個回調， onCreate 和 onCreateView ，方便開發者在不同的時機恢復數據。
Fragment 的 retainInstance 屬性默認為 false ，當其設置為 true 時，表示 Fragment 實例會在 Activity 因配置變化而重建時， Fragment 自身實例會被保持，不會創建新的實例。它的原理是，調用該方法時，最終調用到了 FragmentManager.addRetainedFragment -> FragmentManagerViewModel.addRetainedFragment ， Fragment 實例保存到了 FragmentManagerViewModel.mRetainedFragments 中。 mRetainedFragment 是壹個以 Fragment 的 uuid( Fragment 自己生成) 為 key ，以 Fragment 自身實例為 value 的 HashMap 。因此本質上是因為 FragmentManagerViewModel 是壹個 ViewModel ，它可以在重建周期內保持實例。
正確的使用姿勢應該是， onSaveInstanceState 和 ViewModel 結合使用。
我們知道 onSaveInstanceState 中保存的是能夠被序列化的數據， Android 系統同樣為我們提供了在配置改變時保存沒有必要序列化的數據的方法： onRetainCustomNonConfigurationInstance 和 onRetainNonConfigurationInstance ，這兩個回調方法都返回壹個 Object ，區別在於， onRetainCustomNonConfigurationInstance 是開放給開發者來保存數據的時機的回調， onRetainNonConfigurationInstance 是 final 方法，用於系統自己保存壹些系統資源時使用。
對於 onRetainCustomNonConfigurationInstance 保存的數據，之後我們在重建的 Activity 的 onCreate 方法中，可以通過 getLastCustomNonConfigurationInstance 來直接獲得之前保存的數據。這個回調在 Androidx 中已經被標記為 Deprecated ，這是因為該機制的職責已經由 ViewModel 代替了。
對於 onRetainNonConfigurationInstance 保存的數據，其實通過閱讀源碼我們是可以發現，目前的實現就是用來保存了 ViewModel 。而 ViewModel 之所以能夠在系統配置改變後重建，正是使用了 onRetainNonConfigurationInstance 的恢復機制。
ViewModel 的重建恢復原理