最近工作中常常被问到如何降低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 不会导致上述问题。
以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索内存
, 问题
, 页面
, binding
, public
bindingsource
windowsphone、windows phone 10、windows phone官网、windows、windows 应用商店,以便于您获取更多的相关知识。