Fragmentのドキュメントが刷新されましたが、そこに次のように記載されています。
https://developer.android.com/guide/fragments/create#add-programmatic
Note: You should always use
setReorderingAllowed(true)when performing aFragmentTransaction. For more information on reordered transactions, see Fragment transactions.
setReorderingAllowed を常に使うべきと記載されています。後方互換のためデフォルトではfalseになっています。
この setReorderingAllowed によってライフサイクルがどのように変わるかを見ていきます。
環境
使用したのは、 1.3.0-beta02 です。
implementation "androidx.fragment:fragment-ktx:1.3.0-beta02"New State Manager
Fragmentの管理方法の内部実装が新しくなってるのですが、これにより setReorderingAllowed の挙動も影響を受けます。
New State Managerについては以下の記事にあります。
Fragment 1.3.0-alpha08からこちらはデフォルトで有効になっています。
以下のコードを先に実行しておくことで、以前の方法として実行することもできます。
FragmentManager.enableNewStateManager(false)このNew State Mangerが有効、無効での挙動の違いも見ていきます。
この記事ではNew State Manger / Old State Manger と表現します。
単純なFragment遷移
以下のように単純にFragment遷移をするときの違いです。
FragmentA から FragmentBへ遷移します。
単純な遷移では特に影響はないと思いますが、 Shared element transitions などで postponeEnterTransition を使う場合は必ず setReorderingAllowed(true) にする必要があります。そうしないとアニメーションが奇妙な感じなります。
New State Mangerの場合
New State Mangerの場合は setReorderingAllowed に関わらず同じ順番で実行されます。
Old State Mangerの場合
Old State Managerの場合は先にFragmentAのViewが破棄されるかどうかの違いがあります。
setReorderingAllowed(false)
setReorderingAllowed(true)
同時にFragment遷移
同時にFragment遷移が発生した場合の挙動の違いです。
FragmentAからFragmentBへの遷移と、FragmentAからFragmentCへの遷移が同時に発生した場合です。
最終的にはFragmentCが表示されます。
注意としては両方とも setReorderingAllowed(true) にしないと効果はありません。
New State Mangerの場合
setReorderingAllowed(false)
falseの場合はBが一旦表示されてCの表示がされています。表示されないのにViewが生成され破棄されていて無駄に処理が実行されています。
setReorderingAllowed(true)
trueの場合は、BはonCreateのみ呼ばれていて、すぐにCの処理が実行されています。効率が良い感じです。
Old State Mangerの場合
setReorderingAllowed(false)
New State Mangerとは微妙に異なりますが、基本的なことは同じで、無駄にBの処理が実行されています。
setReorderingAllowed(true)
New State Managerとは異なりますが、BのViewに関する処理が実行されていないため効率が良さそうです。
