Faster Startup Times With Startup Tracing On Android
One of the biggest pain points we’ve heard from you is startup times on Android.
Improving Startup Times
If you use AOT today, it improves startup times drastically, but you suffer in APK size bloat. This, unfortunately, is not a bargain that most Android applications can take in this modern-day as we must keep our users at the forefront of our decisions. They also ensure that they don’t have to download a large APK just to use our services. There must be a better way forward we thought.
We wanted to make sure we address this problem head-on by giving you the best of both worlds; a performant startup experience, and minimal increase to APK size.
Starting today, we’re announcing faster starter times using Startup Tracing on Android for all versions of Visual Studio.
What is Android AOT?
The Android runtime(ART) is a managed runtime used by applications and system services on Android. ART as the runtime executes Dalvik Executables (.dex files – Dalvik EXecutable) which is a compact format to store Dalvik bytecode.
ART introduced the use of ahead-of-time (AOT) compilation by compiling entire applications into native machine code upon the installation of the application. This brings faster execution of applications and improved memory allocation. As well as garbage collection mechanisms, more accurate profiling, and much more.
To accomplish this, ART uses a utility known as
dex2oat (Dalvik Executable to Of Ahead Time) to create an ELF (Executable and Linkable Format) executable. The downside requires additional time to compile. Additionally, applications take up larger amounts of disk memory to store the compiled code.
What is Mono AOT?
The Mono runtime provides an ahead-of-time (AOT) feature. Which Mono will precompile assemblies to minimize JIT time and reduce memory usage.
Mono can generate an ELF .so file on platforms that support it such as Android. It then stores a precompiled image next to the original assembly.
i.e. Mono.Android.dll → libaot-Mono.Android.dll.so
These files can then be used by the Mono runtime and omit the JIT overhead alongside similar downsides such as Android AOT.
What is Startup Tracing?
Mono introduced a feature which allows one to use a built-in AOT profiler on an application to generate an AOT profile. The profiler conducts memory profiling, execution time profiling, and even a statistical-based sampling for profiling. This generates an AOT profile that can be used to optimize your application when using Mono’s AOT feature with a profile.
Startup Tracing can be used with Visual Studio 2019 Version 16.2 or Visual Studio for Mac 2019 Version 8.2.
You can get started with Startup Tracing by editing your Android project’s .csproj file and adding the following property inside your Release <PropertyGroup>:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> <AndroidEnableProfiledAot>true</AndroidEnableProfiledAot> </PropertyGroup>
This can also be in the Android Options in your project settings starting with Visual Studio 2019 16.3 Preview 2:
For more documentation on Startup Tracing, see our release notes on this topic.
This will tell Mono’s AOT compiler to enable startup tracing which uses a default profile and speed up the startup time of your Android applications when deploying.
Differences in AOT Modes
|Type||Startup Speed||APK Size|
|Startup Tracing||1s518ms||20.1 MB|
Get the best of both worlds with startup tracing and use it in your Android apps today.
We’re continuously improving this experience and want to know your thoughts on it! For anything you believe is an issue with Startup Tracing with Android apps, please file an issue on Developer Community.
Additionally, let us know if you have any suggestions for how we can improve the Startup Tracing experience.
I’ve tested this on our application, here are the results:
Normal:Build time: 3 minutes 30 secondsSize: 45 MBStartup time: 12 seconds
Startup tracing: Build time: 7 minutes 30 secondsSize: 60 MBStartup time: 12 seconds
AOTBuild time: 18 minutesSize: 145 MB (we split this for architectures, in result we have 4 APKs each 45 MB)Startup time: 9 seconds
In our case, it doesn’t work at all. No benefit.
Normal AOT is much better in terms of performance, but since Visual Studio 2019 it is broken on some older devices.
I’ve posted github issue, but no one is respondning there…
Hi Jon, thanks for the post.
Unfortunatly, I can’t use AOT because when I added the “Enable AOT” (under Release) in the .csproj file, then the archiving process fails!!
I’m using Visual Studio 2019 16.2.3 and Xamarin.Forms 4,1..
I can’t understand why and, as many of app-developers, I need to have Faster Startup Times.
Have you any suggestion?
Thanks a lot,
I had the same problem, installing the NDK solved it for me:
Make sure Android NDK installed correctly and it’s working, cause AOT compiles into native code (machine code) if i’m not mistaken.
Hello, Still face confusion i used Visual studio 2019 Community Edition 16.1.6 how to decrease Splash Screen time.
I did a test, all 4 ABIs (x86 + x64 + arm 32+64bit) were included in the APK.
Tested on PC Emulator, Release build. (maybe could get diff results on a real phone?)
Default: ~13sec startup, 38MB
Startup trace ~8sec, 43 MB
Full AOT + link: ~3 sec, 71MB
Considering all above, I think AOT is still the best.
If size matters, obviously, you need only 2 ARMs to release on Android, so size will be ~half.
If still huge, you can split into multiple APK.
Or use App Bundle (if you dare to share your keys with Google…)