Android slow StartUp time - SOLUTION!
ILMember ✭✭✭
My solution after 2 weeks of work, for StartUp time on Android Without AOT is Dual SplashScreen.
Actually, there is no magic here. The same init time is remains. This solution is based on UX "Perceived Performance".
UX here will be much better. Instead of the user sees a long-time delay on one splash screen (or without splashscreen, which is worse),
Now, the user sees 2 splash screens:
1. The normal splash screen, and…
2. Screenshot of the first interactive screen the user engaging when the app starts.
I called it 'FirstScreen', which I implement it with MainActivity. The user sees what screen he going to get while progress bar is showing, and when
the rendering is finished, the image (as a background) is switched with the real Page.
If we analyze the delay at the start (cold start), there are 2 kinds of delay:
1. Init code of different components (Forms.init, DI init (e.g. autofac etc.))
2. Rendering of the page.
So, by splitting the init code to the first activity (SplashActivity) and leaving only the Render delay to FirstScreen (or MainActivity), we can split the
delay time by 2 pages, and that way the user sees half of the total delay, on each screen.
Users starts to count the seconds on static screen. So, if you move fast to another screen, you good.
The perception now is the app starts FASTER (even actually, as you'll see later the app starts even slower a little bit).
I put my solution on Github DualSplash.
Check it out.
Credits to Ideas and components:
1. Acr.UserDialogs of Allan Ritchie @AllanRitchie.
2. XF Page_Load event by Mohamed Yousuf @yousufctec .
3. Splash screen in XF by Adam Pedley @AdamP .
4. Thank you All!
Issac Kramer.
Posts
I tweaked the code even further, and now the difference is even better.
Check it out.
Hi @zahikramer:
I liked the idea, while I must say, this one is good.
It would be good, if on git page you upload some comparison GIFs side by side and some bench-marking in graphical form (since you already have used stopWatch in code, data is already with you), that would create good impact. 1 like from me. Kudos.
Regards,
N Baua
Thank you very much @N_Baua .
Sorry, but I don't have the time for that, besides , i need you to see the miracle "with your own eyes"
Regarding time, it depends on what device you running.
On my nexus4 SingleSplash takes 10s to start, and DualSplash takes 5s.
On the emulator 4s on Single, 2s on Dual.
THIS IS THE WHOLE POINT! you are is the one who decides how much time it takes on the Splash Screen.
Read what i wrote in the notes on github repo, you can play with the init code and stick it on the first splash , or the second.
Enjoy!
Issac Kramer
okey, fair enough
Just couldnt build it.
Technically it's a Jedi mind trick...not a solution
The Matrix Steak
Our job is to make our customers/users happy. Nothing beyond that!
You are right @NickKovalsky , i made a clean clone and i got the error "path too long" because of the long name of the Repo. Just cut the name (or move the whole Repo to short path) and make a full solution build , and I hope you good to go.
It is well documented here also - https://developer.xamarin.com/guides/android/user_interface/splash-screen/
Thanks @LewisK .
The well documented topic is SingleSplash and not DualSplash.
I red it before, and it gave me even the pinpoint of the direction, but it is far far away from the implementation of
DualSplash.
Check it out.
Buh, I also implemented the AOT options and that reduced the launch time by 3-4 seconds, wish Xamarin studio and Visual Studio options have this implemented in project properties somewhere as a simple check box, I had to manually edit the project file, just to add AOT value as true from default as false.
Does AOT not increase the APK size though?
@NamyslawSzymaniuk AOT is fine solution, but it quadruples the APK size (for me at least),
and sometimes it's a size you cannot release to store (users will be suspicious about it and the download time on 3G network will be BAD).
But consider this: even after your AOT solution, you can ADD my solution and now instead of 3s startup you'll have 1.5s start up (!!!!). Isn't that better?
My solution is good for every framework, even MVVMCROSS or other (I checked vanilla mvvmcross startup and it's slow like XF.
You don't have to use it. For my opinion it's a great quick solution if you have complex app and you want quick solution without the need to start digging in you code and Refactor all the way down (until you will succeed to squeeze 1 or 2 sec).
It is only an option for your considerations.
@N_Baua on Visual Studio 2017 Enterprise edition there is AOT checkbox.
And another point to remember:
This solution is only for Cold Start. After the App loaded, and went to background, when you
press the App Icon, it start immediately , for real!
So the problem (and the solution) is only on the first time launch.
Doesn't the users deserve for a better and quick response??
@zahikramer
on Visual Studio 2017 Enterprise edition there is AOT checkbox.Thanks for the info, didn't knew that they went for it. I am on community edition (being a small start-up).
BTW Issac, AOT + Linker isn't that bad on file-size -and- performance, sure your solution tricks the users much better. kudos for that.
N Baua
@N_Baua
Thank you very much Nhilesh.
For me AOT+LLVM+linking took +120Mb apk size (and on the phone it shows even larger number for some reason(??)).
But as you say, every case is different.
I'm also small startup , so i applied for Microsoft Bizspark: https://bizspark.microsoft.com/ , and i got VS Ent for free for 3 years.
Try that you 2!
Thanks for the tip, I'll try Bizspark option.
APKs deflate on device, this is usual I guess, Android also keeps Res+Cache element in install location + any other file operations and service data gets accumulated, so it will always be on higher side.
@N_Baua for your request:
Hello! I want to test this project. I downloaded the solution and when I open it in VS Community 2017 over Windows 7 x64, the IDE can't load DualSplash.Core project and shows me an error because not found this file:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Sdks\Microsoft.NET.Sdk\Sdk\Sdk.props
What is my mistake? Thanks!
Hi @Josecanalla .
I answered you on github.
Tell me if it worked....
@zahikramer is it healthy to initiliaze packages in async method like you did below? i was having problems with that once I uploaded on production and decided to do it sync again. And what is the reason you have GoogleAnayltics initialize and Xamarin Insights on different Activities?
await Task.Run(() => { if (bundle == null && !Insights.IsInitialized) { Xamarin.Insights.Initialize("AppID", ApplicationContext); //"b7015d6e120008cb54e81254b603f354855b059b", ApplicationContext); //Insights.Initialize("apikey", ApplicationContext); Insights.DisableCollection = false; Insights.DisableDataTransmission = false; Insights.DisableExceptionCatching = false; }Hi @batmaci .
Read it on Github Readme.
In this case it's a MUST to bundle this init code in MainActivity - "FirstScreen" with async code because
not to load the UI thread and to finish OnCreate quickly.
The whole point is to spread the init code between the 2 splash screens based on the needs of your app.
If the init code is long and render time is short so move more init code to FirstScreen and less on SplashScreen.
If init code is short and render time is long, move more init code to SplashScreen etc.
If you have very long init+render time, you can consider to do Triple SplashScreen and put in the middle splash an Ad for example, thus your long delay will be spread across 3 pages and every page will fill like 1/3 of total delay time.