1

I want to preface this by saying I'm not a Kotlin developer or Android developer, so my experience is extremely limited, but I wanted to delve into some Android + Kotlin development and this was one of my issues and question that I have been wondering about for a week now.

LazyColumn according to the docs, is said to only compose the visible items (Composable's). If these composables do any kind of heavy lifting, when scrolling an item out of view and into view again, it seems to me that LazyColumn is defeating the entire purpose of the Compose framework?

If the framework builds up state, like for instance, manages life cycles of Composable's then if those composables do any remember { someStateOrComputation() } it means that the LazyColum invalidates this every time - no?

Is it possible to tell LazyColumn not to throw away the object (and all it's state, life time management etc) when a previously displayed Composeable goes out of view (and thus, re-use it, when it comes back into view?)

Emitting a simple text bubble and rendering some pretty trivial stuff, amounts to ~3 ms per text bubble using LazyColumn this is outrageously bad performance, but it's fine if it happens once and then if the framework recomposes for us.

I tried replacing the LazyColumn with a normal column and indeed - the items that get scrolled out of view, do not get reconstructed (thus, they do not invalidate ALL the state of the composable's) when scrolled back into view.

Does LazyColumn break the entire idea behind Jetpack Compose or is there someway to tell LazyColumn to behave like Column but with the added bonus of not actually creating the lifetime management until it's seen the first time?

Simon Farre
  • 71
  • 1
  • 6

1 Answers1

2

From what I dig into the official docs there are some things to note, first the definition for LazyColumn

The vertically scrolling list that only composes and lays out the currently visible items.

Lays out currently visible items is telling that the composition tree only renders the composables in the view.

As the official doc on compose lifecycles here

https://developer.android.com/jetpack/compose/lifecycle

You can check this part https://developer.android.com/jetpack/compose/lifecycle#add-info-smart-recomposition

Says that every time you scroll a new composable is created and remembered for the list position since it's not meant to change in future re-compositions, this tells you that first time you scroll the list of items it will create a new instance of each composable (that's why sometimes it could get a little slower to scroll) and then it will save those instances to recompose them and do not recreate them again (that's why after you finish scrolling it might be faster to scroll the list)

For this, the conclusion that I have is that each time an item goes away from the view, its instance + state will be saved in memory, lets say that the state that the composable has been created in the list when you scroll away will be saved with also the composable instance. Then, when it comes back to the view (you scroll back to it) the position of where this composable left is now returned to the view and binds the composable with its saved state.

This, I think, is the same as creating a for loop with a Column and store the state with a remember variable for each composable in the tree, since the column will not by itself save its state, you will need to create it for each composable.

LazyColumn does this for you so you don't need to worry of state of each composable created.

This info is what I found out in the official doc and how I'm putting it for what I read, please reach to the links provided above to learn more.

halfer
  • 19,824
  • 17
  • 99
  • 186
Gastón Saillén
  • 12,319
  • 5
  • 67
  • 77
  • What you say were my conclusions at first as well. But the actual behavior I am witnessing is, when an item gets scrolled *out* of view, it's entire subtree, the life time management, `remember { }` blocks, all of it, gets discarded - and the next time its scrolled back in, the setup(life time management etc), the creating of the subtree, the `remember { }` blocks all run _again_. – Simon Farre Mar 29 '23 at 19:11
  • thats correct, because as you can see in the docs provided above (the lifecycle one) the composables get removed from the tree but some state is saved to remember where they were placed on screen, when this position gets triggered again the instance and all its state is throw back to the composer and the view is recomposed with these items. This is to prevent "invisible" items live in the tree, because, since you are not seeing them, why keep them in memory if not needed, you can recreate these compose objects later – Gastón Saillén Mar 29 '23 at 20:06
  • Yes, but there is so much involved in recreating the context for a composable. Life time management needs setting up (and tear-down), most likely re-running UI-logic code, like parsing some arbitrary data to produce an effect, etc. Keeping this in memory comes at little to no cost, it's just reading from memory, - while re-creating the Composable from scratch every time is higly costly. Which to the keen eye is clearly noticeable. The memory footprint is negligible in comparison which is why I was wondering if there was a hybrid, which would improve the performance N-fold. – Simon Farre Mar 29 '23 at 22:48
  • I think this could be better answered from someone involved inside the compose compiler and runtime, try to reach Leland Richardson – Gastón Saillén Mar 30 '23 at 19:55