ПРЕДУПРЕЖДЕНИЕ: УТЕЧКА ПАМЯТИ (feat. Java, Android Studio)

Хорошо, пожалуйста, поднимите руки, если вы видели эту ошибку раньше? Или вы обнаружили, что ваше приложение ведет себя странно? Странно, как при странных сбоях приложений, серьезном снижении производительности, когда приложение непрерывно работает в течение длительного времени? Если это звучит знакомо, существует большая вероятность того, что утечка памяти уже происходит в вашем приложении.

Вы знаете, что в Java объекты сохраняются в области памяти, называемой кучей. Как это звучит, в куче мы можем хранить там кучи объектов, хотя иногда они увеличиваются и уменьшаются в размерах. К сожалению, эта куча имеет ограниченное пространство, и как только она достигнет предела, вы увидите OutOfMemoryError сообщение об ошибке. Полезная статья об ошибке ООМ

Вопрос : Тогда как мы можем очистить ненужную память? A : Обычно существует такая вещь, как GC(мусор Collector) в Java, который периодически заботится обо всех неиспользуемых объектах в памяти.

GC: встроенный сборщик мусора (или сокращенно GC). GC неявно заботится о выделении и освобождении памяти и, таким образом, способен решать большинство проблем с утечкой памяти.

Вопрос : Если сборщик мусора может освободить память, почему происходит эта утечка памяти? A : Давайте взглянем на картинку для лучшего понимания!

По сути, когда сборщик мусора освобождает неиспользуемую память, он проверяет это на основе того факта, что на объект нет ссылок или ссылок. Если этот объект идентифицирован как объект без ссылок, то GC рассмотрит его как неиспользуемый объект для очистки и продолжит работу с ним.

Однако в реальном мире, скорее всего, у нас есть объекты, которые на самом деле не используются, но на которые все еще ссылаются другие объекты в приложении. Как и ожидалось, сборщик мусора, очевидно, не способен идентифицировать эти проблемные объекты, и в результате эти объекты останутся неправильно обработанными, используя объем памяти, доступный для приложения, что приводит к неожиданным результатам.

Я имею в виду, это очень похоже на то, когда мы убираем свою комнату или когда мы переезжаем, в ситуации, когда нам приходится избавляться от всего того, что мы на самом деле не используем, чтобы начать все сначала, всегда есть какие-то вещи, которые постоянно беспокоят нас, верно? Если вы большой коллекционер, вы бы поняли, о чем я говорю. Нет никаких сомнений в том, что вы ими не пользуетесь и уже давно ими не пользуетесь но тогда всегда есть какие-то ссылки на него, которые заставляют вас колебаться, удалять ли их но если вы продолжите держать их в своей комнате, они будут занимать большую часть места, и вам нужно будет как-то их убрать.

В любом приложении утечки памяти могут происходить по многим причинам. Есть 3 наиболее распространенных случая.

1. Интенсивное использование статических Первый сценарий, который может привести к потенциальной утечке памяти, – это интенсивное использование статических переменных.

В Java статические поля имеют срок службы, который обычно соответствует всему сроку службы запущенного приложения. Если мы не установим его равным нулю, когда закончим использовать, существует вероятность того, что эти переменные останутся в памяти и станут потенциальной причиной утечек.

2. Растровые изображения Объекты Bitmap в целом довольно тяжелые, и если с ними обращаться неправильно, они могут привести к значительным утечкам памяти, которые в конечном итоге приведут к сбою вашего приложения из-за OutOfMemoryError. В большинстве случаев эти объекты имеют какое-то отношение к изображениям, и если они не обрабатываются в framework, рекомендуется использовать recycle() после их использования.

3. Контексты Другой распространенной причиной утечек памяти является неправильное использование экземпляров контекста. Контекст может показаться знакомым, поскольку is обычно используется как абстрактный класс, который расширяется для обеспечения функциональных возможностей класса.

Однако существует два важных типа контекстов: контекст на уровне действия и контекст на уровне приложения. Если контекст действия используется в неправильном месте, эта ссылка может быть сохранена для всего действия и стать потенциальной утечкой. Вот несколько статей о типах контекстов в Android

Если вы работаете над большим объемом кода приложения, написанного кем-то другим давным-давно, и каким-то образом вам следует выяснить, почему происходит эта утечка памяти, есть 2 удивительных рекомендуемых способа сделать это.

Профилировщик

В документах Android profiler определяется следующим образом: Профилировщик памяти – это компонент профилировщика Android, который помогает вам выявлять утечки памяти и отток памяти, которые могут привести к заиканию, зависаниям и даже сбоям приложений. Он показывает график использования памяти вашего приложения в реальном времени и позволяет захватывать дамп кучи, принудительно собирать мусор и отслеживать распределение памяти.

Итак, предположим, что ваше устройство или эмулятор подключены к Android studio, и вы открываете профилировщик (обычно Просмотр > Окна инструментов > Профилировщик), а затем позволяете приложению немного поработать. Тогда вы увидите что-то похожее на эту картинку.

Тогда вы увидите что-то похожее на эту картинку.

Вы можете внимательно просмотреть график и, вероятно, установить время захвата памяти, если это необходимо, чтобы выяснить, когда происходит утечка памяти, прочитав перечисленные объекты и определив, должны ли эти объекты быть здесь или удалены. Если они существуют, когда их не должно быть, именно здесь обнаруживается утечка памяти, и вы начинаете думать об оптимизации класса.

Этот профилировщик помогает анализировать данные из памяти и предоставляет так много фильтров и подробной информации. Например, он обеспечивает,

Какие типы объектов были выделены и сколько места они используют.
Трассировка стека каждого выделения, в том числе в каком потоке.
Когда объекты были освобождены (только при использовании устройства с Android 8.0 или выше).

Для получения дополнительной информации нажмите здесь, чтобы ознакомиться с документацией по profiler.

Утечка канализации

LeakCanary – это Java-библиотека с открытым исходным кодом для обнаружения утечек памяти в ваших отладочных сборках. Самое большое преимущество использования LeakCanary заключается в том, что LeakCanary автоматически покажет уведомление при обнаружении утечки оперативной памяти в вашей отладочной сборке.

Самое большое преимущество использования LeakCanary заключается в том, что LeakCanary автоматически покажет уведомление при обнаружении утечки оперативной памяти в вашей отладочной сборке.

Подводя итог, можно сказать, что по мере увеличения размера приложения становится все труднее устранять сбои приложений и выяснять причины. В том же смысле, поскольку куча памяти не является чем-то четко видимым для нас, действительно сложно точно знать, где и когда происходит утечка памяти. Используя профилировщик и библиотеку, такие как LeakCanary, мы можем, по крайней мере, диагностировать проблему с помощью некоторых значимых данных и анализа, полученных для начала устранения неполадок в нужной точке.