Понимание утечки памяти в приложении Android

Question

я нашел статью "Avoiding memory leaks", в котором говорится, что следующий код:

private static Drawable sBackground; 

@Override 
protected void onCreate(Bundle state) { 
    super.onCreate(state); 

    TextView label = new TextView(this); 
    label.setText("Leaks are bad"); 

    if (sBackground == null) { 
    sBackground = getDrawable(R.drawable.large_bitmap); 
    } 
    label.setBackgroundDrawable(sBackground); 

    setContentView(label); 
} 

не является хорошей идеей, так как:

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

Так выше код:

... просачивается первое действие, созданный при первом изменении ориентации экрана. Когда Drawable прикреплен к представлению, вид устанавливается как обратный вызов для выделенного объекта. В фрагменте кода выше, это означает, что рисуем имеет ссылку на TextView, который сам по себе имеет ссылку на деятельности (Context), который в свою очередь имеет ссылки на почти все (в зависимости от вашего кода.)

Но, когда изменения ориентации экрана, метод setBackgroundDrawable(Drawable background) называется, который, в свою очередь, вызывает:

background.setCallback(this); 

метод Drawable.setCallback() является определяемом следующим образом:

public final void setCallback(Callback cb) { 
    mCallback = new WeakReference<Callback>(cb); 
} 

Итак, теперь фон должен выпустить старую ссылку на предыдущий TextView и создать новую ссылку на новый TextView.

Таким образом, кажется, что изменение ориентации экрана утечки ссылки только до тех пор, пока активность не будет создана.

Куда я иду не так?

Answer 1

Вы абсолютно правы. Однако есть один тонкий момент: статья от . Тогда реализация setCallback была different:

Android < = 2.3.7:

public final void setCallback(Callback cb) { 
    mCallback = cb; 
} 

Android> = 4.0.1:

public final void setCallback(Callback cb) { 
    mCallback = new WeakReference<Callback>(cb); 
} 

_{Grepcode не обнаруживающей исходный код промежуточных версий, это единственный способ, который я мог бы быстро найти.}

---

Итак, опять же, вы абсолютно правы в данном конкретном случае (если вы ориентируетесь> 14, что есть). Тем не менее, по-прежнему очень важно действительно думать о том, что на самом деле происходит, когда вы сохраняете статическую ссылку на такие предметы (как и вы). Существует множество случаев, когда вы, конечно, можете просачивать Context.