Есть ли потеря производительности (или утечка памяти) при сохранении виджетов в приложении?

#android #performance #android-context #slidingdrawer

#Android #Производительность #android-контекст #slidingdrawer

Вопрос:

У меня есть SlidingDrawer, на который ссылаются во всех моих действиях. Ящик довольно подробный и имеет глубокую иерархию представлений. В настоящее время все мои действия вызывают контекст приложения при создании, чтобы получить одноэлементную копию ящика. Когда вызывается activities onPause, он удаляет ящик из группы просмотра верхнего уровня. Это работает, но я не знаю, лучший ли это способ сделать это.

Также проблема, с которой я сталкиваюсь, заключается в использовании контекста. В SlidingDrawer есть несколько кнопок, которые запускают некоторые диалоговые окна. Зная, что я не могу передать контекст приложения, я просто создал OnActivityChangeBroadcaster и Listener , которые изменили контекст ссылок для ящика. Но даже при этом диалоговое окно всегда появляется в активности запуска.

У кого-нибудь есть какие-либо мысли или мудрость по этому поводу?

Ответ №1:

Это работает, но я не знаю, лучший ли это способ сделать это.

Происходит утечка памяти. Никогда не передавайте виджеты между действиями. Никогда не помещайте виджеты или что-либо еще со ссылкой на действие в Application объект или элемент статических данных, если вы не собираетесь null удалять эту ссылку при уничтожении действия.

У кого-нибудь есть какие-либо мысли или мудрость по этому поводу?

Пожалуйста, создайте свой ящик для каждого действия.

Ответ №2:

Мой подход заключался бы в том, чтобы отделить пользовательский интерфейс от данных. Если во многих ваших действиях используется один и тот же SlidingDrawer, я бы разделил данные, отображаемые SlidingDrawer, в свой собственный класс [не пользовательский интерфейс], чтобы он существовал только в одном месте, и заставил каждый экземпляр SlidingDrawer заполнять себя из этих данных. Вы можете определить свой SlidingDrawer в XML один раз и <include> использовать его во всех макетах, которые вам нужны.

Тогда у меня была бы одна функция, которая заполняла бы SlidingDrawer данными из вашего отдельного класса (доступными через одноэлементный объект или путем создания данных static ). Для достижения этой цели вы можете либо создать static метод, который использует SlidingDrawer для заполнения в качестве параметра ( public static void loadSlidingDrawer(SlidingDrawer destinationView) {...} ), либо вы можете расширить SlidingDrawer и сделать этот метод класса доступным для каждого экземпляра.

CommonsWare верен, ваша текущая стратегия приведет к утечке памяти повсюду. Элементы пользовательского интерфейса должны обладать гибкостью, чтобы их можно было постоянно уничтожать и создавать заново, поэтому это действительно хорошая привычка — разделять все ваши данные на классы, отличные от пользовательского интерфейса, к которым пользовательский интерфейс просто обращается для отображения. Это прекрасно все разделяет и позволяет платформе эффективно функционировать.