S
просто что более сложная логика выполняет объединение логик и по сути отвечает принципу единой ответственности, это вот если в кратце.
Size: a a a
2021 April 01
Ф
для других случаев можно использовать слабые ссылки WeekReference
Про weekReference не слышал, посмотрю
S
S
Если Dagger используется или Koin, или своя реализация или еще что, то там как правило используется ApplicationContext который и так живет все жизнь, жизни приложения. до полного его убийства. Даже в кэше сохраняется. пока не будет убит.
S
И по этому его часто передают в такие архитектурные компоненты, по тому что, в этом не чего страшного нет и более правильно чем вызывать Application::class (который мы указали в манифесте и сохранили в ссылку при onCreate).instance. особенно в класс которые генерятся через Dagger, Koin и тд тп.
S
Тем более страшен же не сам контекст а любая ссылка, которая может указывать на тяжелый объект, к примеру Fragment у него был какой то listener который был установлен как слушатель в синглтоне и отписка не произошла,
указывали как listener но на самом деле там храниться Fragment со свойствами listener.
указывали как listener но на самом деле там храниться Fragment со свойствами listener.
Ф
И по этому его часто передают в такие архитектурные компоненты, по тому что, в этом не чего страшного нет и более правильно чем вызывать Application::class (который мы указали в манифесте и сохранили в ссылку при onCreate).instance. особенно в класс которые генерятся через Dagger, Koin и тд тп.
Да, это понятно
S
Но если используйте LiveData, Observable и другие + Двух стороний биндин, то там принцип проектировки прилаги, немного другой, что делает более безопасной для утечки памяти.
А утечка может быть разные
К примеру работали с Bitmap их надо уничтожать руками или помещать в специальный кэш окторый затрет.
А утечка может быть разные
К примеру работали с Bitmap их надо уничтожать руками или помещать в специальный кэш окторый затрет.
S
Другие объекты которые юзают C/C++ К примеру, атм часто пишут в доке, вызвать обязательно Destroy и тд тп.
Ф
Ну С++ вообще кошмар в плане утечек
S
Ну вообще там просто все удаляется руками))
S
Больше возможностей, больше ответственность
СП
Но если используйте LiveData, Observable и другие + Двух стороний биндин, то там принцип проектировки прилаги, немного другой, что делает более безопасной для утечки памяти.
А утечка может быть разные
К примеру работали с Bitmap их надо уничтожать руками или помещать в специальный кэш окторый затрет.
А утечка может быть разные
К примеру работали с Bitmap их надо уничтожать руками или помещать в специальный кэш окторый затрет.
Зачем? Если картинка не нужна сборщик ее сам прибьет.
Ну то есть тот метод где она объявлена закрылся. Или объект полем которого она является - сам уничтожен.
Ну то есть тот метод где она объявлена закрылся. Или объект полем которого она является - сам уничтожен.
СП
А уничтожать руками это bitmap= null?
СП
Крайне редко видел такой код
S
bitmap.recycler
G
Виды ссылок Java. Кому надо, забираем.
СП
bitmap.recycler
А, это. Это полезно
S
Зачем? Если картинка не нужна сборщик ее сам прибьет.
Ну то есть тот метод где она объявлена закрылся. Или объект полем которого она является - сам уничтожен.
Ну то есть тот метод где она объявлена закрылся. Или объект полем которого она является - сам уничтожен.
это я что бы избавиться от стандартных реализаций слушателей. Когда могли подписывали и забывали отписываться.