Enable AOT in Xamarin for Android (Visual Studio)

Question

I know that there's support for AOT in Xamarin for Android. After the software became free, all of its features became free as well. I read around the documentation and I enabled AOT by modifying my project.csproj file, as follows:

<AotAssemblies>True</AotAssemblies>

After making sure that my project path doesn't contain spaces (breaks process), I ran a build and I got an APK with both managed .NET DLLs and native compiled libs. Sadly, the app seems to be using the .NET DLLs and completely ignoring the native libs. Is there any way I can remedy this?

EDIT: Reading around some other Mono AOT-related questions, it appears that this might be how it is supposed to work. I wanted to AOT-compile my app in hopes to reduce the ~2 seconds start-up time, which did not change at all after I switched from JIT to AOT. Can somebody please explain this this to me?

BONUS: Is there any way I can enable advanced optimization flags? (e.g. -o)

Convolution

UPDATE: The Community version of Visual Studio does not support AOT; and, sometime in the past six months, an update to Xamarin explicitly forces it off (if you had manually turned AOT on by editing the csproj file). Now must have Enterprise version to build with AOT. – Melodramatic

Answer 1

AOT'ing your assemblies/code is not going to change the startup of the app's initialization (native app bootstrap + Xamarin/Mono initialization BUT not including any of your code execution time).

Now, if you are doing X amount of work that is CPU bound within your code, say within the OnCreate (which you really should not be doing), you would (should) see a decrease in total time. I say should due to the fact that AOT'ing does not guarantee that you will see a faster execution time of a particular portion of code, it does eliminates the jitter, but there are lots of other factors involved. I've been using Mono (AOT w/ & w/o LLVM) for many years and you really need to instrument and test on your code.

Although the JIT mode is very fast, and the default optimizations in Mono have been tuned to provide a good balance between optimizations and JIT speed, AOT compilation provides a few extra benefits:

• Reduced startup time.

Note: This is particularly useful for large programs that might need to execute a lot of code before they are operational...

• Potential better performance.

Note: ....This means that certain programs might run slower as the generated code is more general than the specific code that the JIT can produce.

Ref: http://www.mono-project.com/docs/advanced/aot/

---

Enable LLVM and AOT for testing your release builds:

In terms of optimization of AOT code, enable LLVM along with AOT in your release builds for performance/instrumentation testing. Note: Testing is key, having a complete app test suite and internal instrumentation for collecting runtime performance is key to getting those 5 stars reviews on the app stores ;-)

---

EnableLLVM

A boolean property that determines whether or not LLVM will be used when Ahead-of-Time compiling assemblines into native code. Support for this property was added in Xamarin.Android 5.1.

This property is False by default.

This property is ignored unless the $(AotAssemblies) MSBuild property is True.

---

AotAssemblies

A boolean property that determines whether or not assemblies will be Ahead-of-Time compiled into native code and included in the .apk. Support for this property was added in Xamarin.Android 5.1.

This property is False by default.

Prehistory

Thank you for the great explanation! Should I assume there is no way to reduce the start-up time, given that Mono cannot be further optimized? Some big apps take around 5 seconds to load (as seen on Google Play) and this is really pulling me back from using Xamarin. I have virtually no code in my OnCreate method. – Convolution

@DoDo AOT/LLVM is not going to help getting to the first initiated screen in a "HelloWorld" (no user code) app any faster... Facts of life as there is an overhead for using the Xamarin/C# eco-system, if your app design is clean, the launch-time difference between a "native" app vs. a Xamarin-Based one should be fairly "small"... now I have seen LOTS of "native" apps that have a horrible user experience in terms of launch-time, view/activity change times, refresh delays, etc... a toolset only does so much, after that it is in the hands of the app developers, for better or worse ;-) – Prehistory

Interesting... so the overhead is going to remain unchanged, even if I scale my app? I will retain a clean OnCreate method with everything happening async after the UI is loaded. But if I add more code and more activities, will the start-up remain the current ~2 seconds, or will it increase to some 5 seconds I see on the market? Also, do you know if using more C# libraries has an impact on that start-up time? I read somewhere that adding more libraries dramatically increases start-up time, and I believe this is where AOT plays a big role. – Convolution

@DoDo I've worked on Xamarin.iOS and Xamarin.Android apps that push 200MB of user code and 2GB of installed content and their "startup time" is really no different than a Xamarin templated "HelloWorld" app. Now if we would start everything we need (GPS updates, physics engine initialization, Play Game leaderboard pulls, etc...) within just the app's startup, yes we would be dead in the water.. but between using Async and our own threadpools smartly and doing a "lazy" startup, the app is in front of the user in a couple of seconds.. – Prehistory

@DoDo So, in the end, this really has little to do with Xamarin, but just app development in general and I would be doing the same code design within Java/C Droid apps and/or ObjC/Swift iOS apps.. – Prehistory

Thank you sir! I will stick to your words and go forward with Xamarin :) – Convolution

@DoDo ;-) I always look at the toolset, dev tooling, language, etc.. as a second, third, last(?) item on the list. The question you should start with is what are your app goals, requirements, platforms,.. then back into those requirements with tooling that achieves those goals with the least amount of compromise, of course taking in real-world factors like if you only have access to C# devs, I would not throw them in front of Xcode/ObjC with a 3 month app ship date ;-). Now, if they/you have NO mobile background, allocate time as mobile is a different world even if you're using a known like C# – Prehistory

I have an error when enabling AOT. "could not aot the assembly" :/ – Regelation

@Regelation Hi. You fixed "could not aot the assembly"? – Barfield

Answer 2

Coincidence or not, when I added <AotAssemblies>True</AotAssemblies> to <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> section of the android .csproj my startup times were reduced from 10 seconds to 4 seconds! Then I removed the AotAssemblies and tried again and I have 10 seconds again, so the AotAssemblies does something :)

Gaptoothed

I did some test and AotAssemblies DOES shorten my app startup time form 5s to 3s. – Lookout

I can confirm this too. AOT improved my app's startup time by atleast 2 seconds. Everything else such as the page navigations, button actions, UI feedback, etc. feels faster too. – Sanalda

In my case the App loads fast but it takes 6 seconds to load the first view (within a page) – Cab