Fixed
Status Update
Comments
ap...@google.com <ap...@google.com> #2
Thanks for reporting.
Unfortunately I can't reproduce it. What I tried:
class DemoActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
Scaffold {
LazyColumnFor(
items = (0..200).toList()
) {
Text(
text = "$it",
modifier = Modifier.clickable(indication = null,
onClick = {
Log.e("test", "test")
})
)
}
}
}
}
}
And this code has pretty much the same performance if I remove the clickable modifier.
Is there a chance you can share with me more complete repro project so I can debug it?
Unfortunately I can't reproduce it. What I tried:
class DemoActivity : ComponentActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContent {
Scaffold {
LazyColumnFor(
items = (0..200).toList()
) {
Text(
text = "$it",
modifier = Modifier.clickable(indication = null,
onClick = {
Log.e("test", "test")
})
)
}
}
}
}
}
And this code has pretty much the same performance if I remove the clickable modifier.
Is there a chance you can share with me more complete repro project so I can debug it?
ap...@google.com <ap...@google.com> #3
I also had a problem reproducing it as well. It only happens when I build for a physical device (ARM). Adding clickable when deploying on an emulator has no effect.
ad...@gmail.com <ad...@gmail.com> #5
one is 5.1 another one is 7.1.2
ma...@gmail.com <ma...@gmail.com> #6
Project: platform/frameworks/support
Branch: androidx-master-dev
commit 17cd20811cfd5df0dceb95706d76248f2f7f2e42
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Tue Sep 22 20:09:35 2020
Scroll performance optimization for LazyColumnFor/LazyRowFor
We were unnecessary recomposing all the visible items on every scroll offset if the items type was not stable(if it was stable the recomposition was skipped using the regular runtime logic). In this change I introduced the itemContent lambda caching logic which allows to reuse the same lambda instance for not changed items. If we pass the same lambda instance into subcomposition the runtime will skip the whole composition as there is nothing to recompose. We clear this cache if the new itemContentFactory was provided or if the parent constraints have been changed.
Bug: 168293643
Bug: 167972292
Bug: 165028371
Relnote: Performance optimizations for LazyColumnFor/LazyRowFor scrolling by not doing unnecessary recompositions during every scroll
Test: tested manually and with a new test for both LazyColumnFor and LazyRowFor. Instead of 18 recompositions for each item for a simple scroll we do none of them.
Change-Id: I64f6568fd1193a6d28e3e2e2205b977f4a5f116b
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/LazyColumnForTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/LazyRowForTest.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/CachingItemContentFactory.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyFor.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyForState.kt
https://android-review.googlesource.com/1434551
Branch: androidx-master-dev
commit 17cd20811cfd5df0dceb95706d76248f2f7f2e42
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Tue Sep 22 20:09:35 2020
Scroll performance optimization for LazyColumnFor/LazyRowFor
We were unnecessary recomposing all the visible items on every scroll offset if the items type was not stable(if it was stable the recomposition was skipped using the regular runtime logic). In this change I introduced the itemContent lambda caching logic which allows to reuse the same lambda instance for not changed items. If we pass the same lambda instance into subcomposition the runtime will skip the whole composition as there is nothing to recompose. We clear this cache if the new itemContentFactory was provided or if the parent constraints have been changed.
Bug: 168293643
Bug: 167972292
Bug: 165028371
Relnote: Performance optimizations for LazyColumnFor/LazyRowFor scrolling by not doing unnecessary recompositions during every scroll
Test: tested manually and with a new test for both LazyColumnFor and LazyRowFor. Instead of 18 recompositions for each item for a simple scroll we do none of them.
Change-Id: I64f6568fd1193a6d28e3e2e2205b977f4a5f116b
M compose/foundation/foundation/api/current.txt
M compose/foundation/foundation/api/public_plus_experimental_current.txt
M compose/foundation/foundation/api/restricted_current.txt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/LazyColumnForTest.kt
M compose/foundation/foundation/src/androidAndroidTest/kotlin/androidx/compose/foundation/lazy/LazyRowForTest.kt
A compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/CachingItemContentFactory.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyFor.kt
M compose/foundation/foundation/src/commonMain/kotlin/androidx/compose/foundation/lazy/LazyForState.kt
Description
When using the new fragment state manager , if a fragment is inflated after the host activity is RESUMED, via either the deprecated , the fragment never makes it to a RESUMED state.
<fragment>
tag orFragmentContainerView
In the case of the
<fragment>
tag:VIEW_CREATED
and never makes it any furtherfor
FragmentContainerView
:RESUMED
the first time, but on configuration change, the view that inflates the fragment is never attached to the new view hierarchy, so the fragment isRESUMED
but never actually visible.We should address this issue for both components. aosp/1591056 and aosp/1593053 have been implemented for the
<fragment>
tag case. This bug will track theFragmentContainerView
case.