Bug 42948 - Android layouts generated from xaml are overly complex and causing performance issues
Summary: Android layouts generated from xaml are overly complex and causing performanc...
Alias: None
Product: Forms
Classification: Xamarin
Component: Android ()
Version: 2.3.0
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-08-01 06:10 UTC by Cliff Cawley
Modified: 2017-03-10 15:43 UTC (History)
23 users (show)

Tags: ExPT
Is this bug a regression?: ---
Last known good build:

Sample and Screenshot of Android Device Manager View Hierarchy (156.62 KB, application/zip)
2016-08-01 06:10 UTC, Cliff Cawley

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Cliff Cawley 2016-08-01 06:10:14 UTC
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.
Comment 1 Wiktor Koncki 2016-08-01 11:39:18 UTC
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.
Comment 2 Tony 2016-08-03 21:52:59 UTC
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.
Comment 3 Tobias Schulz 2016-08-31 10:59:37 UTC
Any news?
Comment 4 Wiktor Koncki 2016-08-31 11:35:40 UTC
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.
Comment 5 Tobias Schulz 2016-08-31 11:54:31 UTC
How can we optimize our code? Is there any way to avoid creating some of these excessive views with custom renderers?
Comment 6 Wiktor Koncki 2016-08-31 12:19:44 UTC
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.
Comment 7 Cliff Cawley 2016-09-01 11:37:24 UTC
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 :(
Comment 8 Wiktor Koncki 2016-09-01 12:28:02 UTC
I absolutely agree Cliff. What I proposed is not a fix, it's a workaround.
Comment 9 aed 2016-11-14 07:40:54 UTC
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.

Some numbers:
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.
Comment 10 Wiktor Koncki 2016-11-14 10:42:51 UTC
@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?
Comment 11 aed 2016-11-14 17:47:26 UTC
@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.
Comment 12 Wiktor Koncki 2016-11-14 18:13:03 UTC
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.
Comment 13 aed 2016-11-14 18:43:47 UTC
@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.
Comment 14 Miguel de Icaza [MSFT] 2016-12-09 20:47:34 UTC

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.
Comment 15 dhaligas 2016-12-14 17:41:31 UTC
@miquel thanks for the update.  Android performance is a top issue with Forms that we are eagerly awaiting fixes for.
Comment 16 NMackay 2016-12-14 17:42:23 UTC
@miquel thanks for the update, it's appreciated.
Comment 17 Tobias Schulz 2017-01-01 21:29:48 UTC
Hi, are there any news on this issue?
Comment 18 Brad Chase 2017-01-04 15:03:03 UTC
@Tobias Schulz  They announced they plan to have it fixed in May 2017 as part of their 2.5.0 release.
Comment 19 Paul DiPietro [MSFT] 2017-03-10 15:43:23 UTC
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