Don't know, in my community version Android project i initially had <AotAssemblies>false</AotAssemblies> so just put it to true, it doesn't change back.
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
@Caioshin said:
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.247 Target Version: 7.1 Dependencies: Loads!, We use around 15 Syncfusion controls as well as lots of nugets XAMC usage: used on whole forms assembly Image 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?
AOT is a feature of Xamarin.Android, so no Xamarin.Forms version dependencies
AOT does not require Release mode, but Debug will naturally be slower and skew production performance tests
Crash at startup - I don't have a magic answer to that. Dig through the crash report. Add logging. Use HockeyApp to catch/report them.
@zahikramer because assuming his app is built the same way as eShop is not wise.
re: eShop - I'm looking into how the group built that app and what we can do to optimize it.
@DavidOrtinau Great David!
It can be a perfect exercise before and after.
Please you Xamarin guys, make another branch there like "Optimized",
and write the App for best Startup time.
Can you do that?
(As i read the docs there , it says it is a model for Xamarin App and Backend apps... So..... )
When I try to enable the AOT I get the error: "Could not AOT the assembly" and a few DLL names.
Any ideas on why? Or some way to better see the full error?
I would open and review the build logs if you're not getting the info in the IDE. On VSMac it's Help > Open Log Directory and on VS it's Help > Xamarin > Open Logs.
If that doesn't help, log an issue for the Android team to review and let me know the number please.
@DavidOrtinau , While we are at the performance tip on AOT, is there any initiative to reduce the final output size. Currently the final apk size is more than 3 times the normal compile.
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:
So you mean, that 10s is too long? Then how about Xamarin Live app, which is in 99% written in Xamarin Forms, and it's starting up in 7 seconds at my device ?
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:
So you mean, that 10s is too long? Then how about Xamarin Live app, which is in 99% written in Xamarin Forms, and it's starting up in 7 seconds at my device ?
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.
Just tested a distributed Forms 2.3.4 MVVM light app on my S5 and a larger Prism app with 2.3.5-pre6 (both apk compiled with SDK assemblies), both boot about 6-6.5 seconds.
The Prism app spins up more IoC services upfront due to the app api been more complex.
@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
Out of interrest. Does anyone have any good ways for Sizing resources for Android / ios?
I am following the steps here to optimise startup but and see it mentions Sketch and Zeplin but these are paid services. Does anyone have any good free solutions?
@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.
So my conclusion is:
AOT 5 seconds
My code 3 seconds
Unknown 2 seconds?
AOT causes alot of headaches when switching between debug and release though. especially when trying to debug an error due to AOT, so much so that I don't think I will be able to use it.
The only thing I didn't check and I know is probably an issues is the amount of nugets and third party dlls we use. We have 115 nugets on our project
Posts
@rogihee trying using msbuild with /p:AotAssembles=true
@DH_HA1 @DavidOrtinau , found it, thanks! For anyone on Community Edition, manually edit your project file:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> .. <AotAssemblies>true</AotAssemblies> </PropertyGroup>The problem with editing manually is that anytime you go into the project properties UI, it will get removed. We've been using the build parameter.
Don't know, in my community version Android project i initially had
<AotAssemblies>false</AotAssemblies>so just put it to true, it doesn't change back.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
Damn it, I've just reduced my app startup from 6 seconds to 3 seconds, with just using AotAssemblies at Android.
I'll check this on iOS.
Totally true, though i have a feeling that Aot trick speeds up things indeed.
Anyway just a few small tricks for transitions: https://forums.xamarin.com/discussion/comment/277020/#Comment_277020
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
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?
@MichalDobrodenka.3459
Yes I do.
3.0 pre-release right now doesn't include any additional work on Android startup over 2.3.5-pre.
+1 for android Startup time. App takes around 10 seconds to start on a good device. I can only account for around 2 of that.
Try to follow this - https://forums.xamarin.com/discussion/comment/284078/#Comment_284078
At my chinese Meizu phone, app starts up in around 6-7 seconds WITHOUT this, and around 3 second WITH this AotAssemblies flag.
@NamyslawSzymaniuk @DavidOrtinau
Whats the official word on AOT?
from the documentation it says:
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:
Hi @DavidOrtinau .
Why do you need @JKay project?
You can use yours: https://github.com/dotnet-architecture/eShopOnContainers
Can you make that Startup time less then 13sec? 6sec? 2sec?
@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.247
Target Version: 7.1
Dependencies: Loads!, We use around 15 Syncfusion controls as well as lots of nugets
XAMC usage: used on whole forms assembly
Image 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?
@JKay
AOT is a feature of Xamarin.Android, so no Xamarin.Forms version dependencies
AOT does not require Release mode, but Debug will naturally be slower and skew production performance tests
Crash at startup - I don't have a magic answer to that. Dig through the crash report. Add logging. Use HockeyApp to catch/report them.
@zahikramer because assuming his app is built the same way as eShop is not wise.
re: eShop - I'm looking into how the group built that app and what we can do to optimize it.
@DavidOrtinau Great David!
It can be a perfect exercise before and after.
Please you Xamarin guys, make another branch there like "Optimized",
and write the App for best Startup time.
Can you do that?
(As i read the docs there , it says it is a model for Xamarin App and Backend apps... So.....
)
@DavidOrtinau Thanks for the reponse.
I'm going to try get AOT working in release seems like the best way to reduce startup time
@DavidOrtinau
When I try to enable the AOT I get the error: "Could not AOT the assembly" and a few DLL names.
Any ideas on why? Or some way to better see the full error?
@LGMaestrelli are you on the latest Android 7.x? Couple issues fixed with that error message. https://developer.xamarin.com/releases/android/xamarin.android_7/xamarin.android_7.4/
I would open and review the build logs if you're not getting the info in the IDE. On VSMac it's
Help > Open Log Directoryand on VS it'sHelp > Xamarin > Open Logs.If that doesn't help, log an issue for the Android team to review and let me know the number please.
@DavidOrtinau , While we are at the performance tip on AOT, is there any initiative to reduce the final output size. Currently the final apk size is more than 3 times the normal compile.
So you mean, that 10s is too long? Then how about Xamarin Live app, which is in 99% written in Xamarin Forms, and it's starting up in 7 seconds at my device
?
@NamyslawSzymaniuk On Nexus4 Xamarin Live takes 15sec to start!
xDDD it was 7 sec on my cheap Meizu M2 Mini
Ha. Funny
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.
@JKay try using the "Generate on package per selected ABI" option in the Android options.
This will result in multiple apk files that you have to upload to google play.
@DirkWilhelm Thanks for a solution. From the documentation it says:
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.
Just tested a distributed Forms 2.3.4 MVVM light app on my S5 and a larger Prism app with 2.3.5-pre6 (both apk compiled with SDK assemblies), both boot about 6-6.5 seconds.
The Prism app spins up more IoC services upfront due to the app api been more complex.
@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
Out of interrest. Does anyone have any good ways for Sizing resources for Android / ios?
I am following the steps here to optimise startup but and see it mentions
SketchandZeplinbut these are paid services. Does anyone have any good free solutions?Edit Found this site: http://assets.codly.io/ looks great
@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:
So I can account for 3 seconds. The other 7 seconds are completely unaccounted for. AOT saved around 5 seconds.
So my conclusion is:
AOT 5 seconds
My code 3 seconds
Unknown 2 seconds?
AOT causes alot of headaches when switching between debug and release though. especially when trying to debug an error due to AOT, so much so that I don't think I will be able to use it.
The only thing I didn't check and I know is probably an issues is the amount of nugets and third party dlls we use. We have 115 nugets on our project