Оптимизация AsyncTask относительно внутреннего списка

Люди, у меня есть задача async, которая загружает некоторые новости с помощью webservice. Вот psuedo для этого.Оптимизация AsyncTask относительно внутреннего списка

У меня есть операция, которую я выполняю в asynctask. Он загружает некоторые новости из веб-службы.

AsyncTask 
{ 

AsyncTask(Context context){} 

doInBackground() 
{ 
// download some news 
.. 
.. 
return List<News> 
} 

onpostExecute(List <News>) 
{ 
is the activity around ? if yes then 
    //find the list using context ,and populate it with news 
} 

}

Вопрос в том, что в середине операции, если устройство ориентировано, у нас будет новая AsyncTask. Теперь у старого уже есть внутренний список.

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

Кроме того, в слабых ссылках я могу знать внутри onPostExecute, что активность, которая породила эту Async, уже не вокруг. Но . Я все еще верю, что упускаю много.

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

источник

2013-11-11 Muhammad Ahmed AbuTalib

У вас есть новый AsyncTask, потому что активность воссоздана, и вы, вероятно, создаете задачу в onCreate | onStart | onResume.

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

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

Вы можете попробовать использовать «приложение» контекст вместо «деятельности» контексте, как это рекомендовано в этом блоге: http://android-developers.blogspot.com.es/2009/01/avoiding-memory-leaks.html

Другой вариант, как вы сказали, есть WeakReference в контексте ,

Но помимо этого важно, могут ли эти две задачи безопасно работать одновременно. Также выполнение задачи до ее завершения, когда вы знаете, что результат не будет потреблен видимой деятельностью, является пустой тратой ресурсов. Я отменил бы текущую задачу, когда действие закрывается (onStop | onPause | onDestroy), но это тоже сложно (вам нужно реализовать его с целью его отмены как можно скорее, поток прерывается. Дополнительная информация здесь: Android - Cancel AsyncTask Forcefully) ,

Самый надежный способ - использовать Сервис вместо AsyncTask.

источник

2013-11-11 10:54:43

спасибо за ответ. Однако, как вы видите, мой вопрос больше связан с поведением сборщика мусора.Я имею в виду, что у меня нет какой-либо проблемы в настоящее время, однако я СИЛЬНО вижу, что у меня может быть один в будущем, как я подразумеваю в своем вопросе. –

Я думаю, что более дорогим объектом в плане памяти является контекст активности. Список, вы бы объявили его в классе asynctask, поэтому он будет собран также, если задача будет собрана. –

Существует возможность потока Is AsyncTask really conceptually flawed or am I just missing something?

Вкратце, активность является контроллером из MVC (Model-View-Controller) точки зрения, и Ваши данные относятся к модели. Поэтому просто не вызывайте такие AsyncTasks непосредственно из Activity. более

Один записывания: AsyncTask промахов http://www.shanekirk.com/2012/04/asynctask-missteps/

источник

2013-11-11 11:05:52 18446744073709551615

Оптимизация AsyncTask относительно внутреннего списка

ответ

Смежные вопросы