Caliburn.Micro
Caliburn.Micro copied to clipboard
Caliburn-Micro
Attached events and memory profiling
Hi,
I'm doing some memory profiling of my UWP (with a ShellView) app and I discovered that app leaks. I tried to isolate the problem by adding an empty View/VM with below lines in XAML:
<cm:Message.Attach>
[Event SizeChanged] = [OnViewSizeChanged($eventArgs)];
</cm:Message.Attach>
When I navigate to that page and then back to the previous one (and doing so several times, forcing GC after all) both View and ViewModel seem to stay in memory forever (something that references Behaviors/Interaction SDKs keeps references). Removing above lines from XAML and replacing them with standard XAML SizeChanged="ThisPage_SizeChanged" attribute problem is gone.
On the other hand using x:Name attribute for VIew/VM binding seems to work just fine. Only the attached events seem to be the problem.
Any idea what can be wrong?
Thanks, Lukasz
I could confirm this issue. Temporary removed all Message.Attach from views because of that.
Seems like x:Name binding to the Button causes the same issue (RoutedEnevtHandler seems to remain there forever and it is kinda random.. 1-2 buttons seems alright but adding more makes GC completely freak out). Doesn't make any sense :D
BTW is it actually a good idea to keep Behaviors SDK reference in CM? This break the entire .Net native compiler and prevents good optimization. Wasn't that the whole reason why Behavios are removed from UWP?
EDIT: x:Name binding in TextBlock adds +1 to refcount of the VM (View can be collected though). Seems like I have to roll back to x:Bind / Binding in XAML instead.
Thanks for the info. Can you rerun your tests but against a build of the UWP Behaviours SDK from source. There was a bug Microsoft/XamlBehaviors#55 that caused EventTriggerBehavior to not detach from the event correctly. I'm wondering if this is part of the problem.
Regarding using the Behaviors SDK. Caliburn.Micro has been built on to of behaviors from the beginning (something like 2009). Removing them now would be awkward to say the least.
Surprised about the view model reference count being added to by the TextBlock binding this should simply be adding a Text="{Binding PropertyName, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" to the control. Can you verify in your tests that replacing the x:Name with the above doesn't add to the reference count?
I'll take a look at it when I get back from work. Anyways it feels like the problem is much more complex than that. It feels like the main cause could be somewhere in the INavigationService implementation. Having just a simple Binding causes memory profiler mark View/VM as "Cycle Detected". I do not store VM/View as properties anywhere so it much be the "Screen" + "FrameAdapter" implementation doing something funny.
If the view model is IViewAware it will hold a weak reference to the view. Also if you're using CachingFrameAdapater then naturally this hold a reference to the view model.
Not using a CachingFrameAdapater and weak reference should be removed when forcing GC
Excellent, just wanted to document all assumptions, I probably won't be able to dig into this till the weekend.
@winnie1pooh it was announced to be released soon http://compiledexperience.com/blog/posts/behaviors-1.1.0
No progress on this specific issue, happy to take some help from people with experience in this.
In terms of the 3.0.0 release, plan was for yesterday, but was passed word of a potential UWP bug, so holding off till I get a repro of it,
Do we know if this problem has been fixed or if there is any workaround that helps mitigate the number of RoutedEventHandlers being held onto?
There hasn't been anything done for this specific issue, happy to take any help offered here.
Hello, is there any fix or a work around for this issue yet? I'm running into a similar problem.
