Господа, у всех lazycolumn адово лагает? Сделал lazycolumn, внутри которого: Row - Column --

Text
-- Text
-- Text
- Column
-- Text
-- Text
-- Text
- Column
-- Text
-- Text
-- Text
- Column
-- Text
-- Text
-- Text

Лагает скроллинг так, что использовать программу невозможно. Типа 5-10 фпс +-. И это при том, что данные уже подготовленные вставляются в Text, не нагружают mainthread.
Какой есть выход из ситуации? До композа использовал drawText на canvas, так там намека на лаги не было. А в композе drawText нету, зависить чисто от Android'овского канваса не хочу.

А вы в релизной сборке смотрите?

И в дебаг, и в релизной. В релизной чуть получше, но где-то уровня iPhone 3G без рисования на канвасе. Помню те времена...

А много текста?

12 вызовов Text в одной строке. 14 строк вмещается на экране

Сравнение реализации на композе и на канвасе Android. Слабонервным первое видео не смотреть

Сравнение реализации на композе и на канвасе Android. Слабонервным первое видео не смотреть

жёстко, пока что посижу на xml ещё

Большое спасибо за сигнал. На этом отдельном отрицательном примере мы мобилизуем общественность, поднимем массы... 😀

каво?)

А это дебаг сборка или релиз?

Оба видео дебаг сборка. Релиз сборка даёт на несколько кадров больше, но лучше ситуация не становится

А с какой биржи апи берете?

Мне все-таки кажется что тут вся проблема в постоянной рекомпозиции.

Там разные. Бинанс, Битмекс, московская, Санкт-Петербургская биржи (российские через Quik)

Серый плейсхолдер из скелетной части, который заменяется на плейсхолдер с камерой, который потом заменяется на фотку, весь immersion ломает 😜

Мм )) надо подумать )))

Кстати, а как со вложенными нав хостами я буду переходить по внешнему хосту? Буду внутрь прокидывать 2 нав контролера: внутренний и внешний?

Ага

Продолжение вчерашней темы. Сегодня сделал дополнительный вариант для тестирования - Compose + Canvas. Итого в тесте принимают участие: - Android View + Canvas (целый view на канвесе) - Compose + Canvas (построчно). - Compose + Text (построчно). @andkulikov, если есть время, не мог бы ты поучаствовать в дискуссии? Или хотя бы после НГ. Прикрепляю записи экрана (много весят, если что). ComposeCanvas уже почти близок к ViewCanvas, но только если данные не обновляются. А вот если обновляются, то лаги сильные. Нужно минимум 3 раза в секунду данные обновлять. Собственно, вопрос в том, как сделать ComposeText (в идеале) или хотя бы ComposeCanvas таким же производительным, как ViewCanvas при обновлении данных 3 раза у секунду? P.S. это с android:debuggable=false, т.е. как релизная сборка

самое эффективное это завести баг и приложить код. но сразу скажу что рисование текста на канвасе всегда будет быстрее. для корректного сравнения попробуйте сделать то же самое на вьюхах, где каждый текст это отдельный TextView. поучаствовать в дискуссии готов после 9го. у меня отпуск)

Окей, принял) желаю весело провести новогодние праздники)

Мне любопытно, а зачем в этом конкретном случае canvas вообще? Там же просто разноцветный текст везде. Или я что-то не так понял?

А какая альтернатива есть, кроме канваса и Text'a?

Так просто Text, он же не тормозит? Или тут именно тест на производительность?

Так третье видео ComposeText как раз с помощью 12 функций Text в каждой строке. Очень плохая производительность. Канвас без композа показывает в разы лучше FPS

А всё, понял. Извиняюсь.

Там же LazyRow?

Да

Можно попробовать https://developer.android.com/jetpack/compose/lists#item-keys

Я ключи делаю, да. Но это вряд ли про производительность, скорее помогает при смене сортировки, что мне очень кстати

Не уверен как работают кишки, но в теории это сможет позволят избегать рекомпозиции неизменённых элементов.

Это в теории, а на практике ключом в моём случае является уникальная строка из объекта, а изменился объект или нет, композ не знает. Да и это мало поможет, т.к. часто бывает, что все видимые объекты реально изменяются

Моё понимание такое, что композ сможет понять, какие из изменённых объектов сейчас видимы, и обновит только их. Например если изменилась 1000 объектов, а видно только 10 где-то посередине.

Логи показывают, что видимые строки рекомпозируются независимо от изменения или не изменения объекта. Тупо выводил логи в lazyColumn и наблюдал, какие индексы перерисовываются. Тут проблема не в том, что рекомпозируются, а в том, что долго. И не совсем понятно, почему так. Ведь даже на канвасе из композа не получается достичь скорости View + Cancas. Что как бы неприятно, учитывая, сколько дней я посвятил переписыванию всей той страницы на композ) придётся теперь брать прежний вариант, пока не найду решение. И ещё в новой версии композа поломали связку webview и pager (не скроллится ни вниз, ни вверх), теперь вынужден сидеть на старой версии + на котлине 1.5. Такие дела.

Я смог воспроизвести лаги с максимально простым LazyColumn { Row { Text Text Text Text } } и списком на 1000 элементов. Профайлер показывал, что тормозит именно рекомпозиция в композ. А точнее некий метод groupObjects, если я ничего не путаю. PS: рекомпозиция не рано перерисовка.

А количество элементов влияет? Потому как у мены с разным количеством так получается одинаково

Не пробовал, если честно

А киньте этот пример на гит где вы воспроизвели . Интересно посмотреть

Есть подозрение, что что-то не так готовишь. Разумеется, если 3 раза в секунду рекомпозируется (и перерисовывается) каждый элемент на экране — это тяжёлая операция. Я не предлагаю решение и, возможно, всё сделано как надо, а это просто какой-то баг\неоптимизированный кусок. Но, рекомпозировать (и перерисовывать) нужно только те элементы, у которых что-то поменялось.

As we discussed, recomposing the entire UI tree can be computationally expensive, which uses computing power and battery life. Compose solves this problem with this intelligent recomposition. https://developer.android.com/jetpack/compose/mental-model#recomposition

Прочитал статью полностью. Нет там ничего, что бы говорило о неправильном подходе. У функций моих нет sideeffect'ов. Есть тупо val data by remember { someMutableStateWithHashMap }. После идёт HorizontalPager, в котором LazyColumn с items(data[page]). Ещё указываю ключ в items и дальше идёт Row с тремя Column и 12 Text. Каждый Text просто отображает одно значение из предоставленного объекта. Все. Т.е. никаких тяжелых операций, внешних изменений и т.д. Профайлинг показывает, что mainthread используется исключительно композом (однако это не означает, что я правильно его "готовлю"). Мне кажется, если вы просто создадите LazyColumn с 12 Text и будете её обновлять 3 раза в секунду, сложно будет не увидеть просадок в FPS. А ведь ещё использую Column с weight'ами, дабы пространство поделить на 4 столбика с разным коэффициентом. Причём у меня Text имеет фиксированную ширину, дабы даже тут уменьшить напряг для композа

Это ведь не я сказал, что видимые строки рекомпозируются независимо от того, изменился стейт или нет. А это неправильно. Рекомпозировать нужно только то, что действительно изменилось. Всё ещё говорю это не в тему решения, а просто чтобы сказать об этом.