MAUI very slow on physical android devices #18838
Comments
samhouts
added
the
migration-compatibility
|
For me it is also very slow without any prints like reporter has here, on Android 12. I migrated (manually = creating the same app by moving pieces of code and rewriting renderers into handlers etc) an app from Xamarin and it is very slow on device. In DEBUG. In RELEASE everything is ok. |
|
I can confirm I am getting these messages all the time in debug. Common ones include (but not limited to):
That last one happens VERY often as it's triggered by getting the main display DPI in a looped animation (at Microsoft.Maui.Devices.DeviceDisplayImplementationBase.get_MainDisplayInfo()). It makes it nearly impossible to find debug messages in the console. Edit: Thought I should add, it appears to be device specific: My TCL 30XE running Android 12 does not have this problem, but my Samsung A13 running Android 13 excretes this issue like sweat in a texas summer. Edit 2: Nvm, my TCL now has these issues... |
|
Having the same problem. Any news to this? |
|
Same here. |
|
Forcing xaml compilation results in same performance as Xamarin Forms in our side in Debug. (Breaks Xaml Hot Reload for the moment) |
|
Also from our end there is a major difference in which physical Android devices are about 5 times slower than Android emulators AND iOS physical devices. This is a critical problem that does not seem to be on the radar at all. Who should we contact to escalate this further? |
|
I'm having trouble with this as well. |
|
@clintcambier @QiteSimon Did you try solution in the post above yours? Adding this for DEBUG should solve slowness |
|
The performance while debugging is acceptable (slower yes, but ok). |
|
The same problem exists. |
Same here but to a lesser degree on iOS as it's definitely not as snappy as Xamarin.Forms on iOS. Our project on Xamarin.Forms in Android is much more performant yet Xamarin.Forms support is End of Life in 5 days. Menu drawer closing while navigating is supper laggy as well as everything else so much so that we can't even develop properly. Again, these issues are also apparent in Release mode and we can't release to production with these serious performance issues. They exist in our app in debug and release in MAUI but not Xamarin.Forms. Microsoft needs to extend Xamarin.Forms support until MAUI is stable and performant as the product they intend to be replacing. |
|
Fully agree that support should be extended... Any update about that?
Op vr 26 apr. 2024 18:08 schreef mnxamdev ***@***.***>:
… I'm having trouble with this as well. My app, which was migrated from
Xamarin, is MUCH slower in MAUI than in Xamarin. At least it is on Android.
iOS seems to be running just fine.
Same here but to a lesser degree on iOS as it's definitely not as snappy
as Xamarin.Forms on iOS. Our project on Xamarin.Forms in Android is much
more performant yet Xamarin.Forms support is End of Life in 5 days. Menu
drawer closing while navigating is supper laggy as well as everything else
so much so that we can't even develop properly. Again, these issues are
also apparent in Release mode and we can't release to production with these
serious performance issues. They exist in our app in debug and release in
MAUI but not Xamarin.Forms. Microsoft needs to extend Xamarin.Forms support
until MAUI is stable and performant as the product they intend to be
replacing.
—
Reply to this email directly, view it on GitHub
<#18838 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB32IPUDSJ4GAS2QPIZXAVLY7J3YDAVCNFSM6AAAAAA7PZDY3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZZGY4DGOJXHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@mnxamdev, my advice: I know that can be time consuming but you should create small projects to isolate each problem that you suspect. I personnaly don't use "Menu Drawer" for instance. |
Zhanglirong-Winnie
added
s/verified
|
Verified this issue with Visual Studio 17.10 Preview 5 (8.0.21&8.0.3). Can repro on android device platform. |
|
Can you attach a logcat file? You can also grab a speedscope to see if that reveals anything |
Eilon
added
the
t/perf
PureWeen
added
the
area-infrastructure
|
@jonathanpeppers thoughts? |
|
A solution would be great, not only makes it the app slower but also produces an unreadable debug window. I'm using many settings through the Preferences, so my debug window is completely filled with these messages:
|
|
The Simply enabling log messages like these will make the app slower. |
|
Thanks @jonathanpeppers that worked perfect! |
|
My app was working well in .net 7.0 preview, but after upgrading it to .net 8.0, the app got slow on Android. |
|
@wagaana did you profile your app? If you could share a sample project or I don't know of any performance regression going from .NET 7 to .NET 8. |
|
Any news here? Have same problem, in emulator is ok, but on physical android device unusable |
This sounds backwards to me: my experience is that something like even a Pixel 5 (few years old) is faster than an emulator. If someone is able to review https://aka.ms/profile-maui and share |
dotnet-policy-service
bot
added
the
s/no-recent-activity
|
Same here, since I migrated my project from Xamarin.Forms to MAUI, I've noticed a big drop in productivity. Despite the fact that MAUI was relased two years ago, it feels a very beta (almost alpha) version of the product that Microsoft promised. Is two, three or four steps behind the obsolete version of Xamarin.Forms. |
dotnet-policy-service
bot
added
s/needs-attention
|
Also experiencing the same issue, Android version of our app is extremely laggy and will give our customers very bad experience and not good for the companies reputation. |
|
Solved replacing autommaper with mapster
El vie, 18 oct 2024, 10:23, Dijon Smit ***@***.***> escribió:
… Also experiencing the same issue, Android version of our app is extremely
laggy and will give our customers very bad experience and not good for the
companies reputation.
—
Reply to this email directly, view it on GitHub
<#18838 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACD5QNWNYQOZZY7JZBLG5ZDZ4DAR3AVCNFSM6AAAAAA7PZDY3OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRRHAYTANJTGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Same issue here. CollectionView click can take something like half a second if not more to register on Android ( Pixel 7 so not exactly a slow device ). IOS, Windows, Mac are all fine. |
I'm confused by this comment, as clicking should not do anything. It has 1 Java -> C# transition, and allocates a |
I'll run a speed scan when I get change ( probably later this week due to a deadline ). when running in release mode it's a lot better but still feels a little sluggish. in debug mode it takes a good chunk of time to register the click, even to the point of showing the android ripple effect. |
|
I also am experiencing this. I have done a speed scope file of just a simple button click. It loads a screen that has 12 buttons on it. They are not actual buttons, but are custom controls. It takes it about 4 or 5 seconds to load the buttons (removed xaml from the equation and load the buttons via code), then spends another 5 seconds in Microsoft.Maui.Controls!Microsoft.Maui.Controls.Element.SetHandler. |
|
@jlinkerlathem can you share the file? |
|
@jonathanpeppers Sure, this one i removed 9 of the buttons. So, I tap a button, it loads a page with three buttons. It reduced the rendering of the page to 2 or 3 seconds, but the SetHandler code still high. But even reduced, three buttons shouldn't take 3 seconds to render (not saying I am not doing something stupid, but, this code worked fine in Xamarin)dotnet-dsrouter.exe_20241031_125557.speedscope.json Forgot to mention, in the speed scope file, the thread in question is the 24th one, -1465793228 |
|
To be clear, we aren't saying button clicks are slow. We are saying navigation to new screens are slow? In your app, there are a few things that you could improve:
There is a lot of interesting things in here, in general, though. Thanks! |
|
Yes, it is the navigation I am referring to.
Glad you see interesting things. If you see anything else useful let me know. I will swap out the remaining LathemButtons for the LathemSound ones, disable the UpdateNetworkConnectivityStatus(), and remove Mr.Gestures and see what affect that has, if I still see the issue I will submit another speed scope file |
|
If you know what method to look for, use the Sandwich view, search box, and then the call stack should show who called it:
|
|
@jonathanpeppers Well, that would be why I couldn't figure out how to search, mine does not have a search icon there...
And now I see that the normal ctrl+f instead of bringing up Chrome's Search box, adds a search box to speed scope insert face palm here |
|
@jonathanpeppers Ok, I removed Mr. Gestures. Also removed the UpdateNetworkConnectivityStatus() call. I also moved all of the custom controls involved out of XAML and to be created in C#. I thought it had sped it up one of the times I ran it, but I must have done something wrong as I am still getting slow times. I have attached the latest Speed Scope file. It seems to me the LathemSoundButton is the issue. But I cannot figure out why. As mentioned, I am building it in code. Its a Border, with a RoundRectangle (with two data triggers), then a Grid (with a TapGestureRecognizer (handles the bound command), and a TouchBehavior (handles swapping the image source to a "pressed" state image if an image has been added) attached), and then an Image and a Label in the grid (each with some bindings). I could see the button being too bulky being the the issue if the problem was worse with more buttons, but it seems even one button on the screen kills it. Any more thoughts? |
|
If I have an example here, but maybe the control can override In this example, a new Reviewing your logs, I also see how fixing this would help: So, I'm looking into it. |
|
@jonathanpeppers Hmmm, that could work with this particular control as I do not think the values change after initialization. I guess what confuses me though is what is so different between Maui's handling of this (bindings, xaml creation/parsing, whatever else is involved here) that would make it take so vastly different an amount of time as it did from Xamarin? I will try the without binding option, but I am worried it will have a negligible affect. Will let you know what I find. I will be starting on testing a release of our software on Monday, so if I have not responded by then it may be a few days before I can circle back. |
|
@jonathanpeppers Also, before I forget, I want to express my genuine appreciation for your persistent assistance in tracking this down |
|
@jonathanpeppers I don't think it is the bindings. Just to see I removed all of the bindings, DataTriggers, Behaviors, the only thing I left was the TapGestureRecognizer to be able to tap on a button and navigate, and the Text Property. I removed EVERYTHING else, and it still takes the same amount of time... I am running out of ideas as everything I have tried has had no affect on it. Like, not even a little. I would at least expect these changes to be speeding it up a little here and a little there. It takes it about 10 seconds from the time I tap the button until the next page loads, and that time has remained consistent through every change I have made.... |
|
I switched LathemSoundButton to be just a normal button instead of a content view. Loses my functionality but for testing purposes helps narrow something down. It did speed it up a little. UI creation went from about 3 or so seconds down to 2.25, but there is still a 4 second section of it doing the LayoutHandlers. I will say with the Button instead of Content View, it does load fast the second time you call the page (about 6.5 seconds as opposed to 8, where as with the Content View button it did not speed up after the first time). I think I have stared at this too long now though... |
|
@jlinkerlathem how many controls are on the page you are testing? Is it in the hundreds? (The joke is you should have less views than pixels on the screen) Also keep in mind the numbers you see in |
|
@jonathanpeppers Visually there are less than 20 items on the screen, 12 buttons, a text box, a title bar with a label and a back button, and then a status bar at the top with the time. There may be a few more objects as containers for those objects, but its not a list or anything like that. Just a grid. I have ran it in release mode to verify the instrumentation was not the culprit and it still takes the same amount of time to laod the page. As I mentioned, for the next few days I will be on release testing another app, once that is complete I am going to flatten the UI for this page and see what that does. Currently its a ContentPage that is loaded into a BaseContentPage (has the title bar and status bar that is shared by all of the pages), then it loads a Custom Control (a NumberPad) which has 12 of the LathemSoundButtons on it. I am going to flatten that so there is no base page, just all of the stuff on one page, and the number pad code will reside in the parent page and the buttons will be copied on the page and see if that speeds it up. If it does then I will separate things back out one at a time until I hit the issue, and go from there. I will try to update when I get to that point to help others, or if it doesn't solve it when I flatten it I will post another speed scope file. |
I have tried running a speed test this afternoon and its having some issues running. when I run dotnet-trace collect -p 21001 --format speedscope it crashes. No profile or providers specified, defaulting to trace profile 'cpu-sampling' Provider Name Keywords Level Enabled By [ERROR] System.IO.EndOfStreamException: Unable to read beyond the end of the stream. I'll try again tomorrow |
and others
Description
MAUI Android runs very well on emulators, but on physical devices, both debug and release it runs very slow. I believe its due to an error that gets throw due to a variety of reasons, that gets worse the more content a project has. I'm our current project just switching to another page can take up to 10 or so seconds, on a new MAUI project it isn't noticeable, but its there still. This did not use to take that long i Xamarin. Its unusable with that much delay on pretty much everything.
The errors always look something similar to this:
[monodroid-assembly] typemap: unable to find mapping to a managed type from Java type 'androidx/fragment/app/FragmentManagerImpl' [monodroid-assembly] typemap: called from [monodroid-assembly] at Java.Interop.TypeManager.GetJavaToManagedType(String class_name) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Interop/TypeManager.cs:line 228 [monodroid-assembly] at Java.Interop.TypeManager.CreateInstance(IntPtr handle, JniHandleOwnership transfer, Type targetType) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Interop/TypeManager.cs:line 274 [monodroid-assembly] at Java.Lang.Object.GetObject(IntPtr handle, JniHandleOwnership transfer, Type type) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:line 303 [monodroid-assembly] at Java.Lang.Object._GetObject[FragIt can be reproduced in a completely new and untouched MAUI project too:
[monodroid-assembly] typemap: unable to find mapping to a managed type from Java type 'com/android/internal/policy/PhoneLayoutInflater' [monodroid-assembly] typemap: called from [monodroid-assembly] at Java.Interop.TypeManager.GetJavaToManagedType(String class_name) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Interop/TypeManager.cs:line 230 [monodroid-assembly] at Java.Interop.TypeManager.CreateInstance(IntPtr handle, JniHandleOwnership transfer, Type targetType) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Interop/TypeManager.cs:line 274 [monodroid-assembly] at Java.Lang.Object.GetObject(IntPtr handle, JniHandleOwnership transfer, Type type) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:line 304 [monodroid-assembly] at Java.Lang.Object._GetObject[LayoutInflater](IntPtr handle, JniHandleOwnership transfer) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:line 290 [monodroid-assembly] at Java.Lang.Object.GetObject[LayoutInflater](IntPtr handle, JniHandleOwnership transfer) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:line 281 [monodroid-assembly] at AndroidX.Fragment.App.Fragment.n_OnCreateView_Landroid_view_LayoutInflater_Landroid_view_ViewGroup_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_inflater, IntPtr native_container, IntPtr native_savedInstanceState) in /Users/runner/work/1/s/generated/androidx.fragment.fragment/obj/Release/net6.0-android/generated/src/AndroidX.Fragment.App.Fragment.cs:line 2028 [monodroid-assembly] at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PPLLL_L(_JniMarshal_PPLLL_L callback, IntPtr jnienv, IntPtr klazz, IntPtr p0, IntPtr p1, IntPtr p2) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Android.Runtime/JNINativeWrapper.g.cs:line 352 [monodroid-assembly] typemap: unable to find mapping to a managed type from Java type 'androidx/fragment/app/FragmentManagerImpl' [monodroid-assembly] typemap: called from [monodroid-assembly] at Java.Interop.TypeManager.GetJavaToManagedType(String class_name) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Interop/TypeManager.cs:line 230 [monodroid-assembly] at Java.Interop.TypeManager.CreateInstance(IntPtr handle, JniHandleOwnership transfer, Type targetType) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Interop/TypeManager.cs:line 274 [monodroid-assembly] at Java.Lang.Object.GetObject(IntPtr handle, JniHandleOwnership transfer, Type type) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:line 304 [monodroid-assembly] at Java.Lang.Object._GetObject[FragmentManager](IntPtr handle, JniHandleOwnership transfer) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:line 290 [monodroid-assembly] at Java.Lang.Object.GetObject[FragmentManager](IntPtr handle, JniHandleOwnership transfer) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Java.Lang/Object.cs:line 281 [monodroid-assembly] at AndroidX.Fragment.App.Fragment.get_ChildFragmentManager() in /Users/runner/work/1/s/generated/androidx.fragment.fragment/obj/Release/net6.0-android/generated/src/AndroidX.Fragment.App.Fragment.cs:line 416 [monodroid-assembly] at Microsoft.Maui.Controls.Platform.Compatibility.ShellFragmentContainer.OnCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) in D:\a\_work\1\s\src\Controls\src\Core\Compatibility\Handlers\Shell\Android\ShellFragmentContainer.cs:line 48 [monodroid-assembly] at AndroidX.Fragment.App.Fragment.n_OnCreateView_Landroid_view_LayoutInflater_Landroid_view_ViewGroup_Landroid_os_Bundle_(IntPtr jnienv, IntPtr native__this, IntPtr native_inflater, IntPtr native_container, IntPtr native_savedInstanceState) in /Users/runner/work/1/s/generated/androidx.fragment.fragment/obj/Release/net6.0-android/generated/src/AndroidX.Fragment.App.Fragment.cs:line 2031 [monodroid-assembly] at Android.Runtime.JNINativeWrapper.Wrap_JniMarshal_PPLLL_L(_JniMarshal_PPLLL_L callback, IntPtr jnienv, IntPtr klazz, IntPtr p0, IntPtr p1, IntPtr p2) in /Users/runner/work/1/s/xamarin-android/src/Mono.Android/Android.Runtime/JNINativeWrapper.g.cs:line 352 [Mono] Running class .cctor for Microsoft.Maui.Handlers.PageHandler from '/data/data/com.companyname.mauiapp3test/files/.__override__/Microsoft.Maui.dll' [Mono] Running class .cctor for Microsoft.Maui.Handlers.ContentViewHandler from '/data/data/com.companyname.mauiapp3test/files/.__override__/Microsoft.Maui.dll'Steps to Reproduce
Link to public reproduction project repository
No response
Version with bug
8.0.3
Is this a regression from previous behavior?
Yes, this used to work in Xamarin.Forms
Last version that worked well
Unknown/Other
Affected platforms
Android
Affected platform versions
Android 12 and up at least.
Did you find any workaround?
We have not been able to find a workaround.
Relevant log output
The text was updated successfully, but these errors were encountered: