Open RobTF opened 2 months ago
RobTF
commented
2 months ago Eventually, after my walk I've run the app again and again, eventually it just gets far enough to trigger the Android "Wait or Kill" dialog for slow apps. Tapping wait allowed it to run, but this comes up maybe one in 10-15 attempts and you have to catch it quick.
I believe at this stage my employer is considering adding MAUI related mental health cover for the developers!!
jonathanpeppers
commented
2 months ago @RobTF so is the problem that the app takes a long time to launch? Are you doing work on the main, UI thread?
I would consider recording a .speedscope to see what is taking so much time on the UI thread:
It could be your code, but it could also be something else like MAUI or the BCL.
There are 177 [monodroid-assembly] Assembly load messages. @grendello should we actually consider hiding these monodroid-assembly messages when debugging?
grendello
commented
2 months ago @jonathanpeppers they are log_warn, because the assumption is that usually we load assemblies just fine, so it usually isn't a problem. However what's interesting here is that we first log the message and then load the assembly from the override dir, it might be just a case of changing the order of locations we check when debugging. I'll take a look at it this week.
grendello
commented
2 months ago Mono invokes assembly preload hooks in reverse registration order: https://github.com/dotnet/android/blob/07cb311e10d30fe94a29b7804ab01393786958a6/src/native/monodroid/monodroid-glue.cc#L683-L691 so the "load from override dir" hook should be invoked first, and thus we shouldn't see any of the load failure warnings
grendello
commented
2 months ago I don't think the messages themselves cause the ANR, though, it must be something else. Either, as @jonathanpeppers suggested, too much work being done on the main thread (and assembly loading itself wouldn't take that much time, unless there's a very, VERY, big image to load and individual assemblies load in well under a millisecond on a midrange device) or there's a deadlock somewhere which causes the connection to time out.
grendello
commented
2 months ago @RobTF if you don't use Hot Reload, can you try setting the AndroidUseInterpreter MSBuild property to false and see if that improves your performance? Debug builds use the interpreter by default, and interpreter is slow.
Android framework version
net8.0-android
Affected platform version
VS 2022
Description
When launching an app on Android I'm beginning to get this as the app grows;
It takes so long to spin up the app with all the assembly loading stuff the debugger times out.
Apologies in advance for the sarcasm but it's somewhat therapeutic. This sort of thing has plagued the iOS side of things for a while with the watchdog giving up on execution and killing the app before the debugger can latch properly.
Steps to Reproduce
4a. Quietly celebrate as you get one more relatively trouble-free cycle of your > 1 minute long dev loop for some minor code change. -- or -- 4b. Wipe away tears of frustration as useless exception dialog pops up from the depths of the toolchain and yet another mobile development issue raises its head. Try not to look at the clock as it reminds you of the amount of your life you're wasting battling with the tooling.
Did you find any workaround?
Go for a walk and forget about it for half an hour.
Relevant log output