касательно оптимизации.
Использую getItemLayout.
Список состоит из публикаций с медиа
Первое время дикие задержки перед срабатыванием событий клика + часто пустые пространства надолго зависают.
Все это в release mode, apk тоже.
Я так понял, FlatList не предназначен для больших списков с немалыми высотами у элементов(и это мягко еще сказано)...
js поток может быть занят чем то другим + нужно мемоизировать ячейки обязательно и все пропы листа андроид на РН в целом медленнее - джависты как всегда рукожопы
Попробуй flashlist
FlatList имеет один целевой кейс - бесконечная лента постов с не очень быстрым скроллом. Как раз с крупными (в меру) элементами. Посмотрите в инспекторе сколько он реально элементов рендерит у вас за пределами окна вывода; отпрофилируйте js (грубо говоря, не нагружают ли скрытые компоненты JS поток)...
Мне нужен initialScrollIndex
есть логика фетчинга внутри элемента списка. Очень много вызовов вижу через Redux profiler. Такова структура на беке, что приходится подгружать медиа по его айдишнику
Плохо... Лучше сделать так, чтоб любой элемент списка был максимально тупым и не ререндерился на любой чих, потому что сам виртуализованный список по своей сути айтемы постоянно перерендеривает (поддерживает подмножество в окне видимости), поэтому они там постоянно передергиваются, новые добавляются, старые удаляются (поэтому у них ещё внутреннего стейта не должно быть, привязанного к времени жизни айтема - сбрасываться будет). Итого, если хочется чтоб это быстро работало: 1. элементы должны ререндериться только если это реально необходимо 2. быть максимально тупыми (стейт где-то вовне должен лежать)
а что насчет recyclerlistview ?
Что он, что FlashList будут работать только с "оптимизированными" айтемами. FlatList пытается скрыть лаги делая большое "окно видимости", а эти наоборот уменьшают окно видимости пытаясь сберечь суммарно циклы процессора... Поэтому если айтемы не оптимальны, то с ними наоборот будут виднее пустые места, когда рендер не успевает за скроллом
Обсуждают сегодня