Androidのメモリリークとは何か、プログラムの不在をチェックする方法、および発生を防ぐ方法

初心者のAndroid開発者向けのこの記事では、Androidの「メモリリーク」とは何か、アプリケーションごとに192 MBを割り当てる最新のデバイスでそれらについて考える必要がある理由、馴染みのないアプリケーションでこれらのリークをすばやく見つけて修正する方法についてお話しますアプリケーションを開発する際には特別な注意を払う必要があること。


この記事の最終的な目標は、簡単な質問に答えることです。
アプリケーション内のどの行を修正するかを見つけるには、どこをクリックしますか？

メモリリークとは何ですか？

「メモリリーク」と呼ばれるものから始めましょう。 厳密な理解では、オブジェクトへのすべての参照が失われた後でもメモリに存在し続ける場合、オブジェクトはメモリリークと呼ばれます。 この定義では問題がすぐに発生します。作成するすべてのオブジェクトのメモリは、ガベージコレクタの参加によって割り当てられ、オブジェクトへの参照があるかどうかに関係なく、ガベージコレクタは作成されたすべてのオブジェクトを記憶します。

実際、ガベージコレクターは非常に原始的に構築されています（実際にはそうではありませんが、動作原理は非常に単純です）。既存のすべてのオブジェクトが頂点であり、オブジェクトから他のオブジェクトへのリンクがエッジであるグラフがあります。 このグラフのいくつかの頂点は特別です。 これらは、ガベージコレクションのルートのルートです。システムによって作成され、他のオブジェクトがそれらを参照しているかどうかに関係なく存在し続けるエンティティです。 特定のオブジェクトから任意のルートへのグラフ上のパスがある場合にのみ、オブジェクトはガベージコレクタによって破棄されません。

これは問題です-オブジェクトが破棄されない場合、ルートからこのオブジェクトへのリンクのチェーンがあります（または、そのようなチェーンが存在しない場合、次のガベージコレクション中にオブジェクトが破棄されます）。つまり、オブジェクトはリークできません。用語の厳密な意味での記憶。 実際には、ガベージコレクター自体がシステム内の既存のすべてのオブジェクトへのリンクを保存しているという事実でさえ十分です。

Javaで「クリーンな」メモリリークを取得しようとする試みは繰り返し行われていますが 、もちろん引き続き行われていますが、メモリを解放せずにオブジェクトへの参照をガベージコレクタに忘れさせるメソッドはありません。 メモリのネイティブコード割り当て（JNI）に関連するメモリリークがありますが、この記事ではそれらを考慮しません。

結論： 関心のあるオブジェクトへのすべてのリンクを失う可能性がありますが、ガベージコレクターは記憶しています。

したがって、厳密な意味での「メモリリーク」の定義は、私たちには適していません。 したがって、メモリリークは、破棄する必要がある後も存在し続けるオブジェクトとしてさらに理解します。

次に、メモリリークの最も一般的なケースのいくつかを示し、それらを検出する方法とそれらを回避する方法を示します。 これらの典型的なメモリリークを修正することを学習した場合、99.9％の確率で、アプリケーションに心配する必要のあるメモリリークはありません。

しかし、これらの一般的なエラーの説明に進む前に、主な質問に答える必要があります。これらのエラーをすべて修正する必要がありますか？ アプリケーションは動作しています...

メモリリークのトラブルシューティングに時間を費やすのはなぜですか？

リソースをdrawable-ldpiフォルダーに詰め込むのを忘れたため、アプリケーションは長い間クラッシュしていません。 この記事を書く準備をして、簡単な実験を行いました：作業中のアプリケーションの1つを取得し、作成されたアクティビティがメモリからアンロードされないようにメモリリークを追加しました（静的リストに追加し始めました）。 アプリケーションを開いて画面をクリックし、Nexus 5でアプリケーションが最終的にクラッシュするのを待ちました。最後に、5分55画面後にアプリケーションがクラッシュしました。 皮肉なことに、Googleアナリティクスによると、通常、ユーザーはセッションごとに3つの画面にアクセスします。

