Comments 21
Я не джавист, но мне кажется не очень разумным полагаться на поведение сборщика мусора в вещах, которые относятся к бизнес-логике. Предположим, завтра к Вам придет аналитик и скажет: давайте мы будем держать эту вьюмодель в памяти, но только пока пользователь находится в этом разделе приложения (на соседних экранах), а как только переходит в другой раздел (скажем, корзина) - можем прерывать запросы, если они еще идут, и освобождать память для более нужных вещей. И наоборот: пока пользователь находится в этом разделе, пусть и на других страницах - держать вьюмодель в памяти, независимо от приходи GC.
Имхо для подобных вещей имеет смысл создавать отдельную сущность, которая будет управлять подобными вещами, пусть даже в первоначальной реализации там действительно используются слабые ссылки.
Я джавист обычный, под андроид не пишу. Но там вроде уже есть Koin, Kodein, Dagger. На бэкенде есть Spring и Guice. Тут и компайлтайм и райнтайм решения. Что инновационного вы предлагаете?
Идея библиотеки проста - прежде всего это избавить разработчика от необходимости определять скопы DI, заставлять джависта решать проблемы памяти, будто он использует не джаву, а плюсы.
Сборщик мусора никогда не уничтожит обьект, если вы его хоть в одном месте явно используете. А значит скоупы жизни компонентов (и ЖЦ) определяются именно тем как они используются в конкретных кейсах и экранах.
Более того не нужно создавать сложные скоупы для компонентов приложения, которые должны доступны с нескольких экранов, но не должны существовать весь ЖЦ приложения
А много ли памяти занимают кэшированные данные ? Так-то томик Войны и Мира - это всего порядка мегабайта.
Теперь я знаю кто всю эту муть про gc и ссылки спрашивает...
Есть такая штука как spring web flow для веб приложений для таких случаев, где в сессии хранятся данные для нескольких страниц. В крайнем случае можно сделать что-то похожее для андроида через кастомный скоуп в spring и хранить данные в памяти/сессии когда это нужно. Ту же сессию можно сохранять в базу, ну либо саму модель данных в базу пихать. Хотя конечно довольно странно получать проблемы с памятью в современном мире.
SoftReference позволяет использовать объект вплоть до конца, но не умирать за него. Если у jvm будет стоять вопрос памяти ребром, то ты как самый ответственный программист легко откажешься от любого нужного компонента, дабы не встретиться с "Out of Memory".
В Android SDK написано несколько другое:
Avoid Soft References for Caching
In practice, soft references are inefficient for caching. The runtime doesn't have enough information on which references to clear and which to keep. Most fatally, it doesn't know what to do when given the choice between clearing a soft reference and growing the heap.
Из личного опыта: в доисторические времена (году ~в 2015) пробовал в одном, тогда довольно известном, Android проекте делать свой кэш картинок на SoftReference-ах; оказалось, SDK не врёт и живут эти ссылки совсем не так долго, как хотелось бы - так что пришлось от них отказаться, хотя идея выглядела красивой. Но может быть, к 2023 сборщик мусора стал умнее?...
Спасибо за уточнение. В действительности мог допустить в этом плане некую неточность. Однако могу добавить, что JVM проводит сборку мусора над несколькими группами сегментов в памяти подробнее здесь к примеру .
И получается (в теории) при долгом использовании обьектов этот самый обьект будет удаляться дольше
del
А почему не lru cache? Он же тоже доисторический. Вполне можно настроить на работу же.
LruCache это больше про картинки, статья же про DI
Так а какая разница что в нем хранить, он же не к bitmap привязан то. Понятно что в основном его не для этого используют, но технически кешировать им можно хоть классы, хоть что. Размер только переопределить при запросе.
LruCache как и другие кэши inMemory с пулом основаны на идее, что обьект, который хранится в памяти не изменяется и его дубликат хранится где то еще (на диске, на сервере). При заполнении этого пула кэша до ограничения, кэш начинает выкидывать эти объекты по различным алгоритмам. Также эти обновления могут быть по триггерам (повторным загрузкам картинки с сервера)
В DI нет возможности все обьекты хранить на жестком диске, как минимум потому, что почти все обьекты, что он предоставляет недесериализуемые обьекты (не дата классы котлин).
Справедливо. Спасибо за ответы!
Касательно DI - lru cache удалить обьект может по любым свои алгоритмам, не вдаваясь в подробности ЖЦ этого самого объекта.
По итогу мы можем получить для обьект будет пересоздан там где не надо.
Все эти кэши могут работать хорошо с однотипными обьектами, но если кэшируются различные обьекты ViewModel, Presenter, Repository, то этому самому кэшу нужно будет знать - когда можно удалять этот самый обьект, а когда нет.
Конечно идею осуществить можно, но к сожалению ее развитие зависит только от вас)
Потому, что хотел сделать кэш, зависящий от доступной приложению памяти, который JVM бы автоматически чистила, когда памяти становится мало - lru cache так не умеет.
Такое себе на JVM полагаться, а вдруг кто из вендоров нахимичит что-то? Они могут...
Вопрос довольно открытый. Однако насколько я понимаю dalvik является частью AOSP, которая в свою очередь является открытой и обязывает ее модификации тоже делать открытыми. Для вендоров предоставляются точки интеграции (один, два и др.), которые ограничены и не позволяют ломать AOSP основы.
В тоже время существует разница в некоторых кейсах использования kotlin или java, при написании вашей программы (К примеру находил минорный кейс для Котлина). Это больше обусловлено конкретным компилятором языка, так что такое может быть встречено даже при использовании различных jdk в проекте.
Все эти кейсы уникальны и думаю на общую картину не влияют.
Такое себе на JVM полагаться
Так я цитату из SDK выше и привёл именно потому что идея, когда-то мне казавшаяся красивой, оказалась "такое себе" :)
Ракету пустил и забыл. Или как заставить DI работать