Android：何が良いですか-複数のアクティビティまたは手動でのビューの切り替え？

私はAndroid向けのアプリをいくつか開発しましたが、この質問は常に残ります。

UIをどのように構成すればよいですか？アクティビティを次々に起動し、電話から離れて「戻る」ボタンを作成する必要がありますか、またはビューを手動で切り替えてから「戻る」ボタンの機能を手動で実行する方法で、より最適化された実装を選択する必要がありますか？

何が良い（または知っている）と思いますか？

ほとんどの場合、複数のアクティビティの方が理にかなっています。Androidが絶えず独自のビューを切り替えるように設計されているとは思いません。自分でBackを実装する必要があります。アクティビティ間の遷移は発生しません。アプリケーションを正しい状態で再開するには、多くの内部ロジックを実装する必要があります。アプリをアクティビティに分割しないと、後でアプリケーションのフローを変更することが非常に難しくなります。また、1つのメガアクティビティが発生し、小さなコードの多くよりも処理がはるかに困難になる場合があります。

スピードが本当に問題だとは思いもしません。もしそうなら、各アクティビティを初期化する方法に何か問題があります。たとえば、アクティビティ間でSerializableオブジェクトを渡そうとすると、信じられないほど遅いことが判明しました。オブジェクトを渡すより速い方法に切り替えると、アクティビティの起動速度が大幅に向上しました。

また、Androidのアクティビティとタスクデザインのガイドラインでは、ビューの切り替えについてはまったく触れられていないようです。これは、Activity-as-Viewデザインを中心としています。

1つのアクティビティが複数のフルスクリーンビューを備えたAndroidアプリケーションに適している場合があることを指摘したいと思います。

• アプリケーション画面が密結合され、それらがすべて操作している共通のオブジェクトを共有する場合。この場合、オブジェクトを渡すにはバンドルが必要な場合があり、そのコピーがあるためエラーが発生しやすくなります。良い例はウィザードです。はい、静的オブジェクトを使用して共通のオブジェクトにアクセスできますが、Androidでは静的オブジェクトが危険な場合があります（構成の変更を考えてください）。

• 画面の間にいくつかの本当にクールなアニメーションが必要な場合。鳥が1つの画面で離陸し、別の画面に着陸したいと思うかもしれません。各画面がアクティビティのときにそれを試してみてください！

一方、画面の1つが他の任意の数のアプリケーションによって表示されるように設計されている場合、その画面は独自のアクティビティである必要があります。

2014年3月の更新：

この時点で、質問にはフラグメントの選択が含まれるはずです。ビューはおそらく、アクティビティ、フラグメント、ビューの3つのうち、最も可能性の低い選択肢だと思います。[戻る]ボタンを使用する画面を実装する場合は、どちらも[戻る]ボタンをネイティブで処理するため、[アクティビティ]または[フラグメント]のいずれかである必要があります。戻るボタンを機能させるには、フラグメントをFragmentManagerバックスタックに追加する必要があります。フラグメント、ダイアログ、バックスタックの管理は少し面倒かもしれませんが！

2018年9月の更新：

Googleの一部の開発者は、新しいナビゲーションアーキテクチャコンポーネントを使用するシングルアクティビティアプリを推奨しています。

また、アプリを複数で実装するActivitiesと、プラットフォーム全体でユーザーに一貫性のあるエクスペリエンスを提供できることに注意してください。エクスペリエンスの一部は組み込みのGoogleアプリを使用して形作られるので、アプリケーションがすでに電話にインストールされているものと同様に動作する場合、ユーザーはおそらくアプリケーションをより簡単に使用できます。

他とは異なり、両方を組み合わせて使用​​し
ます。たとえば、1。アプリケーションの起動時にメインメニューがあります
。2。検索をクリックして、検索アクティビティに移動します。3
。表示と表示を切り替えるだけのフィルターボタンがあります。
フィルタービューの最後に2つのボタンがあります。「検索」または「キャンセル」を押すと、再び検索ビューに戻ります（アクティビティを切り替えることなく）
。5.ユーザーが電話に戻った場合ボタンをクリックすると、検索フィルターオプションの代わりにメインメニューに戻ります。私が推測するのは正しい動作です。

ユーザーが自然に感じる方法で使用してください。また、すべてを1つのアクティビティに収めると、複雑になります。

それはすべて、アプリケーション、より良いパフォーマンス、よりスムーズなUIを実現しようとしているものに依存します。IMHO私は、アクティビティを手動で制御する2番目のアプローチを好んでいます。これは私が私のandroidタブプロジェクトで使用したアプローチです。また、ActivityGroup（パッケージは不明）というクラスを確認すると、切り替え可能な複数のアクティビティを持つことができます。このクラスの良い点は切り替え時にアクティビティはアンロードされませんが、メインアプリのロードに時間がかかるのが悪い点です。

ただ私の意見です。

私が偶然見つけたビューの切り替えの問題も、ガベージコレクターが原因です。ビューではなくアクティビティを離れると、GCがトリガーされるようです。そのため、たとえば、かなり複雑な子ビューを持つタブを変更すると、ほぼ必然的にスタックオーバーフロー例外が発生します。

選択する正当な理由がない限り、複数のアクティビティレイアウトで非常に多くの問題を経験したので、私はそれを強く推奨しません。

複数の活動の欠点

複数のアクティビティを使用すると、アクティビティからデータを返すようにコードをリファクタリングすることが非常に困難になります。

「サブ」アクティビティを呼び出すと、メインアクティビティが強制終了される可能性があります。しかし、まともなデバイスでデバッグしている間はそのようなことは決してないので、常に状態を保存し、状態を正しく回復する必要があります。それは苦痛です。ライブラリ（つまり、別のアクティビティ）のメソッドを呼び出すことを想像してください。そのメソッドが返されたときに、アプリがVM内のすべてのオブジェクトのすべてのフィールド（つまり、アクティビティ。 restoreIntance）。その狂気。

また、逆に、サブアクティビティを開いたときに、サブアクティビティが表示されているときにアプリが最小化されている場合など、サブアクティビティが最初に起動されてからVMが強制終了された可能性があります。

関連するアプリの状態を保存する場所が1つしかないので、とてもクリーンです。私の場合、ほとんどの場合、VMが強制終了された場合、ユーザーをメイン画面に戻して、もう一度操作をさせたいと思います。 0.1％のユーザーが体験する保存/再開機能のコーディングに30〜50時間を費やす必要はありません。

オルタナティブ

フラグメントまたはアクティビティビューを自分で管理します。ビューを手動で管理するには、必要に応じて、トランジション付きのアクティビティ/フラグメントに代わるいくつかのビュー切り替えのコーディングが必要です。

そして、それは、受け入れられた回答で示唆されているように、1つのメガアプリ以外の方法で1つのメガアクティビティを意味するものではありません。アクティビティの状態やその他の奇妙さを管理する作業ははるかに少なくなりますが、ビューを管理する作業がわずかに増えるため、コードベースを少しずつ適切に設計する必要があります。

おそらく関連性があります：Reddit：それは公式です：Googleはシングルアクティビティアプリのアーキテクチャを公式に推奨しています