だから、ユーザーが気付かないかもしれない場合、メモリリークを心配する必要がありますか？ はい、それには3つの理由があります。

まず 、アプリケーションで機能しないはずの何かが機能する場合、これは非常に深刻でデバッグが困難な問題につながる可能性があります。

たとえば、ソーシャルネットワーク用のアプリケーションを開発しました。 このアプリケーションでは、ユーザー間でメッセージを交換できます。メッセージング画面には、新しいメッセージを受信するために10秒ごとにサーバーに要求を行うタイマーがありますが、画面を終了するときにこのタイマーをオフにするのを忘れていました。 これは視覚的に何を導きますか？ なんでもあり。 アプリケーションが何か間違ったことをしていることに気付かないでしょう。 ただし、同時に、アプリケーションは10秒ごとにサーバーにリクエストを送信し続けます。 アプリケーションを終了した後でも。 画面をオフにした後でも（電話とは動作が異なる場合があります）。 ユーザーが3人の異なる友人との通信画面に入ると、1時間以内にサーバーへの1000の追加リクエストを受信し、1人のユーザーがアプリケーションに非常に怒って、バッテリーを集中的に消費します。 これらは、画面をオフにして電話でテストアプリケーションを使用して得た結果です。

これはメモリリークではなく、タイマーがオフになっていないことを主張するかもしれません。これはまったく別のエラーです。 関係ありません アプリケーションでメモリリークをチェックすることにより、他のエラーを見つけることが重要です。 アプリケーションでメモリリークをチェックするとき、存在するはずのすべてのオブジェクトを見つけたいと考えています。 そのようなオブジェクトを見つけると、どのような追加の操作が引き続き実行されるかがすぐにわかります。

第二に 、すべてのアプリケーションがメモリをほとんど消費しないわけではなく、すべての電話機が大量のメモリを割り当てるわけでもありません。

わずか5分で55のアンロードされた画面の後にクラッシュしたアプリケーションを覚えていますか？ そのため、同じアプリケーションの場合、OutOfMemoryExceptionからクラッシュの1〜2週間のレポートを受け取ります（主に4.0までのデバイスから、アプリケーションには50,000のインストールがあります）。 これは、アプリケーションにメモリリークがないという事実にもかかわらずです。 したがって、特にアプリケーションが大量のメモリを消費する場合、メモリリークのあるアプリケーションをレイアウトすることで、カルマをかなり損なうことができます。 アンドロイドの世界ではいつものように、過酷なプレゼントは私たちを輝かしい未来から引き離します。

第三に、男はすべてを行うことができなければなりません！ （私は3つの理由すべてが深刻になると約束した）

メモリリークをキャッチするように説得したいので、それらが発生する主な理由を見てみましょう。

静的変数にアクティビティ参照（ビュー、フラグメント、サービス）を保存しない

すべての初心者開発者が直面する最初の質問の1つは、あるアクティビティから次のアクティビティにオブジェクトを転送する方法です。 私が定期的に見ている最も単純で最も間違った解決策は、最初のアクティビティを静的変数に書き込み、2番目のアクティビティからこの変数にアクセスすることです。 これは非常に失敗したアプローチです。 メモリリークを即座に引き起こすだけでなく（アプリケーションが存在する限り静的変数は存在し続け、それが参照するアクティビティはアンロードされません）。 また、この方法では、ユーザーに表示されない画面はユーザーが戻ったときにのみいつでも破棄および再作成できるため、間違った画面と情報を交換する状況につながる可能性があります。

アクティビティの漏れがなぜそんなに大きな問題なのですか？ 実際のところ、ガベージコレクターがアクティビティを収集しない場合、すべてのビューとフラグメント、およびアクティビティ上にある他のすべてのオブジェクトは収集されません。 写真を含むはリリースされません。 したがって、アクティビティのリークは、原則として、アプリケーションで発生する可能性がある最大のメモリリークです。

