Борьба с утечками памяти в Android. Часть 1

[mIK_LH]

del

[HotIceCream]

По этой теме помню был доклад на Yac. tech.yandex.ru/events/yac/2012/talks/398/
За WeakHandler спасибо.

[Norraxx]

Про OQL наверное мало кто знает.
Всегда приятно читать эдакие поиски истины.
Но ещё приятнее их находить. Это называется опыт.
Делитесь с нами своим опытом ещё!

[DmitryO]

Интересно, но я так и не понял, чем же плох вариант removeCallbacksAndMessages(null)?

[mutable]

Вариант с removeCallbacksAndMessages(null) очень даже хорош. Но программируя на языке со сборщиком мусора хотелось бы меньше уделять внимания таким мелочам как освобождение памяти.
Дело в предпочтениях.

[anton9088]

Еще одна причина ваших утечек памяти — onDestroy. Вызов этого метода не гарантируется и там не стоит освобождать критические ресурсы и отсоединять листенеры. Последний гарантированный метод, который вызовется при уничтожении activity это onPause.

[mutable]

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

Если вы знаете о других случаях, когда onDestroy не вызывается, пожалуйста сообщите.

[ookami_kb]

Удалено, фигню сказал, не подумав.

[anton9088]

Из документации:
When your activity receives a call to the onStop() method, it's no longer visible and should release almost all resources that aren't needed while the user is not using it. Once your activity is stopped, the system might destroy the instance if it needs to recover system memory. In extreme cases, the system might simply kill your app process without calling the activity's final onDestroy() callback, so it's important you use onStop() to release resources that might leak memory.

Не всегда уничтожается процесс при нехватке памяти, могут просто освобождаться activity

[ookami_kb]

Только и postDelayed() надо запускать в onStart(), потому что onCreate() после onStop() может и не вызваться.

[Artyomcool]

In extreme cases, the system might simply kill your app process without calling the activity's final onDestroy() callback

Другого пути «освободить activity» без вызова onDestroy, насколько мне всегда казалось, не существует.

[ookami_kb]

И всё-таки ресурсы настоятельно рекомендуют освобождать именно в onStop(). Вообще, этому следовало бы уделить больше внимания в документации, расписать подробнее, а то как-то по крупицам собирать приходится.

[Artyomcool]

Ресурсы действительно лучше освобождать как можно раньше. Если был вызван onStop, значит Activity не видна на экране, и незачем занимать память/диск/сеть.

[vlivyur]

А может кто-нить об'яснить зачем при перевороте каждый раз создаётся новая Activity?

[anisart]

Если я не ошибаюсь, то для того, чтобы можно было другой layout подсунуть для landscape ориентации. В добавок к этому можно ещё как-нибудь обработать смену ориентации. Также можно запретить вызов onCreate для активити при различных сменах конфигурации в манифесте.

[vlivyur]

Ну так и дали б событие на смену ориентации, а там уж реализуй как хочешь: подсовывай другой layout, создавая новый или используя имеющийся (например, с предыдущего переворота) или вообще ничего не делай;
А то непонятны эти свистопляски с постоянным созданием нового, будто перезапустил приложение, но с другим разрешением экрана;

[ookami_kb]

Так пропишите в манифесте android:configChanges=«orientation|screenSize» и ловите onConfigurationChanged()

Но в большинстве случаев полный рестарт активити удобнее, имхо.