MemoryLeak trough onConfigurationChanged()

Question

У меня есть AsyncTask, который мне нужно перезапустить, если пользователь выполняет настройки, такие как Switch Color.

Когда он сделал так, я начинаю AsyncTask так:

myWorkerClass.clearMemory(); 
    myWorkerClass = new WorkerClass(getApplicationContext(), gv, searchbar, width, scaleButtonText); 
    myWorkerClass.execute(); 

В AsyncTask я добавить onTextChangeListener к моему EditText (который вызывает MemoryLeak позже!).

Для предотвращения MemoryLeaks у меня есть метод в моей AsyncTask который удаляет onTextChangedListener:

public void clearMemory() { 
    searchbar.removeTextChangedListener(myTextWatcher); 
} 

Все хорошо, за исключением, когда я повернуть мое устройство работает. Когда я повернуть мое устройство я сделать это только в onConfigurationChanged:

myWorkerClass.clearMemory(); 
      myWorkerClass = new WorkerClass(getApplicationContext(), gv, searchbar, width, scaleButtonText); 
      myWorkerClass.execute(); 

Как вы можете видеть, я сделать то же самое, как если изменяется пользователь цвет. Но на вращающемся устройстве я течет Память, при переключении Цвет я не!

Это после включения цвета:

Это после поворота экрана несколько раз (помните, я делать точно так же, как и при переключении цвета:

Это мои подозреваемые в утечке из кучи кучи:

Это мое доминатором дерево:

Почему я знаю onTextChangeListener это проблема?

Потому что, если я комментирую добавление onTextChangedListener в свой EditText, все работает нормально. Нет утечек памяти.

Мой вопрос:

Почему утечка памяти Rotation Изменение и изменение цвета не когда я начать AsyncTask точно так же, как и делать точные те же вещи в AsyncTask?

Я искал немного: http://developer.android.com/guide/topics/resources/runtime-changes.html

Но я не могу понять, если это моя проблема. Поворот должен делать что-то другое, например, создавать новое действие из-за этого, создавая новую ссылку на мой edittext. И из-за этого он не может удалить старый onTextChangeListener.

Пожалуйста, поймите.Я не хочу публиковать весь свой код. Но я думаю, что это не обязательно в этом случае.

Я ценю любую помощь.

Заранее спасибо

Answer 1

Вращение должно сделать что-то другое, как создать новый вид деятельности из-за того, что создает новую ссылку на мой EditText.

именно он разрушает вашу текущую деятельность и создает новую. Если searchbar переменная член вашей AsyncTask затем рассмотреть вопрос сдачи его в WeakReference:

WeakReference<SearchBar> searchbarPtr; 

затем получить доступ с помощью searchBarPtr.get(), но проверить, если его нуль, если да, то это означает, что он был сборщиком мусора из-за конфигурации изменение.

Также не забудьте не сделать ваш AsyncTask внутренним классом вашей деятельности. Если он вложен, сделайте его статическим. В противном случае ваша asynctask будет ссылаться на вашу активность, и это предотвратит ее уничтожение - пока ее поток не закончится.

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

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

Answer 2

В андроиде вращение разрушает вашу текущую деятельность, чтобы начать новую.
Чтобы избежать этого, вы можете добавить android:configChanges="orientation|screenSize" в файл манифеста.

Ниже приведены советы, чтобы избежать утечки памяти об изменении вращения

1. Не хранить долгоживущие ссылки на контекстно-активности (ссылка на деятельность должна иметь тот же жизненный цикл, как и сама деятельность)
2. Попробуйте использовать контекстное приложение вместо контекстной активности
3. Избегайте нестатических внутренних классов в действии, если вы не контролируете свой жизненный цикл, используйте статический внутренний класс и слабо ссылаетесь на активность внутри. Решение этой проблемы заключается в использовании статического внутреннего класса с WeakReference к внешнему классу, как это было сделано в ViewRoot и его W внутренний класс, например
4. Сборщик мусора не является страхование от утечек памяти

Источник: Avoiding memory leaks