0

状態の保存と状態の回復は、Android の主要な問題です。状態を保存して復元する必要があるため ( Intents、Parcelables、などを使用)、単純なタスクは複雑であり、スレッド化の問題によってさらに複雑になります ( AsyncTaskLoaders、LoaderManagers、や。。など。）。

ただし、私が理解しているように、static変数はプロセス全体で持続し (ここではアプリの実行に関連しています)、状態を保存し、これらのstatic変数を介してスレッドをファネリングする方がはるかに簡単です。

もちろん、プロセスが強制終了された場合、状態は失われますが、フォアグラウンドで実行されているアプリケーションでこれが実際にどのくらいの頻度で発生するのでしょうか?

さらに状態を維持することは良いことですが、ほとんどのアプリケーションにとって重要ではありません。特に、状態が失われることがめったにない場合はそうです。

また、状態が非常に重要な場合は、ライフサイクルによって提供される関数を使用してActivityその状態を保存および回復しないでください。プロセスが強制終了されたときに関数が呼び出されることが保証されていないため、代わりに常に保存する必要がありますいくつかのデータベースでのあなたの状態。

推奨される方法はやり過ぎで、ほとんどのアプリの開発を不必要に複雑にしていると思いますが、それが受け入れられた理由は何ですか?

4

1 に答える 1

0

もちろん、プロセスが強制終了されると状態は失われますが、これは実際にフォアグラウンドで実行されているアプリケーションでどのくらいの頻度で発生しますか？

当然のことながら、バッテリーがなくなる、ユーザーがデバイスの電源を切るなどのことは絶対にしないでください。

ただし、ユーザーの行動によっては、フォアグラウンドにあまりいないため、フォアグラウンドに長く留まらない場合があります。

状態をさらに維持することは素晴らしいことですが、特に状態が失われることがまれである場合は、ほとんどのアプリケーションにとって重要ではありません。

アプリケーションが非常に頻繁に、または必ずしも非常に長い間フォアグラウンドにないため、状態の喪失は非常に頻繁に発生します。

また、状態が非常に重要である場合は、アクティビティライフサイクルによって提供される関数を使用してその状態を保存および回復するべきではありません。プロセスが強制終了されたときに呼び出されることが保証されていないためです。状態をデータベースに保存します。

ライフサイクルメソッドは、そのような状態には適していません。これらは、ユーザーナビゲーションを簡素化するために可能な限り保持する必要があるデータ（方向の変更の処理など）用ですが、耐久性は必要ありません（永続的なストアに配置する必要があります）。

例えれば、このStackOverflowページに質問を入力した場合、フォームを送信するまで、入力した内容をWebサーバーに保存する必要はありません。ただし、ブラウザのタブを切り替えるとき、またはブラウザウィンドウを最小化（および後で復元）するときは、Webブラウザはこのデータを確実に保持する必要があります。また、Webブラウザーは、このデータを一時ファイルに保持し、開いているタブのリストも保持する場合があるため、ブラウザーがクラッシュした場合でも、可能な限り状態を復元できます。「Webサーバーに保存されるもの」、「プロセスヒープに保存されるもの」、「ローカルファイルシステムの一時的な場所に保存されるもの」の違いによって、これらの戦略に関連付けられるデータの種類が決まります。

同様に、Androidでは、「静的データメンバーに格納されるもの」、「エクストラなどを介して渡されるもの」、「データベースなどの永続的なスポットに格納されるもの」の違いによって、Intentデータの種類が決まります。それらの戦略に結びついています。

その受け入れの背後にある理由は何ですか？

静的キャッシュを非常に注意深く処理しない限り、アプローチによってメモリリークが発生する傾向があるためです。

また、あなたのアプローチは、真のグローバルデータと、論理的には個別の操作の一部であるため、Intent追加または他の操作固有の手段を介して渡される必要があるデータとの区別を混乱させるためです。

これらは、静的データメンバーがJavaで貧弱な形式と見なされる他のすべての古典的な理由に追加されます。

于 2012-11-05T16:16:01.577 に答える