Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 25614 [details]
Sample and ScreenShot
We are using the XF ListView and loaded a normal view(i.e., three labels and one image) in the ItemTemplate property and defined the CachingStrategy as “RecycleElement”. While scrolling continuously by fling action, scrolling gets stuck at some time in Android platform. Since, we are using the Xamarin Forms version 220.127.116.110 and TargetFrameworkVersion of Android is 7.1.
For your information, we have noticed that when the scrolling gets stuck in UI, at this time GC gets collected in the output window and we suspect that this degradation in scrolling(stuck) arises while GC gets collected.
11-09 12:44:37.365 I/art (18496): Starting a blocking GC Explicit
11-09 12:44:37.397 I/art (18496): Explicit concurrent mark sweep GC freed 314(9KB) AllocSpace objects, 6(504KB) LOS objects, 39% free, 7MB/12MB, paused 566us total 32.261ms
11-09 12:44:37.400 D/Mono (18496): GC_TAR_BRIDGE bridges 107 objects 209 opaque 10 colors 107 colors-bridged 107 colors-visible 107 xref 0 cache-hit 0 cache-semihit 0 cache-miss 0 setup 0.12ms tarjan 0.38ms scc-setup 0.11ms gather-xref 0.01ms xref-setup 0.00ms cleanup 0.04ms
11-09 12:44:37.400 D/Mono (18496): GC_BRIDGE: Complete, was running for 35.94ms
11-09 12:44:37.400 D/Mono (18496): GC_MAJOR: (LOS overflow) time 33.08ms, stw 35.23ms los size: 2048K in use: 112K
11-09 12:44:37.400 D/Mono (18496): GC_MAJOR_SWEEP: major size: 2048K in use: 1158K
11-09 12:44:39.167 D/Mono (18496): GC_BRIDGE waiting for bridge processing to finish
Step 1: Run the attached sample in Android platform.
Step 2: Open the Output window
Step 3: Now the ListView is loaded and lot of logcat is displayed in output window.
Step 4: Clear the logcat from the output window.
Step 5: Perform fling action continuously.
Step 6: Note that GC collect logcat is displayed in the output window when scrolling gets stuck.(Issue)
Can you please look into this and revert us the further details asap. We have attached the screenshot and sample too for your reference.
Also, can you please explain or provide a solution on how to overcome from this bug if custom controls are used. Since, it was replicated in custom controls too.
Dinesh Babu Yadav
Some looking around shows that this has occurred for people on regular X.A. apps as well, so I'd like to get some feedback from the Android team on this.
I am having the same problem here. It all began with updating the Xamarin.Android packages to their most recent version as well as with Xamarin.Forms 2.4.x;
FWIW: While I am trying to find a solution, it seems that the XF ListView scrolling stops everytime the Nursery of the GC is full. I tried to make it bigger, smaller, even tried to use old GC implementation (via environment file), but nothing did really help.
Can you please attach a simple repro for this issue?
@marek, simplified sample is already attached by dinesh in it first update. please look at that..
I meant a plain XA sample, sorry. The simpler the better - XF makes things more complicated.
I am facing an issue with XF in android platform.. i didn't tried with XA.
@pannir see comment 1 (it was private, I removed the masking), I'm hoping @paul can come up with something simpler.
The performance data in the OP doesn't show anything that would stand out, perhaps except for the LOS overflow which *is* weird since LOS space appears to be 39% free just moments before. That may suggest inefficiency in the app/framework code (for instance recreation of a large number of objects while scrolling ListView and rendering the cells) but the times spent collecting garbage are rather small, so they shouldn't have impact on UI performance.
That's okay. If not a problem with GC, then what would be a solution to achieve smooth scrolling without any lack?
@panning we're discussing that and the most common answer is "caching". Analyze what objects and how they are created when scrolling the view. Any and all bitmaps should be cached/reused, same applies to other views/object representing each cell. If you use images (especially from the web), it might be a good idea to use native downloaders. However, do keep in mind that it's all guesswork at this point - there might be a large number of reasons for this kind of behavior.
The reported issue occurs not only if we load images in the ItemTemplate property, it will replicate even if you load a two or three labels in it and perform scrolling continuously. Meanwhile, in the sample attachment we have referred the local images in the project for an easy demo to replicate the issue quickly. Moreover, the issue is not related to “Caching Strategy”, it even occurs if you define the Caching Strategy as “Retain Element” for ListView and similarly for custom controls(based on virtualization concepts).
Can you please provide a workaround to clear the GC while scrolling, which would be nice for developing the custom controls with better performance.
Dinesh Babu Yadav
It would be nice if Xamarin Team, resolve this issue at their end or provide a possible workaround or solution for better scrolling performance without affecting the UI while scrolling.
Dinesh Babu Yadav
I did some optimizations in my Layout as well as using some compressed layouts with XF 2.5. However, I still have a noticeable hanging while scrolling when the GC kicks in. The GC runs between 30 and 36 ms everytime it kicks in. I tried to the old, new, tarjan GC via environment file with no difference here. Are there possibly any other settings I could try?
@Dinesh, the GC is inherently indeterministic and while you can call https://msdn.microsoft.com/en-us/library/xe0c2357(v=vs.110).aspx while processing, it is NOT recommended as it puts unnecessary pressure on the runtime and makes your application behave even more unpredictably as far as the GC load/performance impact is concerned. Caching does not apply merely to images (this was just an example), but to whole ListView cells - all the views should be either cached effectively or recycled (for instance in the way Android's RecyclerView works, https://developer.android.com/guide/topics/ui/layout/recyclerview.html). If your ListView contains lots of cells/rows and they contain a number of elements (each represented as a managed object) then the only strategy to have a performing ListView (or a TreeView for instance) is to recycle the views/cells by keeping around only as many of them as you can show on the screen. Such views are loosely tied to the data you display in that they are updated with new data each time a new row/cell is to be shown by scrolling into the view - the objects in the cell stay the same, the data they present changes. If the data you present is expensive to obtain (e.g. downloaded form the internet) do use storage-backed cache and build a predictive model to load the items from that cache in background before they are to be presented by the user.
It appears the issue here might be solved by changes to the Xamarin.Forms controls/APIs and so I'm reassigning this bug to the XF team as I have no experience for Forms whatsoever and the issue doesn't appear to be related Xamarin.Android runtime.
@MSiccDev about the only idea that comes to my mind without seeing the code or knowing anything about what your app does is that there's some portion of code that runs on the UI thread and blocks it when the GC collection kicks in.
My app is a news reader app. I am using akavache to store the images of a news entry. Once an image is retrieved from there, I hold it as drawable in memory, and assign it to the view that needs it via a customized renderer. this was working well until recently.
For specific scenarios that anyone can reproduce (preferably without involving the GC, and as Marek alluded to, issues specifically involving controls and the Forms APIs), I'd request that you file a newer and more specific bug on GitHub (as we have recently moved to using that) with an updated, minimized reproduction we can take a look at, assuming these troubles still exist as of the latest 2.5.0 stable release.
Yes, it exists even in latest stable release too.
@paul, yeah, anyone can reproduce the issue means that it should be a known issue right. the reported issue gets replicated at much easier case. You can simply load any template in the listview with enabling the caching strategy and perform scroll action in Android platform.
The issue will get reproduced.
Please update any workaround to resolve this one.
If you're still experiencing this, refiling this issue on GitHub with the reproduction would be appreciated as we use that for tracking now.