Когда это нормально использовать сильные ссылки в Android, и этот код течет? - PullRequest
0 голосов
/ 01 сентября 2018

Мне не ясно, когда лучше использовать WeakReference, чтобы избежать утечек памяти в Android. Пример:
Код в фрагменте:

containerView.setDataForDisplay(customer, new CustomListener() {    
      @Override  
      public void buttonClicked(@NonNull Customer customer) {  
                if(handler != null) {
                    handler.buttonClickedForCustomer(customer);  
                }  
            }  
        });  

Код внутри кастома LinearLayout

public void setDataForDisplay(List<Customer> customer, CustomListener listener) {  
 // view setup code  

 someView.setOnClickListener( v -> {  
    if(listener != null) {  
       listener.buttonClicked(v.getTag());  
    }  
 });
}  

Анонимный класс CustomListener имеет ссылку на содержащий фрагмент this.
Этот анонимный класс передается как слушатель содержащему представление, которое, в свою очередь, в конечном итоге выполняет обратный вызов

У меня вопрос, это приводит к утечке памяти?
Должен ли listener быть как-то в WeakReference? Как мы решаем, когда хорошо иметь сильную ссылку против слабой?

Ответы [ 2 ]

0 голосов
/ 01 сентября 2018

Современная JVM имеет очень мощный сборщик мусора. Ему удается собирать даже циклические ссылки, обнаруживая объекты, которые полностью изолированы от корней gc. Вы можете прочитать больше на эту тему здесь: Как на самом деле работает сборка мусора

При использовании слабых ссылок. однако вы можете ускорить работу gc, поскольку эти ссылки должны быть собраны сразу после того, как все сильные ссылки на этот объект исчезнут.

0 голосов
/ 01 сентября 2018

Нет, это не утечка памяти.

Упрощенный граф ссылок может выглядеть примерно так:

references graph

Да, график содержит циклическую ссылку, но сборщик мусора вполне способен обнаружить и разрешить эту ситуацию. Весь график будет GC'd после того, как система потеряет свою ссылку на Fragment, который, как правило, будет примерно в то время, когда он будет удален с экрана.

Я не могу придумать ситуацию, когда WeakReference был бы необходим для предотвращения утечки памяти. (Я не говорю, что их не существует, я просто не могу их придумать.)

Я вижу WeakReferences как инструмент для сложных задач управления памятью, который редко появляется в общей разработке приложений. Например: Управление коллекцией крупных предметов, где OK , если некоторые из них получают GC'd (когда заканчивается память), но вы бы вместо сохранили их в оперативной памяти.

IOW: Не храните ссылки, которые вам не нужны, и вы должны быть в порядке.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...