Speaking about performance, what do you thing about page transitions?
In my experience one of the slowest part of my app, that gives to the user an experience not optimal is the transition between pages, especially when in the target page I've a complex UI.
The user tap on a button, then in my app it starts an animation (ie a busyindicator), that after few milliseconds stops to rotate because probably the render process of the new page is too heavy, and this doesn't give a fluent UX to the user.

Then I've to wait a couple of seconds before new page arrive.
I'm already using async/await pattern, and I already tried to remove all the logic from constructor of the new page, but if in the target page I've a very complex xaml I always have the same lag before a new page is pushed and presented.

I would like to know if there's some trick to improve the navigation, because it's one of the most important process that gives to the user an impression of a fast or slow app

Thanks a lot @NickKovalsky . I haven't set animated = false before, and justed PushAcync, which has animated = true by default. With that, navigating to my complex XAML pages tooks even 2 secs. Right now, it tooks around 1-1,2 secs for such pages. Good tip, even loosing pages transitions animation.

I'm testing different ways to improve transitions: seems that enabling AOT (putting false under active configuration, with or without EnableLLVM, doesn't matter) has the only result to make the build process slower.
It seems that the app startup isn't improved, and measuring the time of page transition I have a little worsening of performance.
Without animation the time measured is the same, but it seems to be more fluent and this gives to the user a little improved user experience

@Caioshin said:
I'm testing different ways to improve transitions: seems that enabling AOT (putting false under active configuration, with or without EnableLLVM, doesn't matter) has the only result to make the build process slower.
It seems that the app startup isn't improved, and measuring the time of page transition I have a little worsening of performance.
Without animation the time measured is the same, but it seems to be more fluent and this gives to the user a little improved user experience

To gain speed in my transitions I allways instantiate the page on a background thread and push it on UI thread (this is the best tip i have). Remove nested controls if possible, cut down on bindings as they can be very heavy. I nowadays only bind the things that can change and set the rest up in codebehind, this gives me a boost in performance. As for working with images i can recommend FFImageloading especially for android. And if hou havnt enabled XAMLC, do so

Thank you for your suggestion @BjornB, I'm already using XamlC, and I'm reading about performances related to bound properties.
I'm not sure about page instantiation because I'm using #Freshmvvm that automatically creates a new instance of page and its context viewmodel when I push a new page, so it's not clear if there's a way to move up the page creation in order to save time.
What I noticed is that the first navigation to a new page always take a lot of time more than the second one and following, even if it seems that a new instance of page it's always created.

We evaluate Xamarin.Forms every year (we would love to switch to something like it to have common code base). This year we found everything we wanted, but we had to reject it and continue going Native, due to Application StartUp performance. Several seconds (not hundreds ms) longer is simply not acceptable. AOT helps a lot, but generally is so much broken, that I have never seen it working on anything else but small demos.

We have tested latest prerelease and also 3.0 prerelease.

Do you think that Xamarin.Forms on Android have a chance for massive startup improvement?

AOT is currently an experimental feature. It is not recommended for production use. AOT and LLVM was available in Xamarin.Android 5.1, but it is no longer available in later Xamarin.Android versions. For more information, please see the Xamarin.Android 6.1 release notes

Should I be using AOT for production? Is this supported in the latest (Xamarin.Android 7.3)?

EDIT Tried AOT using VS2017 Enterprise but made no difference to start up time whether it was on or off. I guess its disabled in later versions?

I haven't used LLVM, and from these words:
"AOT and LLVM was available in Xamarin.Android 5.1, but it is no longer available in later Xamarin.Android versions." I understand, that it's about both features.

For me, AOT is working fine on latest Xamarin Forms 2.3.5.256-pre6, and app working fine on my phone with Android 7.1.2.

@JKay AOT works again in 7. You can read a bit of explanation for it being disabled in the Android 6 series release notes,

Official word is that it's an experimental feature. As you can see from reports here alone, it can make a big difference and some have been using it in production apps with success. Scanning the Android 7 series release notes you can see the team has been continuing to improve AOT and fix issues.

Even so, 10s startup in release mode on a modern device and version of Android is surprising. Agh! Would you share your project with me? I'm curious about:

@DavidOrtinau My application is our companies main app so I wont be able to send it over. But I can give answers to your questions.

Forms Version: Latest Stable, 2.3.4.247Target Version: 7.1Dependencies: Loads!, We use around 15 Syncfusion controls as well as lots of nugetsXAMC usage: used on whole forms assemblyImage usage: alot of images maybe 100 odd

Couple of questions:
Does AOT need latest pre release of forms to work?
Does AOT need to be built in Release mode to work?
Also when running in Release + AOT with "no linking" I get a crash at startup how do you advise I debug that error?

Managed to get AOT working and got my 10 seconds down to 5 seconds. Which is better. But it did bloat my apk from 50mb to 160mb (both with SDK linking enabled). which is too big for standard google play upload. I'm still looking into whether there is anything else I can do to optimise start up as I'm not sure AOT is going to be a viable solution because of the app bloat.

In some situations it may be advantageous for an application to have multiple APKs - each APK is signed with the same keystore and shares the same package name but it is compiled for a specific device or Android configuration. This is not the recommended approach

So I'm not sure this solution is for me.

Using AOT for the past 2 days I have found it very frustrating (because of long build times) and random crashing.

For now I'm turning AOT off. It seems like a bit of a band aid for poor startup times which ultimately just need addressing

@JKay I agree with @DirkWilhelm that is exactly what we do. Ours is 250mb packaged together so we just upload each platform on its own. There is no way we could go back to using non AOT. Each ABI is about 30 megs which works out just fine for us. I would highly suggest it.

EDIT: @JKay I wonder what you are doing that causes that slow of app startup. We have over a million lines of code, as I said a 250mb package, a pretty large application for desktop let alone mobile and our startup times are down to under 3 seconds.

@AlbertK we are always mindful of size, but there's not a current task on the Xamarin.Forms team. I recommend raising that question in the Android forum, and I'd be surprised if there aren't other conversations already there on that topic.

@NamyslawSzymaniuk@void
Xamarin Live is a deceptively complex application. The UI is simple, but my understanding is it has a lot of dependencies to make it work. Hence the slow startup.

Which isn't to say we should accept that startup time as "ok". It's not by a long shot.

@BradChase.2654 We use Continuous deployment, so our releases are all automated. I'm not sure that the Automated google play upload can deal with multiple different .apk uploads. I will investigate it though. I am also going to spend some time this morning looking at start up times more

@JKay As for sizing resources, we just ended up using SVGs because there would have been way too many variations of images and would have been massive in the end. Keep me posted on the startup times... I would still be interested in the differences between the apps that cause that large of a discrepancy... Maybe certain libraries? Have you cleared through the common problems that David highlighted?

@BradChase.2654 I spent most of the morning looking at startup. I worked through davids points (alot I was doing already xamlc etc)
I optimised all my images and used AndroidPreCrunch, which didn't seem to do much although I think loading views is quicker though hard to tell

My results were as follows:

Loading Styles - 0.7s

Loading Data into memory - 1.63s

Loading Initial Page - 0.7s

So I can account for 3 seconds. The other 7 seconds are completely unaccounted for. AOT saved around 5 seconds.