1

I noticed that Compose on Android actually implemented by AndroidComposeView, When compose state changes and composable function starts recomposing, AndroidComposeView.invalidate() will be called from the layout node layer (At least for now in master branch of androidx repository).

// For example: RenderNodeLayout

internal class RenderNodeLayer(
    val ownerView: AndroidComposeView,
    ...
) : OwnedLayer {

    ...

    override fun invalidate() {
        if (!isDirty && !isDestroyed) {
            ownerView.invalidate()
            isDirty = true
        }
    }

    ...

}

This will invalidate the whole view. If Compose designs a larger UI, such as the entire activity via function setContent(), even a small change to the UI will invalidate the entire content of activity. Android seems to redraw only the parts of the interface that have been changed when hardware acceleration is enabled, does it mean that Compose loses more performance? If so, how expensive the impact will be?

M.D.
  • 13
  • 4

1 Answers1

0

Recomposition in Compose plays an important role. When portions of your UI are invalid, Compose does its best to recompose just the portions that need to be updated. This means it may skip to re-run a single Button's composable without executing any of the composables above or below it in the UI tree.

Furthermore, Compose can optimize recomposition by running composable functions in parallel. This lets Compose take advantage of multiple cores, and run composable functions not on the screen at a lower priority.

kaustubhpatange
  • 442
  • 5
  • 13
  • Recomposition only partially updates the view tree, but after the update it still invalidates the view which the composable function attached in the framework view level, the whole `AndroidComposeView` is completely refreshed. – M.D. Jun 05 '21 at 14:27