静的変数へのアクティビティ参照を記述しないでください。 Intentを介したオブジェクトの転送を使用するか、一般的にはオブジェクトではなくオブジェクトのIDを転送します（このIDを取得できるデータベースがある場合）。

この項目は、Androidによって直接または間接的にライフタイムが制御されるオブジェクトにも適用されます。 つまり 表示、フラグメント、サービスなどに。

ビューおよびフラグメントオブジェクトには、それらが配置されているアクティビティへのリンクが含まれているため、1つのビューがリークした場合、すべて-アクティビティとその中のすべてのビューがすぐにリークします。画面からのリンクがあります！

アクティビティへのリンク（ビュー、フラグメント、サービス）を他のオブジェクトに転送するときは注意してください

簡単な例を考えてみましょう。ソーシャルネットワークのアプリケーションでは、アプリケーションの各画面に現在のユーザーの姓、名、評価が表示されます。 現在のユーザーのプロファイルを持つオブジェクトは、アカウントにログインしてから終了するまで存在し、アプリケーションのすべての画面が同じオブジェクトで情報を求めます。 このオブジェクトは、評価が頻繁に変更される可能性があるため、サーバーからのデータも定期的に更新します。 プロファイルを持つオブジェクトは、評価の更新の現在のアクティビティを通知する必要があります。 これを達成する方法は？ 非常にシンプル：

@Override protected void onResume() { super.onResume(); currentUser.addOnUserUpdateListener(this); } 

この状況でメモリリークを達成する方法は？ また、非常に簡単です！ onPauseメソッドで通知の購読を解除するのを忘れてください：

 @Override protected void onPause() { super.onPause(); /*           */ currentUser.removeOnUserUpdateListener(this); } 

このようなメモリリークが原因で、画面がユーザーに表示されなくなった後でも、プロファイルが更新されるたびにアクティビティがインターフェイスを更新し続けます。 さらに悪いことに、この方法では、画面は同じ通知に対して2、3、またはそれ以上の回数署名できます。 これにより、この画面だけでなく、プロファイルの更新時にインターフェイスブレーキが表示される可能性があります。

このエラーを回避するにはどうすればよいですか？

まず 、もちろん、アクティビティがバックグラウンドを離れたときに、すべての通知の購読を解除したことを常に注意深く監視する必要があります。

次に 、アプリケーションでメモリリークを定期的にチェックする必要があります。

第三に、問題に対する代替アプローチがあります：オブジェクトへのリンクではなく、 弱いリンクを保存できます 。 これは、ビュークラスの相続人にとって特に便利です。onPauseメソッドがないため、どの時点で通知の購読を解除すべきかが明確ではありません。 弱いリンクはガベージコレクターとオブジェクト間のリンクとは見なされないため、弱いリンクのみが存在するオブジェクトは破棄され、リンクはオブジェクトの参照を停止し、nullになります。 使用するのにあまり便利ではない弱いリンクをいじらないために、おおよそ次のテンプレートクラスを使用できます。

 public class Observer<I> { private ArrayList<I> strongListeners = new ArrayList<I>(); private ArrayList<WeakReference<I>> weakListeners = new ArrayList<WeakReference<I>>(); public void addStrongListener(I listener) { strongListeners.add(listener); } public void addWeakListener(I listener) { weakListeners.add(new WeakReference<I>(listener)); } public void removeListener(I listener) { strongListeners.remove(listener); for (int i = 0; i < weakListeners.size(); ++i) { WeakReference<I> ref = weakListeners.get(i); if (ref.get() == null || ref.get() == listener) { weakListeners.remove(i--); } } } public List<I> getListeners() { ArrayList<I> activeListeners = new ArrayList<I>(); activeListeners.addAll(strongListeners); for (int i = 0; i < weakListeners.size(); ++i) { WeakReference<I> ref = weakListeners.get(i); I listener = ref.get(); if (listener == null) { weakListeners.remove(i--); continue; } activeListeners.add(listener); } return activeListeners; } } 

