Смотри в сторону ассинхронной загрузки/выгрузки. + сгладь углы анимацией загрузки.

Парни, нужен совет. Пробую оценить задачу с точки зрения производительности.
Задача такая -
1) андроид-приложение, экран который отображает одну фотографию на весь экран.
2) есть пул фотографий на диске устройства. Например, 60 фотографий.
3) По скроллингу влево-вправо фотографии меняются.
4) Прямо сейчас реализовано следующим образом - готовлю кэш из битмапов и при скролле ставлю в imageView фотографию по позиции. Работает нормально, но требуется большой кэш, так как каждая фотка в битмапе это разрешение экрана * 4 байта rgba и получается фотка даже из webp весом в 500 кб разворачивается в битмап 7 Мб весом. 60 фоток соответсвенно 420 Мб что для оперативной памяти очень много. На слабых девайсах тупит, конечно же.

Вопрос - есть ли смысл попробовать перенести эту работу на GLES ? Если да, то как именно это мне надо организовать?
Познания на уровне "натягивал текстуру на треугольник", но терпение, труд и чатик всё перетрут )

Пример пула фотографий со скроллингом можно посмотреть здесь https://fyu.se/v/go9m2oe1r6

сколько времени занимает декодирование одного такого кадра?

Я уже не помню цифр )) это не имеет значения.
Бизнес-задачу я решил путём мультитрейдинга и огромного расхода памяти. Тут всё окей.
Теперь я размышляю над путями оптимизации.

я к тому, что нафига тебе всё распаковывать и в памяти держать, если оно за условные 100 мс распаковывается?

я к тому, что нафига тебе всё распаковывать и в памяти держать, если оно за условные 100 мс распаковывается?

потому что долбанные qa делают monkey-тесты и пиздят что телефончик не успевает за ихними скроллами 🙈

потому что долбанные qa делают monkey-тесты и пиздят что телефончик не успевает за ихними скроллами 🙈

тут самое дорогое это чтение с диска

Их. Мы хоть и ПТУшники, но не на столько колхоз

ограничь скорость скролла

7 мб можно и в памяти подержать