Вообще странно как-то всё.... особенно в андродие... @Harmonizr Вот смотри

пример из жини: ща сел - раскинул и в тупик зашёл.

Задача - отражать список элементов и рефрешить его.

1. Самый прямой путь - маппим каждый айтем массива во View компонент, список детей добавляем в скроллируемый парент - и всё. а.... предварительно clean всех старых детей, если таковые были.

2. Когда-то давно телефоны были маленькими и слабыми - гугл решил, что иметь столько view сколько и айтемов - расточительное удовольствие, учитывая что всегда видна только часть. И тогда как раз (когда еще не было даже UIL) ImageView - сами открывали битмап по урлу в майн потоке. Ок - таким образом каждая ImageView моглать иметь еще и битмапы - и потому было решено завести листы и адаптеры для переюзания вьюх.
Отсюда получается - нет смысла иметь 100 UserItemViews и даже 100 UserItemData, достаточно ... (мы ж экономим память) иметь ид-шники only.

3. Если мы в храним только массив ссылок - то нам надо по мере биндинга грузить контент по этим ссылкам в айтемы..... и как бы ты ни старался - нельзя никак придумать мапить синхроннно в майн потоке прям в бинде. Просто тупо потому что все листывью и ресайклеры - пришли из тезиса (n-легковесных url's и id's - биндятся в k-тяжеловесных вьюх, которые попали на вью порт - экономия памяти)
Но нельзя превратить легковесное в тяжеловесное в майн потоке без лага, поэтому мы обречены на async-loading во вью-коллекциях в андроиде.

4. Поскольку юзер листая, может возвращаться мы вынуждены кэшировать уже асинхронно загруженое и кэнсилить загрузки, покидающие вью порт и мн др.
То есть - огромную задачу по разгребанию этого дерьма - взяли на себя имэдж лоадеры - за что им и огромное спасибо. Но ведь битмап - это частный случай тяжёлой начинки View, может быть что угодно, ... тонна текста н-р не знаю, что угодно.
Благо глайд догадались добавить модули кастомизации типов-данных (но это жесть).

5. Тут приходит еще одна мысль, глайд - не рактивная либа, и если изменился сингл айтем или урл картинки - ничего не обновится, пока не рефрешнут будет весь список. И вот тут тупик

6. В ресайклере гугл в довесок к частичным изменениям сделал payloads и diff utils, но, касаемо particular changes for item - тема сомнительная, потому как и реактив это не подцепить, и толку то особо не больше чкм тупо ребинднуть весь вью. И более того - глайд с асинхр поставкой битмапа во вью - не парится не доставляет окольными огорадами и не фэйдит айтем аниматорами.

И весь этот бред рождает больше вопросов чем ответов:
Зачем мне переиспользование ? чтобы экономить на голых вью в памяти?
но при этом держать 100 POJO's и еще 100 битмапов в кэше? Ну допустим )
Реактивность обновления по айтемно так и не решается никак
....так же как и глайд неперезагрузит картинку сам.

Итого мы имеем - все делают ресайклер - pojo-модели содержат весь контент, кроме картинок (они грузятся по урлам глайдом) .
Обновления - только add/remove/move - change - никто так и не делает(diffs и анимирование))
В итоге - экономия памати уже особо не решается, нормальный реактив биндинг по-айтемный тоже не решается.
Единственное, что решается - отображение стабильного плавного немутабельного списка элементов 😁👍 СЛАВА БОГУ - В 2018-м!!!

...и жалкая горстка экспериментов на медиуме с Observable<List<Observable<T и проч

Без переиспользования можно показать пару сот айтемов, но прокрутка вперёд будет неиллюзорно тормозить. Инфлейт, обмазанный рефлексией, файнд, байнд — потерянные кадры. Обзёрваблы... В JavaFX есть ObservableList. Я часто заимствую идеи оттуда, но решаю эту проблему немного по-другому. Не знаю, зачем рефрешить весь список, когда загрузилась картинка. Можно просто эту картинку всунуть, адаптеру можно не знать об этом.