これは次のように動作します：

 public class User { ... public interface OnUserUpdateListener { public void onUserUpdate(); } private Observer<OnUserUpdateListener> updateObserver = new Observer<OnUserUpdateListener>(); public Observer<OnUserUpdateListener> getUpdateObserver() { return updateObserver; } } ... @Override protected void onFinishInflate() { super.onFinishInflate(); /*        */ currentUser.getUpdateObserver().addWeakListener(this); } /* ...        */ ... 

はい、このビューの不要な更新を取得できます。 しかし、多くの場合、これは悪の少ない方です。 また、どのような状況でも、メモリリークは発生しません。

addWeakListenerメソッドを使用するときの微妙な点は1つだけです。追加するオブジェクトを誰かが参照する必要があります。 そうしないと、ガベージコレクターは最初の通知を受け取る前にこのオブジェクトを破棄します。

 /*   ! */ currentUser.getUpdateObserver().addWeakListener(new OnUserUpdateListener() { @Override public void onUserUpdate() { /*      */ } }); 

画面を終了するときにキャンセルされないタイマーとスレッド

この問題については既に上で説明しました。ソーシャルネットワーク用のアプリケーションを開発しました。 このアプリケーションでは、ユーザー間でメッセージを交換でき、新しいメッセージを受信するために10秒ごとにサーバーへの要求を行うタイマーをメッセージング画面に追加しますが、画面を終了するときにこのタイマーをオフにするのを忘れました：

 public class HandlerActivity extends Activity { private Handler mainLoopHandler = new Handler(Looper.getMainLooper()); private Runnable queryServerRunnable = new Runnable() { @Override public void run() { new QueryServerTask().execute(); mainLoopHandler.postDelayed(queryServerRunnable, 10000); } }; @Override protected void onResume() { super.onResume(); mainLoopHandler.post(queryServerRunnable); } @Override protected void onPause() { super.onPause(); /*             */ /* mainLoopHandler.removeCallbacks(queryServerRunnable); */ } ... } 

残念ながら、この問題を回避することは困難です。 与えることができる2つのヒントは、前の段落と同じです。メモリリークがないか、注意して定期的にアプリケーションを確認してください。 弱いリンクを使用して、前の段落と同様のアプローチを使用することもできます 。

アクティビティ内のフラグメントまたは別のフラグメントへの参照を保存しない

このエラーは何度も見ました。 画面には常に1つしか表示されていませんが、アクティビティは5〜6個の実行中のフラグメントへのリンクを保存します。 異なる時間に画面に表示されるフラグメントは、直接キャッシュされたリンクを介して互いに通信します。 このようなアプリケーションでは、FragmentManagerはほとんどの場合初歩的な役割を果たします-適切なタイミングでコンテナの内容を目的のフラグメントに置き換え、フラグメント自体はバックスタックに追加されません（バックスタックに直接リンクしているフラグメントを追加すると、遅かれ早かれにつながりますフラグメントはメモリからアンロードされます;このフラグメントに戻った後、新しいフラグメントが作成され、リンクは引き続き既存のリンクにリンクされますが、ユーザーフラグメントには表示されません）。

これはいくつかの理由で非常に悪いアプローチです。

まず、アクティビティに5〜6個のフラグメントへの直接リンクを保存する場合、5〜6個のアクティビティへのリンクを保存した場合と同じです。 アクティビティの実行中は、インターフェイス全体、すべての画像、および5つの未使用フラグメントのすべてのロジックをメモリからアンロードできません。

第二に、これらのフラグメントは再利用が非常に難しくなります。 フラグメントをフラグメント、x、y、zと同じアクティビティで実行する必要がある場合、フラグメントをプログラム内の別の場所に転送してください。転送する必要はありません。

