アプリケーションは、バックグラウンドで長時間アイドル状態になった後、クラッシュします。デバッグして、クラッシュの原因が によるものであることがわかりましたNullPointerException。例外は、アプリケーションがバックグラウンドにあるときに、アプリケーション シングルトン クラスのデータがガベージ コレクターによって破棄されることが原因でした。アプリケーション全体の各アクティビティで静的データを使用しています。
私の質問は、バックグラウンドでアプリケーション クラスのデータを永続化する方法はありますか? または、他の解決策はありますか?
ベストアンサー1
より正確な回答を得るには、ここにコードを入力してください。ただし、Android のメモリは限られているため、VM は不要と思われるコードの一部を削除できます。
アクティビティ ライフサイクル メソッドを特に詳しく調べてonResume、完全に理解していることを確認してください。アクティビティ ライフサイクル メソッドを適切に使用していないためにアプリケーションがクラッシュするケースは数多くあります。
アクティビティのもう1つの重要な設計上の考慮事項は、永続データに何が起こったとしても、アクティビティはデフォルト値でUIを表示する必要があるということです。したがって、仮定は次のようになります。データがあれば表示しますが、なくても構いません。UIはデータの有無にかかわらず決してクラッシュしてはならないString.xmlデフォルト値を保存したり、レイアウトに使用したりできます。
それでもシングルトン クラスを使用したい場合は、それはまったく問題ありませんが、シングルトンにアクセスするたびに次のチェックを必ず実行してください。
if (instance==null)
instance=Singleton.getInstance()
メソッドgetInstance()は現在のインスタンスを返すだけでなく、
- すべてのオブジェクトと変数を初期化します
- その他のシングルトンメソッドをインスタンスメソッドとして
あるアクティビティから別のアクティビティに静的にデータにアクセスしないでください。これは、特に現在直面している型の問題に対して Android にとって良くありませんし、OOP プログラミングの実践としてもあまり良くありません。
共有設定データを永続化するための良い方法なので、要件を満たす場合はそれを実行してください。
Activity、Service、BroadcastReciever などのさまざまな Android コンポーネントからデータを渡す場合は、それをバンドル内に入れて、インテントとして送信できます。また、いつものように、SQLLite データ ストレージ、ファイル IO などがあります。