Faster Startup Times With Startup Tracing On Android

Avatar

Jon

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.

Getting Started

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>:

This can also be in the Android Options in your project settings starting with Visual Studio 2019 16.3 Preview 2:
Enable startup tracing with a line of code.

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.

Faster Startup Times With Startup Tracing On Android

Differences in AOT Modes

TypeStartup SpeedAPK Size
Normal2s914ms16.1 MB
AOT1s18ms34.6 MB
Startup Tracing1s518ms20.1 MB

 

Feedback

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.

Avatar
Jon Douglas

Program Manager, Xamarin.Android

Follow Jon   

25 comments

  • Avatar
    T. P.

    Thanks for that blog post. I am still a bit confused about what the different between the “traditional” AOT and the Startup Tracing AOT is – especially because Startup Tracing has slower startup speed than AOT and significant smaller APK sizes.
    Does Startup Tracing mean is only AOTs parts of the app (the parts that impact app startup) and normal AOT precompiles the whole app? In that case the normal AOT would be still the way to go if we want optimal app performance after startup, right?

    • Avatar
      Jon Douglas

      Yes that is correct. It’s also known as a partial AOT where only parts of assemblies (such as those needed during startup) are AOT’d. That is the major difference here between traditional/full AOT and startup tracing AOT. 

      • Avatar
        Frank Krupp

        I am also a bit confused. In Visual Studio 16.2, I have now the checkbox: “Enable Startup Tracing” and the tooltip says: “Enabling this option decreases startup time at the cost of a larger apk file”
        Doesn’t your blog say: Enabling this option partially disables AOT and increases startup time to get a smaller apk?

  • Avatar
    Matteo Piccioni

    hello, Startup Tracing 
    – ofc, startup tracing is available also in preview channel version of visual studio?
    – could I enable it on debug too?
    thanks

  • Avatar
    Luis Capelo

    I’ve tried enabling this and don’t see any visible improvement in the app loading time.still takes around 10 seconds to get past the splash screen… which is very slow. I can see a lot of libaot-***.so files in the package lib folders, so it must be doing *something*, just not something that seems a difference 🙁

  • Avatar
    Massimiliano Cristarella

    Hi, I noticed that if in the project name/path there are spaces and the startup tracing is enabled it doesn’t compile end it gives you this error:
    Gravità Codice Descrizione Progetto File Riga Stato eliminazioneErrore  XA0000: Unhandled exception: System.ArgumentException: Caratteri non validi nel percorso.   in System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)   in System.IO.Path.GetFileName(String path)   in Xamarin.Android.Tasks.Aot.<>c__DisplayClass77_0.<RunParallelAotCompiler>b__0(Config config)   in Xamarin.Android.Tasks.AsyncTaskExtensions.<>c__DisplayClass0_0`1.<ParallelForEach>b__0(TSource s)    0  

    • Avatar
      Jon Douglas

      This is a limitation with the Android NDK. The Android NDK does not play nicely with spaces in a path. We are removing the dependency on the Android NDK in a future release, but just make sure you do not use spaces in your paths as it’s a general guideline for Android tooling. This also goes for any special characters as well.

  • Mark Adamson
    Mark Adamson

    Is the APK size aspect less relevant for apps that allow the play store to unbundle the apk and repackage for each platform? Or is the AOT-induced increase in size a per-platform thing? Sorry I can’t remember the term for google’s rebundling and don’t know if Xamarin supports it or not.

    • Avatar
      Jon Douglas

      This aspect is prevalent for any app, whether it’s using Android App Bundle or not. We have preliminary support for App Bundle in this release as well, with proper IDE tooling coming in a future version.

      The AOT bloat is a single hit per CPU/ABI. For each additional CPU you add to your APK, you would have another hit of the native libraries needed per platform and the type of AOT used (i.e. Full or Partial/Startup Tracing) (~5-10mb).

      https://devblogs.microsoft.com/xamarin/shrinking-android-app-size/ has more information as to how size is affected, but with AOT you would see a large hit within the “lib” folder as Mono would produce a .so file on the side of each assembly.

      App Bundles is here to save the day as instead of having a “fat APK” with all of these items, you are providing everything to the Google Play Store and they are dynamically delivering an optimized package to user’s devices, i.e. One ABI, Specific Locale Resources, Specific Screen Density, etc.

      We’ll be blogging on this topic in the near future with associated documentation.

  • Avatar
    ptk

    This has been failing for us when packaging/archiving the app.

    Create a brand new Xamarin Android app, adding the AndroidEnableProfiledAot option, then Build – Archive. The build succeeds but the packaging/archiving fails. The only error is “Cannot create the archive file because the packaging process failed”. 

    Any idea where to find further info on this? This is Visual Studio 16.2

  • Avatar
    Piotrek

    Hi I try to use AOT option, but I cannot compile project due to linker error. Do I need add linker config to my project? Will AOT enable link user assemblies ?

  • Avatar
    Corné

    Unfortunately my app crashes during startup when I enable this. Any suggestions on how or where to find out what’s causing the crash?

  • Avatar
    Jerzy Piechowiak

    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… 
    https://github.com/xamarin/xamarin-android/issues/3480

  • Avatar
    Paola

    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,
    Paola.

  • Ishu Sharma
    Ishu Sharma

    Hello, Still face confusion i used Visual studio 2019 Community Edition 16.1.6 how to decrease Splash Screen time.

Leave a comment