Bug 42335 - XF for Android is much slower than its iOS counterpart
Summary: XF for Android is much slower than its iOS counterpart
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.3.1
Hardware: Macintosh Mac OS
: Highest normal
Target Milestone: ---
Assignee: David Ortinau [MSFT]
Depends on:
Reported: 2016-07-02 23:17 UTC by aed
Modified: 2017-07-09 07:21 UTC (History)
30 users (show)

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

Sample depicting perf difference between Android and iOS for XF (474.71 KB, application/zip)
2016-07-02 23:17 UTC, aed

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 for Bug 42335 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description aed 2016-07-02 23:17:03 UTC
Created attachment 16561 [details]
Sample depicting perf difference between Android and iOS for XF

I am attaching a sample. While this is a tailored example, our entire apps are always 2x-3x slower on Android than on iOS, even when the Android CPU is much faster.

I'm seeing this consistently and regardless of the page contents.

To verify:
1- Run attached sample on modern Android device e.g. Google Nexus 5 (2.2GHz quad core). Average run-time= 900ms
2- Run on ios device (e.g. iPhone 6). Average run-time= 250ms

We've had apps on the app store for over a year now, with 50,000 sessions. On iOS devices, average page render time over all pages is 300ms. On Androids, it is 3,000ms.
Comment 1 aed 2016-07-07 18:24:57 UTC
Xam team can you triage this please.
Comment 2 Alexandros Elefteriadis 2016-07-16 22:34:58 UTC
I can reproduce the sample and I also see VERY slow android performance for the xamarin forms (but it okay on iOS). Why no one from the Xamarin team comment on these bugs when they are affecting every single app?
Comment 3 aed 2016-07-27 15:40:26 UTC
Lots of reports of this in the forums and in bugzilla, no response from support about it.

This has been happening for months now.

Switching to confirmed. If you are unable to repro, please let me or any of the other bug reporters know and we will happily help.
Comment 4 Cliff Cawley 2016-08-01 06:16:44 UTC
Just adding that I'm experiencing the same thing in my Android app that is due for release soon.

Personally I've reported the following: https://bugzilla.xamarin.com/show_bug.cgi?id=42948

It may or may not be causing further performance issues.
Comment 5 aed 2016-08-12 18:41:46 UTC
Another related bug for perf that might help investigate this (perf on XF Android 3x slower than perf on Xamarin Android):

Comment 6 Jason Smith [MSFT] 2016-09-07 16:51:23 UTC
We have some items coming that will help with this. We hope we can ship them to you soon. Android as a whole is slower, not just with Forms but in general. However the way android works in Forms could also be improved and we are working on some stuff there as well.
Comment 7 Wiktor Koncki 2016-09-09 08:15:10 UTC
Can you please tell us what is the expected time frame for this? Is this something we will get in two weeks of two months? I'm about to release quite big application and would certainly prefer to hold it back rather then give it to android users with current performance.
Comment 8 aed 2016-09-16 20:05:25 UTC
Can we get a status update on this? 

I'd also be happy to test any not-yet-done nuget packages to give you an idea of what the perf delta we get is. We have a pretty solid perf measuring framework set up on our app because of this very bug.
Comment 9 Tobias Schulz 2016-09-18 16:23:34 UTC
Are there any news yet?
Comment 10 adrianknight89 2016-09-22 21:23:38 UTC
XF team is lagging behind on many things. Why don't you hire more devs and pound the crap out of all the bugs and performance issues? I want to see more activity on git.
Comment 11 aed 2016-09-22 21:35:32 UTC
I'd be happy to escalate all the way to the SVP or Satya if it will help get you the resources to get this fixed ASAP.

We've had 200,000 sessions last month and nearly every one star review on the Android app store has been because of "lagginess".

There should be weekly updates and an exact ETA on this bug.
Comment 12 aed 2016-10-20 00:47:35 UTC
Any updates on this?
Comment 13 Tobias Schulz 2016-11-15 14:13:19 UTC
Any news?
Comment 14 kyle.spearrin 2016-12-07 00:02:45 UTC
Any update? We also experience this with our XF app. iOS is snappy, Android is laggy.
Comment 15 Namyslaw Szymaniuk 2016-12-12 09:33:51 UTC
XF dev team, is there any update, any progress?
I'm developing some business app, without beauty animations, just some controls, elements, lists... but the Android app, comparing to iOS app, looks like it has crappy code behind (but it doesn't!).
Android app seems to be laggy, pages are rendering in seconds (1-3) instead of (0-1 like on iOS), lists are not scrooling so smoothly like on iOS.

Everything looks more crappy and slowly, and lets be honest, you don't need any "specific reproductions" nor platform specific version/device.
Develop any app, with even a little bit complex UI (I know, simpler UI, means faster UI), then build iOS and Android app, install both and compare. Really, there is no needed any specific use case, any specific UI, to reproduce it, everyone are blaming XF Android part, about performance issues.
Comment 16 David Ortinau [MSFT] 2017-03-21 16:02:17 UTC
This is the same update I shared on https://bugzilla.xamarin.com/show_bug.cgi?id=41863.

2.3.4 contains some performance improvements and we are continuing to explore opportunities to improve Android in terms of layout inflation, startup times, etc.

On our roadmap we have several items we hope will work towards that end:
* Fast Renderers
* Layout Compression
* Group Inflation

For screens that require a higher level of performance, a custom page renderer is the best way to go. Xamarin.Android and Xamarin.iOS afford the best performance when using Xamarin.

All performance tips that apply to Xamarin.Android (and Android for that matter) still apply here as well. Make sure you're using fast scrolling. Simplify layout nesting. Avoid changing properties that will trigger a re-layout (use fixed sizing whenever possible). Etc. 

Performance will never be "done". Please follow our pre-releases and releases, and of course the roadmap for updates. 

The forums are the best vehicle to discuss this issue ongoing. 

Please use bugzilla to file specific bugs with a simple reproduction project.

Comment 17 aed 2017-03-21 17:26:21 UTC
We opened this bug 9 months ago and we still haven't seen any real change in perf. Our team has exchanged no fewer than 30 e-mails with your enterprise support and they've all been: "we're working on it, should have something soon", "we have it on a roadmap".

We disagree with marking this bug as resolved until your team has actually delivered something. At the very least, fast renderers and layout compression. I also noticed a lot of the perf bugs have begun being marked as resolved even though nothing was delivered to actually remedy them.

This bug has a really simple repro project attached to it. If we can run it again and see a perf delta that is bigger than 10%, we'll be happy to mark it as resolved. Otherwise it is not resolved.