私は小さなアンドロイドアプリを書くつもりです。6つの「画面」で複雑なことは何もありません。そのうちの 4 つは、同じビュー ナビゲーション階層レベルにあります。2 は、それら 4 つのうちの 1 つのサブ画面です。
たとえば、画面 A には情報のリストが表示されます。リスト項目をクリックすると、アプリは画面 A1 を表示します。画面 A1 には、以前に選択したリスト項目に関する詳細が表示されます。したがって、画面 A1 は画面 A のサブ画面です。戻るボタンをクリックすると、アプリは画面 A を表示します。
画面 B には、B1 と呼ばれる従属画面もあります。他の画面は、A および B と同じビュー ナビゲーション階層にある C および D です (ただし、A1 および B1 ではありません)。したがって、A、B、C、および D は、ビュー ナビゲーション階層の最上位にあります。アプリは画面 A の表示から始まります。アクション バー (またはスライド メニュー) には、画面 B、C、D にジャンプするためのボタンがあります。
私がやろうとしていることを理解していただければ幸いです。したがって、通常は、すべての画面が独自のアクティビティであると言えます。私はフラグメントの大ファンで、通常はどこでもフラグメントを使用しています。実際、メイン ビュー レイアウトを含むフラグメントを 1 つだけ含むアクティビティを実装していることに気づきました。そして、そうすることは絶対に悪いことではないと言えます（フラグメントは大きな利点をもたらします...）
しかし、メイン アクティビティを 1 つ使用し、このアクティビティのフラグメントのみを変更するのは良い考えではないでしょうか。したがって、画面 A、B、C、D、A1、B1 はアクティビティではなくフラグメントです。したがって、画面 A から CI に移動すると、メイン アクティビティでフラグメント A がフラグメント C に置き換えられます (フラグメント C を含む新しいアクティビティを開始する代わりに)。画面 A からサブ画面 A1 へのナビゲーションを実装するのと同じ方法です。
これまでのところ、このアプローチに問題はありません。私の意見では、画面間を移動するためのスワイプ ジェスチャがないだけで、ViewPager のようなものになると思います。
それについて私が確信していない唯一のこと（そしてそれが私の質問です）は、メモリ管理です。画面 A から B に移動するためにフラグメント トランザクションの置換 (フラグメント マネージャー) を実行するたびに、フラグメント A を破棄し、メモリをガベージ コレクションする必要があります (将来のどこか)。Fragment B はいつインスタンス化するのですか? ユーザーがボタンをクリックして B に移動したとき (および A を置き換えたとき) は? これにより、パフォーマンスの問題 (フラグメントをインスタンス化する時間) が発生する可能性はありますか?
すべてのフラグメント A、B、C、D、A1、および B1 を setRetainInstanceState(true) に設定するとどうなりますか? MainActivity が終了するまで、各画面のクラス メンバー フィールドはメモリに保持されますか?
あなたの誰かがそれを経験したことがありますか？
ViewPage はある種の「プリロード」フラグメントを使用し、次および前のフラグメントのビュー レイアウトのみをロードします (setOffscreenPageLimit() )。
メモリとパフォーマンスの問題を回避するために、似たようなことをしなければならないと思いますか?