フラグメントをアクティビティとして扱います。 それらを可能な限りモジュール化し、アクティビティとfragmentManagerを介してのみフラグメント間で通信します。 これは非常に複雑なシステムのように見えるかもしれません。リンクを渡すだけでいいのに、なぜそんなに一生懸命努力するのでしょうか？ しかし、実際には、このアプローチによりプログラムがより良く簡単になります。

このトピックに関するGoogleの優れた公式記事「他のフラグメントとの通信」があります。 この記事を読み直して、スニペットへのポインタを再度保存しないでください。

一般ルール

前の4つの段落を読んだ後、実際には違いがないことに気付くかもしれません。 これらはすべて、1つの一般規則の特殊なケースです。

すべてのメモリリークは、ライフサイクルが長いオブジェクト（長命オブジェクト）でライフサイクルが短いオブジェクト（短命オブジェクト）への参照を保存した場合にのみ発生します。

これを念頭に置いて、常にそのような状況に注意してください。

このルールには、KISS、YAGNI、RTFMなどの美しい短い名前はありませんが、Androidのアクティビティだけでなく、ガベージコレクターを持つすべての言語とすべてのオブジェクトに適用されます。

メモリリークの主な原因を示したので、作業中のアプリケーションでそれらを識別することに最後に進みましょう。

アプリケーション内のどの行を修正するかを見つけるには、どこをクリックしますか？

したがって、メモリリークを回避する方法は知っていますが、これは、メモリリークを回避する方法を学習する前に作成したタイプミス、バグ、およびプロジェクトからあなたを保護しません。

アプリケーションのメモリリークの存在と原因を判断するには、少しの時間とMATが必要です。 以前にMATを使用したことがない場合は、Eclipseのプラグインとしてインストールし 、DDMSパースペクティブを開き、「Dump HPROF file」ボタンを見つけます。 このボタンを押すと、選択したアプリケーションのメモリダンプが開きます。 Android Studioを使用する場合、現時点ではMATがAndroid Studioのプラグインとしてまだ存在しないため、プロセスはもう少し複雑になります。 MATを別のプログラムとして配置し、 stackoverflowで命令を使用します。

次の手順に従ってください：

1. コンピューターに接続されているデバイスにアプリケーションをインストールし、すべての画面に少なくとも1回表示されるように使用します。 1つの画面を異なるパラメーターで開くことができる場合は、可能なすべてのパラメーターの組み合わせで画面を開いてみてください。 一般的には、リリース前にチェックしているように、アプリケーション全体を調べます。 すべての画面を完了したら、アプリケーションを終了するまで戻るボタンを押します。 ホームボタンを押さないでください-あなたのタスクは、実行中のすべてのアクティビティを完了することであり、それらを非表示にするだけではありません。
2. Cause GCボタンを数回押します。 そうしないと、ダンプには、ガベージコレクターによって破壊されるが、まだ破壊されていないオブジェクトが表示されます。
3. 「HPROFファイルのダンプ」ボタンをクリックして、アプリケーションのメモリをダンプします。
4. 開いたウィンドウで、OQLクエリを作成します。「SELECT * FROM instanceof android.app.Activity」
   
   
   
   
   結果のリストは空でなければなりません。 リストに少なくとも1つの要素がある場合、この要素はメモリリークです。 スクリーンショットでは、まさにそのような要素を見ることができます-HandlerActivity：これはメモリリークです。 リスト内の各アイテムについて、手順8〜10を実行します。
