Windows Phone 8内存控制研究 之 LonglistSelector使用陷阱

amy_888

　　最近工作中常常被问到如何降低WP内存使用，便再一次开始研究内存问题，首先发现了LonglistSelector使用的一个常见问题：

概述
　　若将Longlistselector 控件的ItemsSource设置为ViewModel中的一个ObservableCollection集合，那么应该值得注意内存问题。
　　

问题的产生
　　下面的demo中，模拟了如下场景ItemSource Binding到了Page以外的静态ObservableCollection上。那么如果我们的程序结构如果是
　　MainPage->LoginPage 的话，来回在MainPage和LoginPage间切换就会导致内存中有多个LoginPage不能被释



namespace Feinno.Beside.View.Pages
{
public class BindingSource
{
public static ObservableCollection Collection =
new ObservableCollection();
}
public partial class LoginPage : PhoneApplicationPage
{
public LoginPage()
{
InitializeComponent ();
　　　　　　　//List 为xaml中定义的Longlistselector
list .ItemsSource = BindingSource.Collection;            

Debug .WriteLine("Initialze page!! hashcode = " + GetHashCode());
}
         ~LoginPage()
{
Debug .WriteLine("Uninitialze page!! hashcode = " + GetHashCode());
}
}
}   
　　正常状态(无内存问题）的打印如下：　　　　　　　　　　　　　而上面代码的打印如下：
　　page可以及时销毁。
                             
　　
　　可以看出，在来回切换页面的时候，之前的页面并没有得到释放，而是一只在内存中。

产生原因
　　笔者尝试使用Listbox来执行同样的代码，并不会出现上述问题，所以分析感觉是Windows Phone 8 新增的Longlistselector有问题，
　　具体原因是因为ObservableCollection 对外会暴露CollectionChanged接口将LonglistSelector的ItemSource赋值为ObservableCollection的时候，LonglistSelector通过此接口来监听列表中集合的改变，由于使用的是强事件，那么ObservableCollection中将会持有对LonglistSelector的引用，如此便导致离开页面之后，GC回收资源的时候，认为LoginPage仍在使用中，从而导致我们不希望看到的结果。
　　
　　
　　解决办法   
　　当存在上述类似场景的Itemsource设定时，在页面离开时将Itemsource设为null
　　

深入分析
　　如此说来若Page中的控件Binding到代码中的Binding Source会如何呢？
　　通过写Demo分析以及查阅相关资料，笔者得出一下结论：
　　1、LonglistSelector.ItemSource（ListBox无此问题）如果Binding到ObservableCollection，结果和上文中一致，Page无法释放。
　　2、其他属性的Binding 不会导致上述问题。
　　
　　对结论的理论支持：
　　查阅资料笔者了解到，Binding机制内部实现了叫做WeakEventManager的机制，因此Binding监听属性变更，同Event机制存在差异。若控件A Binding到VM中的属性B上，当GC准备回收A 的时候，不会认为A 存在引用。
　　
　　参考：
　　Weak Event Patterns：http://msdn.microsoft.com/en-us/library/aa970850.aspx
　　Do WPF controls use weak events in their bindings?
　　
　　关于WP的交流欢迎加入QQ群：182659848
　　
　　如有任何疑问，欢迎留言给我。