0

私の Android アプリでは、カスタム Application 派生クラスを設定しました。その中に、任意のオブジェクトを格納するためのメンバー フィールドがあります。

ので、私は持っています：

public class MyApp extends Application {

public static MyApp mInstance;
public Object mData;

@Override
public void onCreate() {
   mInstance = this;
}

public void setData(Object data) {
    mData = data;
}

public Object getData() { return mData; } 

}

今、Activity私がやっていることの1つに

public doSetData() {

     someMyData = ....
     MyApp.mInstance.setData(someMyData);

}

別の方法Activityで私がやっている

@Override
public void onCreate(Bundle) {

     Object myDataRetrieved = MyApp.mInstance.getData();

}

myDataRetrieved私は時々あることがわかりますnull。しかし、私は一度も合格nullしたことがないと信じていMyApp.setData()ます。もちろん、私は間違っている可能性があります。

しかし、MyApp.mDataそれ自体が無効になるような状況があり得るのでしょうか?

4

3 に答える 3

2

それでも、MyApp.mData 自体が null になるような状況はあり得るでしょうか?

もちろん。これは、Android がプロセスを終了するたびに発生します。これは、アプリがフォアグラウンドになく、Android が RAM を必要としており、アプリが次に終了する必要がある場合に発生します。

于 2013-02-18T18:48:01.010 に答える
0

システムは常にプロセスを取得してリソースを再利用できるため、データがメモリに保持されることを保証することはできません。

したがって、アプリケーションは、永続データをonSaveInstanceState（）（短期）またはonPause（） （長期）のいずれかに保存し、onCreate（）で取得できるように常に準備する必要があります。

そうは言っても、私がとても好きな「シングルトンパターン」もあります。これは、永続データを保持するためだけに特別なクラスを作成するソフトウェアデザインパターンです。データが最初に必要になったときにオンデマンドで作成されるクラスのインスタンス（したがって「シングルトン」という名前）は1回だけです。シングルトンは保持されるため、永続データの後続のニーズは、長期ストレージからデータを再ロードする必要なしに、同じオブジェクトを使用するだけです。システムがプロセスを取得しない限り、データは常にそこにあり、アクセスコストはほぼゼロです。システムがプロセスを取得した場合、データは透過的に再ロードされ、アプリケーションは違いに気付くことはありません。

シングルトンの実装については、https：//stackoverflow.com/a/14779357/338479を参照してください。

于 2013-02-18T19:37:46.630 に答える
0

インスタンスが破棄された場合は、データを保存し、アプリケーション オブジェクトの作成時にロードします。これは常にアクティビティの前に作成されます。

メモリの使用を最小限に抑えると、パージされる前に Android zygote でより長く存続します。saveinstancestate などは、小さなデータ ブロックにのみ適しています。アプリ インスタンスを介してデータを共有することは問題なく、場合によっては推奨されますが、静的フィールドを使用する場合と違いはありません。同じ制約が適用されます。

メモリの使用を最小限に抑えたい場合は、区画などを使用してデータを保存することはお勧めできません。Google でも同様です。

于 2016-05-18T09:20:14.817 に答える