プロジェクトの1つで、メモリリークが発生しました。 開発者の最初のルールであるgoogleを利用しました。 残念ながら、プログラマー向けの記事が多く、テスター向けの記事がかなりありました。 ほとんどの出版物の日付は2011-2014です。
以下は、2017年に役立つメモリリークに関する情報です。 その存在がアプリケーションをどのように脅かすかを説明し、ローカライズへのいくつかのアプローチをリストします。
メモリリークがアプリケーションに与える影響
アプリケーションでは、多くのオブジェクトの寿命は限られています。 その後、ガベージコレクターによって破棄されます。 ただし、リンクのチェーンを介してオブジェクトにアクセスできる場合、そのオブジェクトはコンパイルされません。 アプリケーションはメモリを割り当てますが、メモリを解放しません。これは、制限がなくなりクラッシュが発生するまで発生します。
アプリケーションがOutOfMemoryErrorエラーでクラッシュしたときの最初のベルですが、ラッパの呼び出しです。 このエラーは、アプリケーションに割り当てられたメモリが不足していることを示しています。
時々それはそれほど明白ではありません。 安定した合理化された音楽プレーヤーアプリケーションがありました。 いくつかの新しい画面を備えたビルドがテスト用に届くまではそうでした。 最初は、アプリケーションは通常どおりに動作しましたが、約10分後に速度が低下し始めました。 アラートなしでハングまたはクローズすることもありました。 GLRendererなど、ネイティブの「モノ」でクラッシュが発生しました。
テスターがリークを見つける方法を知っているのはなぜですか
開発者に、アプリケーション自体が縮小したり、速度が低下したり、フリーズしたりすると言っても、ほとんど役に立たないでしょう。 問題を特定し、再生の正確な手順を探すためにあなたを送ります。 開発者は、あなたのイニシアチブが衰退し、あなたがもはやそのようなナンセンスで彼に来ないことを望んでいます。 しかし、あなたはアプリケーションの品質と安定した動作のための戦闘機なので、ただそのように放置しないでください。 問題を特定し、開発者にその重要性と重要性を正当化する必要があります。 次に、あなたは本当に「十字軍」の合理性と必要性を考慮する必要があります。
すべてのモバイルアプリケーションを2つのタイプに分けます。
ユーザーは10分以内に申請中です
例は、チケットを購入するためのモバイルアプリケーション、モバイルバンク、オーガナイザーです。 ユーザーはアプリケーションにログインして、特定の目標を達成します。
この場合、漏れを慎重に監視する必要はありません。 マイナーな人は、アプリケーションに深刻な影響を与える時間がありません。 また、たとえば、画面がアクセスされるたびに画面が再作成される場合、大きなものは簡単に見つかります。
ユーザーがアプリケーションに10分以上滞在している
これは音楽プレーヤーとソーシャルについての物語です。 ユーザーが何時間も強度をテストするネットワーク。 テストに加えて、メモリリークとアプリケーションの安定した動作を監視する必要があります。 40分間のセッション中にわずかな漏れがあっても、作業に影響する可能性があります。
ゲームがろうそくに値する場合は、行動を起こしてください。 メモリリークをローカライズするためのいくつかのアプローチについて説明します。
リークローカライズアプローチ
素手でローカライズ
運がよければ、リークの原因となるシーケンスがすぐに見つかります。 時には苦しむ必要があります。 リークを手動で見つけることは非常に時間がかかります。 同じアクションを何十回も繰り返し、これがアプリケーションの動作に影響を与えているかどうかを確認する必要があります。 私は楽観的に、素手でそれを扱えると決めました。 膨大な時間を費やして、パターンを明らかにしました。 タブを20回切り替えた後、アプリケーションは正しく動作しませんでした。 その後、完全にクラッシュしました。 異なるデバイスでは、スイッチの数が異なります。
この知識を持って、開発者に行きました。 数日後、彼らは漏れがカバーされ、すべてが飛ぶと私に言った。 注意、ネタバレ。 そうだった。 新機能と画面まで。 その後、身近な不適切な行動を観察し始めました。
手だけで漏れを見つけようとすると、漏れが実際に覆われているという保証はありません。 おそらく、それはあなたのステップに沿って再生されません。
ヒント：リークをローカライズするときは、まず画面のネストを確認します。 深いほど良い。 すべてを考慮する必要があります：プッシュ、写真付きオブジェクト、アニメーション、リスト、要素が表示されたマップ、垂直および横向き。
特別なツールを使用して見つける
Android Studioパッケージの標準ツールであるMemory Monitorに助けられました。 詳細については、 Android Studioユーザーガイドを参照してください 。
リークを探し始めたばかりであれば、 MonkeyをMemory Monitorと組み合わせて実行すると非常に便利です。 このプログラムは、ストレステストに最適です。 アプリケーション内をランダムに移動し、タップ、クリック、ジェスチャーなどのユーザーイベントを生成します。 詳細については、Android Studioユーザーガイドもご覧ください。
これらの2つのツールは、アプリケーションにリークがあるかどうかを理解するのに役立ちます。 サルがアプリケーション内を移動している間、画面上のグラフを見ています。 アプリケーションには一定量のメモリが必要であり、これは常に関与しています。 ほぼ同じレベルに維持する必要があります。 アプリケーション内を移動すると、サルは徐々にメモリを詰まらせます。 ガベージコレクターを呼び出した後、元の値に戻る必要があります。 コレクターの後にメモリがクリアされない場合、リークを意味します。
サルは、生殖ステップの検索には適していません。 モニターを観察しながら、アプリケーションを手動で意識的にナビゲートする必要があります。
新しいビルドは素手でテストすることを敢えてしませんでした。 メモリモニターを起動し、アプリケーションを開いて監視しました。 パターンが発見されました。 曲リスト画面に表示されたすべてのトラックは、次の画面に移動するときにメモリでハングしました。 ヒープダンプを収集し、開発者に送信しました。 問題は、スクロール後に画面のトラックのセルが消えたときにセルのRecyclerView onViewDetachedFromWindowメソッドが呼び出されたが、onDestroyViewの呼び出し中に画面が閉じられたときに呼び出されなかったことです。 そして、トラックのセルの状態の変化からサブスクライブを解除したのはそこです。 したがって、画面を閉じた後、すべてのリストへのリンクがありました。
これで、アプリケーションには22の画面があります。 ほとんどすべてのトラックから、アルバム画面に移動できます。 リリースからリリースへと、リークの問題は調査の結果が出るまで悪化しました。 その後初めて、メモリリークを実際にカバーしました。
ヒント：メモリモニターを起動するときに、残りのモニターを一時停止すると、互いに干渉する可能性があります。 開発者にヒープをダンプする前に、ガベージコレクターを呼び出します。
漏れと戦う方法をコメントに書いてください。