onPause()ドキュメントは、データを/でコミット/読み取る必要があることを示唆していますonResume()。
しかし、アプリケーションがフォアグラウンドになくても、そのデータ構造はそのまま残ります。これは、アプリケーションが見えなくなるまで、つまりonStop()/内でデータのコミット/読み取りを遅らせることができることを示唆していますonStart()。特にonStop()は の前に呼び出されることが保証されていますonDestroy()。
どちらのアプローチも適しているということでしょうか。ここに記載されているドキュメントは単なるガイドラインですか?
更新
アプリケーションが、大きな画像の編集など、比較的大量のデータを保存する必要があるとします。ユーザーエクスペリエンスが遅くならないように、/で書き込み/読み取りを行うことは絶対にありません。その場合、代わりに / への書き込み/読み取りを選択します。本当？onPause()onResume()onStop()onStart()
を使用する際の問題onStopは、 の前に呼び出されることだけが確実であるため、いつ呼び出されるかについて保証がないことですonDestroy。データをコミットするまで待っonStopていると、別のアクティビティがそれらの変更を表示/使用するのが遅くなる可能性があります。同じことが にも当てはまりonStartます。アクティビティがバックグラウンドにあるだけの場合は、アクティビティを再開する必要がない可能性があるため、データが古くなります。データが常に最新であることを使用onResumeおよびonPause保証し、アクティビティがバックグラウンドに移行するとすぐにコミットが行われ、新しいデータが表示されるとすぐにロードされます。
はい、これは単なるガイドラインです (一般的には良いガイドラインです)。いつ変更をコミットするかは、あなた次第です。個人的には、データベースや SharedPreferences を簡素化できるストア オブジェクトを作成するのが好きで、変更が加えられるとすぐにそれらの変更をコミットします。単純なデータ ストレージの場合、これは迅速であり、ユーザーには見えません。大規模なデータ セットの場合、これにはさらに時間がかかる場合があり、onPause だけでなく、時間間隔でこれらの書き込みを行うこともできます。
いつ読み取るかについては、いつでも読み取ることができますが、AsyncTask などの別のスレッドで処理しない限り、長い読み取りはユーザー エクスペリエンスに影響を与えることがよくあります。
あなたの更新にさらに答えるには：
それは開発者によって異なりますが、私は書き込み、onPause()必要に応じて別のスレッドで読み取りonResume()ます。また、スレッドを使用してスケジュールされた間隔でデータを書き出すこともありTimerます。これは、現在のセッションのユーザー エクスペリエンスにどのように影響するか、および電話onPause()が呼び出される前に電源が切れてすべてのデータが失われると壊滅的であるかどうかによって異なります。
これに対する本当の答えは、onPause は、Androidがプロセスを破棄する前に呼び出されることが保証されている唯一のメソッドです。ユーザーが電話を取るためにアプリを離れ、Android がプロセスを終了することを決定した場合、onPause 呼び出しのみを取得することは完全に合法です。そこに状態を保存していなかった場合、ユーザーが戻るボタンを押したときに、ユーザーが残した状態とは異なる状態でアクティビティを再作成することになります。