mvvmlight
mvvmlight copied to clipboard
lbugnion
Android Navigation Memory Leak
Hello @lbugnion
I have been working through some performance issues with our MVVM Light app and noticed that the Heap Size seems to forever increase in Android. At first I assumed that this was an issue in our implementation of the MVVM Light architecture, but after doing some testing with the NavigrationDroid.sln, from MVVM Light Navigation Sample I suspect that the issue may lie within the MVVM Light framework.
When debugging the sample application above, the Heap Size starts around 10MB. From there the Heap Size will increase with each click of "Navigate to Page 2 with Parameter" and "Go back to Page 2". I am bench marking these values using the DDMS tool provided with Visual Studio 2015. I also had a colleague verify similar results using a Xamarin profiler with Visual Studio 2017.
Here is the Heap from DDMS when the NavigrationDroid.sln app is first deployed to a Motorola G5 phone.
After clicking through the navigation buttons for 1 minute (roughly 90 clicks) and clicked "Cause GC" within DDMS, here is the Heap:
Next I let the app rest for 1 minute, and proceeded with the same test. I clicked the navigation buttons for 1 minute (roughly 90 clicks) and clicked "Cause GC" within DDMS, here is the heap:
Would you have any idea about what is causing the Heap Size to continue to grow? I have been experimenting with unbinding the click events for each button using the OnStop/OnResume methods in Android but have not had much luck. Any advice or insight into this issue is greatly appreciated!
Thanks,
Bill
@lbugnion any thoughts on this? I am just curious if this is expected behavior or if you've seen it before?
@lbugnion we are continuing to see issues with the memory profile of the app when running Android. The only way we are able to reduce the memory footprint is to explicitly call Finish() after navigating. Are you aware of this issue? Do you have any recommendations on how to better handle memory management in Android / MVVMLight?
Did you solve this issue?
At the time we had thought so, but the root cause remains.
@bstahlman is this specifically to do with navigation causing the memory issues? It could be worth checking if you have dependencies registered which should be transient but aren't that are keeping a lot of data in memory when navigating between views.
