Androidでのメモリリークとの戦い。 パート1

この記事では、Android向けの開発に関するHabréに関する一連の記事を開きます。

2012 Crittercismレポートによると、OutOfMemoryErrorはモバイルアプリのクラッシュの2番目の主要な原因です。

正直なところ、Badooでは、このエラーがすべてのクラッシュのトップにありました（ユーザーが表示する写真の量では驚くことではありません）。 OutOfMemoryとの戦いは骨の折れる作業です。 Allocation Trackerを選択し、アプリケーションの使用を開始しました。 予約されたメモリのデータを観察して、メモリの割り当てが疑わしい速度で増加し、減少を忘れるいくつかのシナリオを特定しました。 これらのシナリオの後、いくつかのメモリダンプを準備して、MAT（ http://www.eclipse.org/mat/ ）で分析しました。

結果は面白く、数週間以内にクラッシュの数を減らすことができました。 コードに固有のものがありましたが、ほとんどのAndroidアプリケーションに特有の典型的な問題も明らかにしました。

今日は、メモリリークの特定のケースについて説明します。 多くの人が彼について知っていますが、しばしばこれに目をつぶっています（しかし無駄です）。



android.os.Handlerの誤用に関連するメモリリークについて説明します。 完全に明らかではありませんが、ハンドラーに入れたものはすべてメモリー内にあり、ガベージコレクターによってしばらくクリアできません。 時には非常に長い。

少し後に、何が起こっているのか、なぜメモリを解放できないのかを例で示します。 好奇心はないが、問題の対処方法を知りたい場合は、記事の最後にある結論に進んでください。 または、すぐにオープンアクセスにした小さなライブラリのページhttps://github.com/badoo/android-weak-handlerに移動します 。



それで、そこに「流れる」ことは何ですか？ それを理解しましょう。

簡単な例

これは非常に単純なActivityクラスです。 800秒後にテキストを変更する必要があるとします。 もちろん、この例はばかげていますが、記憶の流れがどのように流れるかをよく示しています。

ハンドラーに投稿する匿名のRunnableに注意してください。 長いタイムアウトに注意することも重要です。

テストのために、この例を実行し、電話を7回回転させて、画面の向きを変更し、アクティビティを再作成しました。 次に、メモリダンプを取得し、MAT（ http://www.eclipse.org/mat/ ）で開きました。



OQLを使用して、Activityクラスのすべてのインスタンスを表示する簡単なクエリを実行します。

select * from instanceof android.app.Activity
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OQLについて読むことを強くお勧めします。これは、メモリ分析に非常に役立ちます。

ここでvisualvm.java.net/oqlhelp.htmlまたはここでhelp.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.mat.ui.help%2Freference%2Foqlsyntax.htmlを 読むことができます 。







メモリには7つのアクティビティインスタンスがあります。 これは必要な7倍です。 ガベージコレクターがメモリから使用済みオブジェクトを削除できなかった理由を見てみましょう。 アクティビティの1つへのリンクの最短グラフを開きましょう。







スクリーンショットは、 この$ 0がアクティビティを指していることを示しています。 これは、匿名クラスから外部クラスへの暗黙的な参照です。 Javaでは、外部フィールドやメソッドにアクセスしない場合でも、匿名クラスには常に外部クラスへの暗黙的な参照があります。 Javaは完璧ではなく、人生は苦痛です。 そのようなこと、子猫。



次に、 この$ 0への参照は、リンクされたメッセージリストに保存されるコールバックに保存されます。 チェーンの最後には、メインスレッドのスタック内のローカルリンクがあります。 明らかに、これはUIスレッドのメインループ内のローカル変数であり、サイクルが完了すると解放されます。 私たちの場合、これはアプリケーションが作業を完了した後に発生します。



そのため、RunnableまたはMessageをハンドラーに配置すると、メッセージが機能するまでLooperThreadのメッセージリストに保存されます。 保留中のメッセージを配置すると、そのメッセージが来るまでメモリに残ることは明らかです。 メモリ内のメッセージとともに、メッセージが参照するすべてのオブジェクトが明示的および暗黙的に存在します。

そして、あなたはそれについて何かをする必要があります。

静的クラスソリューション

この$ 0リンクを削除して、問題を解決してみましょう。 これを行うには、匿名クラスを静的クラスに変換します。







起動し、電話を数回回して、メモリダンプを収集します。







再び複数のアクティビティ？ ガベージコレクターがそれらを削除できなかった理由を見てみましょう。







リンクグラフの下部に注意してください。アクティビティは、DoneRunnableクラス内のmTextViewからmContextリンクに格納されます。 明らかに、静的クラスを単独で使用するだけでは、メモリリークを回避するには不十分です。 他のことをする必要があります。

静的クラスとWeakReferenceを使用したソリューション

メモリダンプの調査中に見つかったTextViewリンクを取り除くシーケンシャルな方法を継続します。







WeakReferenceにはTextViewへのリンクが保持されていることに注意してください。 WeakReferenceの使用には特別な注意が必要です。このようなリンクはいつでもリセットできます。 したがって、最初にローカル変数へのリンクを保存し、後者だけを使用して、nullをチェックします。



