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 16846 [details]
Sample and Screenshot of Android Device Manager View Hierarchy
I'm using Xaml and when I create a simple layout, the generated Android interface on the device is anything but simple.
I've attached a screenshot of the UI inspector from Android Device Manager showing a view with a StackLayout surrounding another StackLayout and a Grid.
Both the inner StackLayout and the Grid contain a Label and a Button.
Both of these Labels and Buttons in the generated views are within their own containers. Each container is in another container.
The whole thing is contained within a FrameLayout, then a LinearLayout, then multiple FrameLayouts and finally a RelativeLayout.
That's incredibly excessive. I have a real world project with more controls than this and it's suffering performance problems and I'm starting to realise it's probably because of this huge amount of complexity that's definitely not needed if you're building a native Android view.
Attached is a screenshot of the UI inspector as well as the sample project.
This is a very good find. I checked this in my application and encountered a similar situation. I have several views, all with same size and position wrapping my page content. This is really bizarre, and as you said, unnecessary. I would love to get comment on that from Xamarin team.
Same Issue with my Xamarin forms project.
Main view block has four View blocks inside that are all the same size inside each other.
Then my Scroll view inside that has another 4 extra View blocks all the same size.
This is duplicated through out the pages.
I think I am subscribed to all topics about this general issue (Android performance), browse forums regularly and I have not encountered any new information about this problem and potential solutions. I have not seen any posts from Xamarin team indicating that they are actively working on solution either. All we can do is wait and try to optimise our code as much as we can.
How can we optimize our code? Is there any way to avoid creating some of these excessive views with custom renderers?
There are a lot of ways to make your Xamarin.Forms application faster but most of them give such a minimal gain in performance that it is not worth wasting your time on them. Here you have a quite complete a list of tweaks you can use
From my experience what gives Android the most boost is:
1. Elimination of unnecessary views from your application. You generally should not wrap views in other views when you can avoid this. Wrapping label in content view is bad. Wrapping stack layout in another stack layout is super bad.
2. Replacing of complex/heavy layouts with absolute layout with proportional bounds and layout flags when possible. Relative layout is prime evil, don't use it if you don't have to.
3. General reduction of element count in layout. If everything else fails just simplify your design.
4. Using FFImageLoading CachedImage for those pages that have a lot if images. This gives most benefit when same image is reused many times.
All of these tips are great if you're not already doing them, however as someone who has already employed these it's difficult to squeeze more performance out when the system generating the views is actively working against you by creating excessive container views for every view.
No matter what you build, you have at the very least twice as many views created than what you really need.
Of course I could be completely mistaken about this issue but with Xamarin remaining silent about all Android topics, it doesn't make me confident that they have a solution yet :(
I absolutely agree Cliff. What I proposed is not a fix, it's a workaround.
We moved a lot of our stuff to custom renderers. As a matter of fact, if we didn't already have tens of thousands of LOC in XF, we would have dropped Xamarin Forms a long time ago. It's more of a toy than a serious platform apparently and the XF team seems to treat it that way.
Anyway, we got 2x improvements in perf moving to custom renderers, and some times even 3x.
1- Full page with an image and about 10 labels (e.g. a Facebook profile clone). XF: 800ms, Custom Renderer: 300ms
2- ListView with image on the left, 3-4 labels on the right. Rendering 10 items was around 650ms with XF and now 280ms without.
The "optimizations" outlined in the blog Wiktor mentioned initially gave us 10-20% improvements, and we did a lot of work to use custom layouts and drop all the stacklayouts (and basically do xamarin form's job) etc. But moving to custom renderers was a 200% improvement for half the work. Right now all XF does for us is be a singleton for views that are then rendered by custom renderers.
@aed Can you please explain how your renderers work? Are you using one giant renderer for whole page that manages all controls in native code?
@Wiktor - yes, we use giant custom renderers that render entire layouts or pages. For the profileview (i.e. user image, and a bunch of labels), we have a single ProfileViewCustomRenderer that renders the whole thing natively.
For example, the SetNativeControl() call sets the native control to a LinearLayout which has been populated with an ImageView and a bunch of TextViews in it.
Thank you @aed that was exactly what I wanted confirmed. It is funny that your way of circumventing Forms issues is to not use them. I could not believe it at first.
@Wiktor - I opened 42335 five months ago and have since escalated it to everyone in the Xamarin team (including their CEO). And there's been no update or ETA on it. Just being realistic here.
I had not seen this bug myself until now, but I can now share what we have been doing.
We have been designing a system that will allow Forms to "collapse" redundant views, merge independent features and minimize the number of native views when created.
We have started on the implementation of the fix, but there is much left to be done to make this a reality. We will keep you posted.
@miquel thanks for the update. Android performance is a top issue with Forms that we are eagerly awaiting fixes for.
@miquel thanks for the update, it's appreciated.
Hi, are there any news on this issue?
@Tobias Schulz They announced they plan to have it fixed in May 2017 as part of their 2.5.0 release.
As mentioned, these sorts of performance improvements are available on our public roadmap which can be seen here: https://forums.xamarin.com/discussion/85747/xamarin-forms-feature-roadmap