Jetpack Compose: вложенный LazyColumn/LazyRow ⇐ Android

[Anonymous]

Я читал похожие темы, но не нашел удовлетворительного результата:

• Что является эквивалентом NestedScrollView + RecyclerView или Nested RecyclerView (Recycler внутри другого переработчика) в Jetpack Compose
• Jetpack Compose: Как поместить LazyVerticalGrid внутри прокручиваемого столбца?
• При использовании lazyColum внутри столбца возникает ошибка в Jetpack Compose
• Вложенная LazyVerticalGrid с Jetpack Compose

Мой вариант использования: для создания списка комментариев (сотни элементов) с возможностью отображения ответов на каждый комментарий (сотни элементов для каждого элемента).
В настоящее время невозможно создать вложенный LazyColumn внутри другого LazyColumn, поскольку Compose выдаст исключение:

java.lang.IllegalStateException: компонент с вертикальной прокруткой был
измеряется с ограничением максимальной высоты,
бесконечным, что
недопустимо. Одной из распространенных причин является вложенность макетов, таких как
LazyColumn и Column(Modifier.verticalScroll()). Если вы хотите добавить заголовок
перед списком элементов, добавьте заголовок как отдельный
item() перед основным элементом() внутри области LazyColumn. Для этого
могут быть и другие причины: ваш ComposeView был добавлен
в LinearLayout с некоторым весом, вы применили
Modifier.wrapContentSize(unbounded = true) или написали собственный макет.
Пожалуйста, попробуйте удалить источник бесконечных ограничений в
иерархии над контейнером прокрутки.

Решения, предоставленные по ссылкам выше (и другие, которые пришли мне на ум):

• Использование фиксированной высоты для внутреннего LazyColumn – я не могу использовать его, поскольку каждый элемент может иметь разные высоты (например: однострочный или многострочный комментарий).
• Использование обычных столбцов (не ленивых) внутри LazyColumn – с точки зрения производительности он уступает ленивым, при использовании профилировщика Android Studio и списка из 500 элементов обычный столбец будет использовать 350 МБ ОЗУ в моем приложении по сравнению с 220–240 МБ при использовании ленивых компоновок. Поэтому он не будет перерабатываться должным образом.
• Использование FlowColumn от Accompanist — я не вижу никакой разницы в производительности между этим и обычным Column, поэтому см. выше.< /li>
  Сгладить источник данных списка (показывать как комментарии, так и ответы как «основные» комментарии и вносить изменения в пользовательский интерфейс только для того, чтобы различать их) — это то, что я сейчас использовал, но когда добавлял больше сложность этой функции препятствует реализации некоторых новых запросов функций.
• Отключите внутреннюю прокрутку LazyColumn, используя недавно добавленный в Compose 1.2.0 параметр userScrollEnabled - к сожалению, выдает ту же ошибку, и это запланированное поведение (см. здесь).
• Использование других способов блокировки прокрутки (также для ее программной блокировки) – та же ошибка.
• Использование других параметров .height() LazyColumn, таких как WrapContentHeight() или использование IntrinsicSize.Min — та же ошибка.

Есть еще идеи, как решить эту проблему?

Подробнее здесь: https://stackoverflow.com/questions/722 ... mn-lazyrow