メモリダンプを実行、回転、および収集します。







目的を達成しました！ 1つのアクティビティのみを念頭に置いています。 問題は解決しました。



このアプローチを使用するには、次のものが必要です。

• 静的な内部または外部クラスを使用する
• 参照するすべてのオブジェクトにWeakReferenceを使用します。

この方法は良いですか？

元のコードと「安全な」コードを比較すると、大量の「ノイズ」が顕著です。 コードを理解するのを妨げ、そのサポートを複雑にします。 このようなコードを書くことは、あなたが何かを忘れたり得点したりすることができるという事実は言うまでもなく、まだ喜びです。



より良い解決策があるのは良いことです。

onDestroyのすべてのメッセージをクリアします

Handlerクラスには、興味深い非常に便利なメソッドremoveCallbacksAndMessagesがあり、引数としてnullを取ります。 このハンドラのキュー内のすべてのメッセージを削除します。 onDestroyで使用してみましょう。







メモリダンプを実行、回転、削除します。







いいね！ 1つのアクティビティクラスのみ。



この方法は、前の方法よりもはるかに優れています。付随するコードの量は最小限であり、ミスを犯すリスクははるかに低くなります。 1つの不幸は、 onDestroyメソッドまたはメモリをクリーンアップする必要がある場所でクリーンアップを呼び出すことを忘れないことです。



在庫にもう1つの方法があります。

WeakHandlerを使用したソリューション

BadooチームはHandler- WeakHandlerを作成しました 。 これは、ハンドラーとまったく同じように動作するクラスですが、メモリリークを排除します。



メモリリークを回避するためにソフトリンクとハードリンクを使用します。 動作の原理については少し後で説明しますが、ここではコードを見てみましょう。







元のコードに非常に似ていますよね？ 1つの小さな詳細だけ： android.os.Handlerを使用する代わりに、 WeakHandlerを使用しました 。 始めましょう、電話を数回回転させて、メモリダンプを削除します。







ついに！ コードは涙のようにきれいで、メモリは流れません。



この方法が気に入った場合、良いニュースがあります。WeakHandlerの使用は非常に簡単です。



プロジェクトにMaven依存関係を追加します。

 repositories { maven { repositories { url 'https://oss.sonatype.org/content/repositories/releases/' } } } dependencies { compile 'com.badoo.mobile:android-weak-handler:1.0' }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードにWeakHandlerをインポートします。

 import com.badoo.mobile.util.WeakHandler
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソースコードはgithub： github.com/badoo/android-weak-handlerに投稿されています。

WeakHandlerの仕組み

主なアイデアは、 WeakHandlerへのハードリンクがある限り、メッセージまたはRunnableへのハードリンクを保持することです 。 WeakHandlerをメモリから削除できるようになるとすぐに、他のすべてのものを削除する必要があります。



説明を簡単にするために、匿名Runnableを単純なHandlerとWeakHandlerに配置することの違いを示す簡単な図を示します 。







上の図に注目してください。アクティビティはRunnableをポストするハンドラーを参照します（スレッドが参照するメッセージキューに配置します）。 RunnableからActivityへの暗黙的なバックリンクを除き、すべて問題ありません。 Messageが存続するキューにある限り、Threadが存続している間は、グラフ全体をガベージコレクターで収集することはできません。 厚いアクティビティを含む。



下の図では、アクティビティは内部にハンドラを保持するWeakHandlerを参照しています。 Runnableを配置するように依頼すると、彼はそれをWeakRunnableにラップしてキューに投稿します。 したがって、メッセージキューはWeakRunnableのみを参照します。 WeakRunnableには、元のRunnableへのWeakReferenceが含まれています。 ガベージコレクターはいつでもクリーニングできます。 彼が事前にクリアしないように、WeakHandlerはRunnableへのハードリンクを保持します。 ただし、WeakHandler自体を削除できるようになるとすぐに、Runnableも削除できます。



WeakHandlerは外部から参照される必要があることを忘れないように注意する必要があります。そうしないと、ガベージコレクターによってすべてのメッセージがクリアされます。

結論

AndroidでpostDelayedを使用するのは見た目ほど簡単ではありません。メモリが流れないように追加の手順を実行する必要があります。 これを行うには、次の方法を使用できます。

• 静的な内部クラスRunnable / Handlerを外部クラスへのWeakReferencesとともに使用します。
• onDestroyメソッドからHandlerクラスのすべてのメッセージをクリアします。
• BadooのWeakHandlerを使用します（ https://github.com/badoo/android-weak-handler ）。

選択はあなた次第です。 最初の方法は間違いなく怠け者向けではありません。 2番目の方法は非常に単純に見えますが、追加の作業が必要です。 3番目は私たちのお気に入りですが、注意する必要があります。必要になるまで、 WeakHandlerには外部リンクが必要です。そうしないと、ガベージコレクターはキューからのすべてのメッセージとともにそれを削除します。



あなたに幸運を！ 私たちと一緒に-このトピックは継続されます。



英語のブログの記事： bit.ly/AndroidHandlerMemoryLeaks



Dmitry Voronkevich、主任開発者