[android] avoid View.Context during CollectionView scrolling#8243
Merged
hartez merged 1 commit intodotnet:mainfrom Jun 22, 2022
Merged
[android] avoid View.Context during CollectionView scrolling#8243hartez merged 1 commit intodotnet:mainfrom
hartez merged 1 commit intodotnet:mainfrom
Conversation
Context: dotnet#8012 Context: https://github.com/Kalyxt/Test_CollectionView We had some reports of poor `CollectionView` performance while scrolling on an older Android device. Reviewing `dotnet trace` output, I did find some issues similar to dotnet#8001: 317.42ms (1.1%) mono.android!Android.Views.View.get_Context() 1% of the time is spent in repeated calls to `View.Context` inside the `ItemContentView` class. Making a new overload for `ContextExtensions.FromPixel()`, I was able to remove all of these calls. This results in only a couple `View.Context` calls on startup now, much better: 1.30ms (0.01%) mono.android!Android.Views.View.get_Context() Using the "janky frames" metric from the latest profiler in Android Studio Dolphin: https://developer.android.com/studio/profile/jank-detection With my slowest Android 12+ device, a Pixel 4a, I could actually see a few "janky frames" while scrolling the sample. With these changes in place, I only see 1 "janky frame" now. I also compared the before and after with the visual GPU profiler: https://developer.android.com/topic/performance/rendering/inspect-gpu-rendering It appears at a glance that these changes are better. I am unsure at what point the performance will be good enough to close dotnet#8012, but this helps!
jonathanpeppers
changed the title
hartez
approved these changes
Jun 22, 2022
Eilon
added
the
perf/general
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context: #8012
Context: https://github.com/Kalyxt/Test_CollectionView
We had some reports of poor
CollectionViewperformance whilescrolling on an older Android device.
Reviewing
dotnet traceoutput, I did find some issues similar to #8001:1% of the time is spent in repeated calls to
View.Contextinside theItemContentViewclass. Making a new overload forContextExtensions.FromPixel(), I was able to remove all of thesecalls.
This results in only a couple
View.Contextcalls on startup now,much better:
Using the "janky frames" metric from the latest profiler in Android
Studio Dolphin:
https://developer.android.com/studio/profile/jank-detection
With my slowest Android 12+ device, a Pixel 4a, I could actually see a
few "janky frames" while scrolling the sample.
With these changes in place, I only see 1 "janky frame" now:
I also compared the before and after with the visual GPU profiler:
https://developer.android.com/topic/performance/rendering/inspect-gpu-rendering
Before:
After:
It appears at a glance that these changes are better.
I am unsure at what point the performance will be good enough to close
#8012, but this helps!