Android performance

[baskren]

TLDR: XMLVM as a way to improve UIElement rendering and layout performance?

First, thank you for tolerating someone who knows just enough to be dangerous. Greatly appreciated. Second, knowing how good of a job you've done with the entire framework, I'm guessing you've not only thought about this already but have benchmarked it and understand it quantitatively.

Your recent roadmap survey got me thinking (once again) about the one issue I have with Xamarin.Forms, MAUI, and UNO frameworks - Android performance. For some of my apps, none of them are good enough. They're all not so great (UNO has proven to be better than the others) as there's a significant amount of time devoted to loading the .NET framework files (resulting in more launch time) and time in rendering and layout out UI objects. If my understanding is correct, both of these come from the same root cause - the cost of switching back and forth between the JVM and the CLR. Again, I might be all wrong about this.

Over the years, I've benchmarked a bunch of proof of concept apps and I've found that:

1. Running a Xamarin.Android UI + .NET business logic is so close to as fast as a native Java app that's practically a wash.
2. Added custom rendering logic (so that Android View or ViewGroup layout is handled in C# code) has a negative performance impact.
3. Lazy loading can sometimes delay (and break into small chunks) the loading of needed .NET dlls - which seem to be a big impact on Android load times.

I've very familiar with performance guides like Uno.UI - Performance and frequently return to them with the hope of new developments. And, hopefully, there are still some things I'm not aware of that I should be doing to mitigate the issues I'm having. As always, if you have any suggestions, I'm all ears.

So here's my question: Would it be viable or beneficial to migrate the UNO UI code from CLR executables to JVM executables? I'm guessing, that's not a trivial endeavor. Which makes me ask if it's possible via a tool like XMLVM? The overall intent here is to get rid of the JVM->CLR->JVM tax. If it were possible, this would still mean that the current .NET->Android class & method PInvoke bridges would have to be removed and new, Uno UI, class & method method PInvoke bridges would have to be created between Uno UI code and the developer's code.

Again, I'm guessing you've already looked at this so what I'm actually asking is how bad is such an idea: what are the major obstacles and, if they're surmountable, is the sub-optimal byte code that is produced just as bad as the JVM -> CLR -> JVM tax?

Thank you again for your patience with me and I won't be offended if you just ignore this question.

[jeromelaban]

This kind of migration is not something Uno will do, it's work that can only be done by the .NET runtime team.

What you're talking about is the interop cost, which is currently high for a variety of reasons. One is the JNI, which is improved significantly in Android 13, so we'd need to reevaluate performance there, be the other one is the code and .NET's interop itself, which is very expensive. There's still a lot of reflection happening (like dotnet/android#7479) and this is slowing down app's performance significantly. P/Invoke bridging is not something we can use either at this time, because we'd still need to use the JNI, basically leaving the interop work to do that .NET Android is already doing.

Now another way of reducing the interop cost is not doing interop at all (or very significantly less), using Canvas-based rendering, but this has its own set of restriction (such as IME or native controls use). We're not there yet.

[baskren]

Thanks, Jerome. As usual, you're very knowledgeable about this and willing to share your insights.

[baskren]

Thanks again for the insight. FWIW: Looks like Uno app launch time is almost cut in half when comparing Android 11 to Android 13. Still about 3x off .NET6-Android native UI.

[jeromelaban]

Thanks. Are you testing with AOT ?

[baskren]

I wasn't so I went back and redid with AOT. Went from 2.86s average (of ten launches) to 2.16s average on an API 31 Emulator. Similar results on the API 33 Emulator. But, now I can't reproduce my original 5+ second average launch times in my original testing. Hmmm.