web-dev-qa-db-ja.com

Androidライフサイクルからオブザーバーとして自分を削除することは必須ですか?

Android Java LifecycleObserver インターフェースを実装するクラスを構築しています。

これはコンストラクタです:

public MyObserver(AppCompatActivity activity) {
    this.mActivity = new WeakReference<AppCompatActivity>(activity);
    activity.getLifecycle().addObserver(this);
}

これまでに removeObserver を呼び出す必要がありますか?

@OnLifecycleEvent(Lifecycle.Event.ON_DESTROY)
public void destroyListener() {
    if (this.mActivity.get() != null) {
        this.mActivity.get().getLifecycle().removeObserver(this);
    }
}

または、永久に観察できますか?

18
esilver

TL; DR:いいえ。

これによると ここにリンク 、ユーザーがAndroid-lifecycles Githubリポジトリ。この質問に対するGoogle開発者の答えは次のとおりです。

はい、それが新しいライフサイクル対応コンポーネントの要点ですオブザーバの登録を解除/削除する必要はありません。

19
TareK Khoury

TL; DR:オブザーバーを使い終わったら明示的に削除するか、LiveDataなど、これを自動的に処理するオブザーバーを使用することをお勧めします。

Lifecycleabstractクラスです。したがって、技術的には、実装が何であり、ゲームのルールが何であるかはわかりません。

具体的なLifecycleLifecycleRegistryです。オブザーバーへの強い参照があります。ですから、アクティビティが破棄されたときなどに、LifecycleRegistryが適時にガベージコレクションされることを期待しています。 FragmentActivityの場合、そのように見えます。したがって、実際には、これらすべてのものの現在のバージョンでは、オブザーバーの登録を解除せずに逃げることができ、悪影響があったとしてもほとんど影響を受けません。

しかし、それはLifecycle契約の一部ではありません。おそらく、Lifecycleの適切な実装(またはLifecycleRegistryを使用するもの)should登録解除に失敗した場合を適切に処理しますが、リスクはありません。それ。

5
CommonsWare

オーディオサウンドを管理するシングルトンオブジェクトでLifecycleRegistryを使用しています。 LeakCanaryを追加した後、この問題が原因でメモリリークが検出されました。

ただし、removeObserverを呼び出すと、メモリリークが再び発生することはありません。

したがって、LiveData + LifecycleRegistryを使用する場合は、登録を解除する必要がないことは事実です。しかし、LifecycleRegistryを使用するカスタムコンポーネントの場合、私の経験では、removeObserverの呼び出しはメモリリークを回避するために必須であることが示されています。

0
Vito Valov