5. フラグメントの子孫に対して同様のクエリを実行します：「SELECT * FROM instanceof android.app.Fragment」。 前のケースと同様に、結果のリストに含まれるのはメモリリークだけです。 それらのそれぞれについてポイント8-10を完了します。
6. ヒストグラムを開きます。 ヒストグラムに表示される結果は、オブジェクトではなくクラスを表示するという点でOQLに表示される結果とは異なります。 フィルターフィールドに、クラスに使用するパッケージ名を入力し（スクリーンショットではcom.examples.typicalleaks）、オブジェクト列（システムに現在存在するこのクラスのオブジェクトの数）で結果をソートします。 結果には、ダンプ時にインスタンスが0個存在したクラスも表示されることに注意してください。 これらのクラスは興味がありません。 本当に多くのオブジェクトがある場合は、テーブル全体を選択し、右クリックして[正確な保持サイズの計算]を選択します。 [保持ヒープ]フィールドでテーブルをソートし、保持ヒープ値が大きい（たとえば10000を超える）オブジェクトのみを考慮します。
   
   
   
   
   今回は、リストに表示されるすべてのクラスオブジェクトがメモリリークではありません。 ただし、これらのクラスはすべてアプリケーションのクラスであり、これらの各クラスのオブジェクトが特定の時点でいくつ存在する必要があるかを大まかに理解する必要があります。 たとえば、スクリーンショットでは、Exampleクラスの6つのオブジェクトと1つの配列Example []が表示されています。 これは正常です-Exampleクラスは列挙型であり、そのオブジェクトは最初の呼び出しで作成され、アプリケーションが存在する限り存在します。 しかし、HandlerActivityとHandlerActivity $ 1（HandlerActivity.javaファイル内で宣言された最初の匿名クラス）は、すでによく知られているメモリリークです。 疑わしいクラスを右クリックしてリストオブジェクトを選択し、結果のリストからオブジェクトの1つに対して手順8〜10を実行します。
7. このステップで、疑わしいオブジェクトが1つも蓄積されていない場合、おめでとうございます！ アプリケーションに重大なメモリリークはありません。
8. 疑わしいオブジェクトを右クリックし、[最短パスをGCルートにマージ]を選択します-すべてのファントム/弱い/ソフトなどを除外します。 参照。
9. ツリーを開きます。 次のようなものが得られるはずです。
   
   
   
   
   一番下に、疑わしいオブジェクトが表示されます。 最上部はガベージコレクターのルートです。 中央のすべては、疑わしいオブジェクトをガベージコレクターのルートに接続するオブジェクトです。 ガベージコレクターが疑わしいオブジェクトを破壊することを許可しないのは、このチェーンです。 このチェーンは次のように読む必要があります。リストの上のオブジェクトの変数は太字で書かれており、変数名の右側にあるオブジェクトへのリンクが含まれています。 つまり スクリーンショットでは、MessageQueueオブジェクトの変数mMessagesには、Messageオブジェクトへの参照が含まれています。Messageオブジェクトには、この$ 0変数内のHandlerActivityオブジェクトへの参照を含むHandlerActivity $ 1オブジェクトを参照するコールバック変数が含まれています。 つまり、疑わしいHandlerActivityオブジェクトは、HandlerActivity.javaファイルで宣言された最初のRunnableを保持します。これは、postまたはpostDelayedメソッドを使用してハンドラーに追加されるためです。 アプリケーションの一部であるリストの一番下から最後のクラスを見つけて右クリックし、[ソースファイルを開く]を選択します。
10. 疑わしいオブジェクトが不要になった時点で、疑わしいオブジェクトとガベージコレクターのルートの間のチェーンを切断するように、アプリケーションコードを修正します。 この例では、onPause HandlerActivityメソッドでHandler.removeCallbacks（Runnable r）メソッドを呼び出すだけです。
11. すべての疑わしいオブジェクトを処理したら、ステップ1からアルゴリズムを繰り返して、すべてが正常に機能していることを確認します。

おわりに

アプリケーションのすべての画面をクリックして、疑わしいオブジェクトが見つからなかった場合、99.9％の確率で、アプリケーションに深刻なメモリリークはありません。

これらのチェックは、ほとんどすべてのアプリケーションにとって本当に十分です。 アプリケーションに実際に影響を与える可能性のあるメモリリークにのみ関心があります。 文字列uuidと2、3の短い行を含むオブジェクトの漏洩は間違いであり、修正するだけの価値はありません。