Windows Phone 8記憶體控制研究：LonglistSelector使用陷阱

最近工作中常常被問到如何降低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可以及時銷毀。

 

可以看出，在來回切換頁面的時候，之前的頁面並沒有得到釋放，而是一隻在記憶體中。

查看本欄目更多精彩內容：http://www.bianceng.cnhttp://www.bianceng.cn/OS/extra/

產生原因

筆者嘗試使用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 不會導致上述問題。