最近工作中常常被問到如何降低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<object> Collection = new ObservableCollection<object>(); } 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
如有任何疑問，歡迎留言給我。