博客园_dinghao

Silverlight内存泄露（八）样式

2011-04-18T05:28:00Z

同一个程序，换一个主题、换一个样式，可能造成内存泄露。

演示Sytle引起的内存泄露

这一系列写到八了，将要结束，还没有一个直观例子说不过去，样式发生内存问题最难找也最隐蔽，做了小例子说明内存泄露问题。

例子下载：

MemoryLeak.rar

例子中ProgressBar样式引起内存泄露，为直观每次导航分配50M内存。

a) 继续使用ANTS检测内存问题，但ANTS属于收费软件

b) 也可使用免费的进程浏览器，启动 Process Explorer.，在sllauncher.exe进程右击，选择属性，在Home、About间导航。

每次导航内存增加50M

注释掉ProgressBar样式后，内存不增加。

查找内存泄露

给程序更换样式后发现，View不能释放，没导航内存都增加一个View实例。查看其中一个内存关系图，如下：

可看到某个动画的引用不能释放。造成View不能释放

ProgressBar样式造成内存泄露

产生内存泄露的样式：

<Style TargetType="ProgressBar">
<Setter Property="BorderThickness" Value="2"/>
<Setter Property="Maximum" Value="100" />
<Setter Property="IsTabStop" Value="False"/>
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="ProgressBar">
<Grid x:Name="Root">
<VisualStateManager.VisualStateGroups>
<VisualStateGroup x:Name="CommonStates">
<VisualState x:Name="Determinate"/>
<VisualState x:Name="Indeterminate">
<Storyboard>
<ObjectAnimationUsingKeyFrames BeginTime="0"
Storyboard.TargetName="ProgressBarRootGrid"
Storyboard.TargetProperty="Visibility">
<DiscreteObjectKeyFrame KeyTime="0" Value="Collapsed"/>
</ObjectAnimationUsingKeyFrames>
<ObjectAnimationUsingKeyFrames BeginTime="0"
Storyboard.TargetName="ProgressBarIndeterminateRootGrid"
Storyboard.TargetProperty="Visibility">
<DiscreteObjectKeyFrame KeyTime="0" Value="Visible"/>
</ObjectAnimationUsingKeyFrames>
<DoubleAnimation Storyboard.TargetName="tr" Storyboard.TargetProperty="X"
Duration="0:0:2" To="0.8" AutoReverse="True" RepeatBehavior="Forever">
<DoubleAnimation.EasingFunction>
<QuadraticEase EasingMode="EaseInOut" />
</DoubleAnimation.EasingFunction>
</DoubleAnimation>
<ObjectAnimationUsingKeyFrames Storyboard.TargetName="gs2" Storyboard.TargetProperty="Offset"
BeginTime="0:0:0" Duration="0:0:4"
RepeatBehavior="Forever">
<DiscreteObjectKeyFrame KeyTime="0:0:0" Value="0.1"/>
<DiscreteObjectKeyFrame KeyTime="0:0:2" Value="0"/>
</ObjectAnimationUsingKeyFrames>
<ObjectAnimationUsingKeyFrames Storyboard.TargetName="gs3" Storyboard.TargetProperty="Offset"
BeginTime="0:0:0" Duration="0:0:4"
RepeatBehavior="Forever">
<DiscreteObjectKeyFrame KeyTime="0:0:0" Value="0.2"/>
<DiscreteObjectKeyFrame KeyTime="0:0:2" Value="0.1"/>
</ObjectAnimationUsingKeyFrames>
</Storyboard>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>
<Border x:Name="ProgressBarTrack" CornerRadius="4"
Background="{TemplateBinding Background}"
BorderThickness="{TemplateBinding BorderThickness}"
BorderBrush="{TemplateBinding BorderBrush}" />
<Grid x:Name="ProgressBarRootGrid" >
<Rectangle HorizontalAlignment="Left" x:Name="ProgressBarIndicator"
Margin="3" RadiusX="3" RadiusY="3"
Fill="{TemplateBinding Foreground}"/>
</Grid>
<Grid x:Name="ProgressBarIndeterminateRootGrid" Visibility="Collapsed">
<Rectangle Margin="3" RadiusX="3" RadiusY="3" >
<Rectangle.Fill>
<LinearGradientBrush StartPoint="0 0.5" EndPoint="1 0.5">
<LinearGradientBrush.RelativeTransform>
<TranslateTransform x:Name="tr" X="0"/>
</LinearGradientBrush.RelativeTransform>
<GradientStop x:Name="gs0" Offset="0" Color="Transparent"/>
<GradientStop x:Name="gs1" Offset="0" Color="Transparent"/>
<GradientStop x:Name="gs2" Offset="0" Color="#CCCCFF"/>
<GradientStop x:Name="gs3" Offset="0.2" Color="#CCCCFF"/>
<GradientStop x:Name="gs4" Offset="0.2" Color="Transparent"/>
<GradientStop x:Name="gs5" Offset="1" Color="Transparent"/>
</LinearGradientBrush>
</Rectangle.Fill>
</Rectangle>
</Grid>
</Grid>
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>

结论

a) 估计是Silverlight4bug，silverlight5没测试。

b) 慎用第三方样式

安装Silverlight5的问题

Silverlight5安装不上，有知道怎么解决下面问题的请回复。

本文链接

Silverlight内存泄露（七）Command

2011-04-17T08:06:00Z

MVVM中View与ViewModel是强引用的双向关联关系，容易发生内存泄露，任何一方没有被回收都会导致另一方不能被GC回收。

Comand连接了View与ViewModel，容易产生内存泄露。

发现内存泄露

在几个View间导航几次，两次导航到View页面，获取内存快照，发现Info有两个实例。内存没有被释放。

为了每次导航到消息页面，都保存上一次显示的信息，InfoViewModel采用了单例模式，作为缓存，InfoViewModel只有一个实例，按照设想Info也应该只有一个实例。

代码：

var lazyViewModelMapping= LazyViewModelExports.FirstOrDefault(o => o.Metadata.Key.Equals(relativeUri.Host, StringComparison.OrdinalIgnoreCase));

viewModel = lazyViewModelMapping.Value;

var viewFactory = viewMapping.CreateExport();

view = viewFactory.Value as Control;

viewFactory.Dispose();//释放View内存

view.DataContext = viewModel;

是什么原因造成viewFactory.Dispose();没有释放View的内存呢？

确定泄露原因

看下面两张Info图：

正常图：

发生泄露图：View是当前页面：

发生泄露图：View不是当前页面：

可看出stopDownloadCommand在View与ViewModel间建立了强引用关系，遇到ViewModel这个单例模式（生存期与应用程序一样）造成View不能被回收。

解决内存泄露

断开stopDownloadCommand内存得到释放，从上图可看出断开这个command并没有从根本解决问题，增加其他Command仍会产生问题。

根本原因是ViewModel在此不应该使用单例模式，Lazy创建了单例，而应该缓存Modle。

弹出窗口是最好的方式，由于Silverlight4不支持子窗口，在此使用单例作为缓存，没想到造成View不能被释放。

总结

a) 绑定View的类（如VM），使用单例或缓存VM需要谨慎。VM的长生命周期将导致View不能被释放，并且每次导航到View，View的实例数都将增加。

b) 从内存角度看单例，单例中的Command、Event非常容易造成内存泄露，根源往往是单例而不是事件或command。

c)ANTS 展现的内存图并不全面，经常需要多张图结合看问题。比如，当View是当前页面时，不能看出Lazy<T>产生的问题，而需要跳转到View不是当前页面再看另外的快照。

d)ANTS 的快照图，对一类引用进行了归类，比如stopDownloadCommand并不是ViewModle中唯一的Command，还有reDownloadCommand也引用了View，图上并没有表现出来，在代码中修正了stopDownloadCommand的引用问题，View仍被reDownloadCommand引用而不能释放。

本文链接

Silverlight内存泄露（六）MEF等Ioc框架引起内存泄露-ExportLifetimeContext

2011-04-15T06:06:00Z

对象的创建可以使用new，也可以使用IOC架如：castle、MEF等，IOC创建的对象的生命周期，可能IOC负责管理，使用框架的开发者如果不弄清楚可能会造成内存泄露问题。

这些内存泄露问题并不是IOC框架的bug，只是开发者使用不当或者不注意造成的内存泄露问题。

以MEF为例说明我碰到的两种内存泄露问题。

内存泄露系列阅读提示：

一摸一样的对象图，有时候我们可以认为它是内存泄露，有时候又认为它不是内存泄露，这一切只是由于上下文不同，这一系列文章中ANTS Memoery Profle截图都是有特定上下文，单独看完全没有意义。如何确定是内存泄露？可以参考前面的文章。

对象以图的形式存在，Ants Memory Profile为了分析方便把这些图处理为树，让我们可以把注意力集中到分析的对象。但我们必须明白内存中对象关系构成图，也就是说ANTS的树状图只是内存中对象分布的一个局部，分析内存泄露时必须有全局观念，需要相关的几张图一起看，即使一张图也要整体看，这样才能分析内存泄露问题。

由于看一张图没什么意义，如果把多张图都贴出来，这文章就太难写了，即使多张图都贴出来，也不一定能表达清楚，分析内存泄露最重要的是经验。接下来的几篇会减少甚至不用ANTS图。

ExportLifetimeContext使用不当造成内存泄露

ExportLifetimeContext 需要调用Dispose方法释放由MEF管理的对象，否则对象不会被释放。

MSDN:

Disposing of a ExportLifetimeContext(Of T) object calls the referenced method to release its associated export.

Call Dispose when you are finished using the ExportLifetimeContext(Of T). The Dispose method leaves the ExportLifetimeContext(Of T) in an unusable state. After calling Dispose, you must release all references to the ExportLifetimeContext(Of T) so the garbage collector can reclaim the memory that theExportLifetimeContext(Of T) was occupying.

可以看到ViewModel存在多个实例，可能出现了内存泄露。

经过分析找出发生内存泄露的对象图：

可以看到MEF的DisposableReflectionComposablePart一直保持着ViewModel的引用，造成不能释放ViewModel。

MVVM使用自定义导航，代码：

[Export]
public class CompositionNavigationContentLoader : INavigationContentLoader
{
public CompositionNavigationContentLoader()
{
}
[ImportMany(typeof(IView))]
public IEnumerable<ExportFactory<IView, IViewMetadata>> ViewExports { get; set; }
[ImportMany(typeof(IViewModel),RequiredCreationPolicy = CreationPolicy.Any)]
public List<ExportFactory<IViewModel, IViewModelMetadata>> ViewModelExports { get; set; }
[ImportMany("lazy", typeof(IViewModel), RequiredCreationPolicy = CreationPolicy.Any)]
public List<Lazy<IViewModel, IViewModelMetadata>> LazyViewModelExports { get; set; }
public IAsyncResult BeginLoad(Uri targetUri, Uri currentUri, AsyncCallback userCallback, object asyncState)
{
var viewModelMapping = ViewModelExports.FirstOrDefault(o => o.Metadata.Key.Equals(relativeUri.Host, StringComparison.OrdinalIgnoreCase));
//ViewModel
var viewModelFactory = viewModelMapping.CreateExport();
viewModel = viewModelFactory.Value as IViewModel;
viewModelFactory.Dispose();//释放对象
//View
var viewFactory = viewMapping.CreateExport();
view = viewFactory.Value as Control;
viewFactory.Dispose(); //释放对象
//绑定、导航
view.DataContext = viewModel;
var values = viewModelMapping.Metadata.GetArgumentValues(targetUri);
viewModel.OnNavigated(values);
}

}

如果不加上viewModelFactory.Dispose();

对象MEF创建的对象不会被回收，VIew、ViewModel及其引用的资源都一直保持到程序关闭。

结论

a) 不要盲目使用第三方框架。

b) 内存泄露都有上下文，只有特定上下文中托管代码才可能产生内存问题。

c)注意由IOC创建的对象生命周期，如果IOC创建的对象由容器管理生命期，可能需要调用IOC提供的相关方法执行对象的销毁。

本文链接

Silverlight内存泄露（五）MEF等Ioc框架引起内存泄露-PartCreationPolicy

2011-04-14T13:21:00Z

这些内存泄露问题并不是IOC框架的bug，只是开发者使用不当或者不注意造成的内存泄露问题。

以MEF为例说明我碰到的两种内存泄露问题。

内存泄露系列阅读提示：

由于看一张图没什么意义，如果把多张图都贴出来，这文章就太难写了，即使多张图都贴出来，也不一定能表达清楚，分析内存泄露最重要的是经验。接下来的几篇会减少甚至不用这ANTS图。

PartCreationPolicy使用不当引起内存泄露

Shared：对象以Singleton方式创建。

Non Shared：每次请求时创建新对象。

Any： Be default, CompositionContainer will use Shared, unless the ComposablePart or importer requests NonShared。默认值

在使用不同的组合方式时，PartCreationPolicy有不同的默认值，因此尽量不要使用默认值。

看下面的程序：

NavigationCommand：由于多个View页面都有需要导航，把导航都放到类NavigationCommand中，恰恰是这一做法引出了内存泄露问题。

[Export(typeof(NavigationCommand))]

public class NavigationCommand

{

private RelayCommand<string> readBookComamand = null;

public RelayCommand<string> ReadBookComamand

{

get

{

if (navigatToContentCommand == null)

{

navigatToContentCommand = new RelayCommand<string>

(

p =>

{

//
},

p => !string.IsNullOrWhiteSpace(p)

);

}

return readBookComamand;

}

}

}

ViewModle

[ViewModelExport(typeof(BookPageSearcheViewModle), "BookPageSearche")]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class BookPageSearcheViewModle: NavViewModel
{
public RelayCommand<string> ReadBookComamand
{
get
{
return NavigationCommand. ReadBookComamand;
}
}
}
public abstract class NavViewModel : ViewModelBase, IViewModel
{
/// <summary>
/// The navigation service allows you to navigate to an other ViewModel.
/// </summary>
[Import]
public INavigationService NavigationService { get; set; }
[Import]
public NavigationCommand NavigationCommand
{
get;
set;
}
}

View

[ViewExport(ViewModelContract = typeof(BookPageSearcheViewModle))]
public partial class BookPageSearcheView: Page, IView
{
public BookPageSearcheView ()
{
InitializeComponent();
}
protected override void OnNavigatedFrom(NavigationEventArgs e)
{
if (this.DataContext is ICleanup)
{
((ICleanup)this.DataContext).Cleanup();
}
}
}
}

上例中NavigationCommand默认以Shared方式创建。

ANTS Memory Profiel 产生内存泄露的对象图：

可看出：BookPageSearcheViewModle 、Mef都引用了NavigationCommand，导致NavigationCommand没有被释放产生了内存泄露，在此只看MEF这一条路径。

我在处理这个内存泄露时太专注于BookPageSearcheViewModle对readBookCommand的引用了，而没有全面看这些图，断开BookPageSearcheViewModle对readBookCommand引用是最简单的处理方法，但是在处理其他ViewModel的时候会发现太多的Command需要处理，这时候才认识到断开引用的点错了。

因此一定要谨慎全面的看对象图，一个路径上包含n个点，断开任何点都能解决这个对象的泄露问题，但是一个程序有N个对象，这种只着眼当前对象的处理方式不能从根本上解决问题，必须找到内存泄露的根源。

解决MEF这个泄露问题，最简单的是加上：[PartCreationPolicy(CreationPolicy.NonShared)]

还可以使NavViewModel类实现所有Command，把组合转换为继承，断开长引用。

结论

a) 不要盲目使用第三方框架。

b) 设计时组合优先于继承，但组合更容易产生内存泄露，因为任何一方如果是长时间存活，内存就不会被释放。继承则无这个问题。

c) 注意由IOC创建的对象生命周期，如果IOC创建的对象由容器管理生命期，可能需要调用IOC提供的相关方法执行对象的销毁。

e)MVVM 比Code behind 方式更容易产生内存问题。V、VM双向引用关系，更可能造成内存不被释放

本文链接

Silverlight内存泄露（四）解决内存泄露

2011-04-13T15:33:00Z

定位泄露内存的对象很容易，但是找出引起泄露的原因并不容易，因为从GC到目标对象（内存泄露对象）的路径不只一条，找出哪条路径引起了内存泄露是非常烦人的工作，大部分情况只能凭借自己的经验。

一般我们都不会关注内存问题，当内存成为问题的时候，程序可能都开发完成了，这时候对象图会引入第三方库、.net 框架、本公司的其他库，需要梳理GC到目标对象的所有路径，并测试每一条路径，确认哪条引起了内存泄露。在测试某条路径的时候，需要排除其他路径对内存泄露的影响，这时候排除其他路径影响非常难，会牵涉到很多代码的改动。

以一个例子说明如何解决内存泄露，强制GC后，对比两个快照，发现没有被回收的对象，如下图BookPageSearche不是当前页面（现在看着还头疼，内存问题真是一个可以让人发疯的问题）：

这张图包含了Command、Event、Style、MEF引起的内存泄露，几乎包括所有我发现的内存泄露情况，这一篇讨论内存泄露的通用解决方案，不会针对每种问题讨论。

看标记出的几个点：

对目标来说，如果切断1，目标对象肯定会被释放，但是目标对象的直接父对象属于.net控件，不可能在这一点切断路径。

对于标记2，切断它会切断3、4、5，标记二NavigationCommand属于自己的代码可以在此释放内存，但并不应该在此释放。

标记3、5圈起来的部分，是由其他View内存引起的问题与这个目标对象关系不大，其他View（About、SIteNav）内存被释放后，这个路径自动被切断。

标记9是由自定义导航框架引起的内存泄露。

标记8是由MEF引起的内存泄露，并且是唯一与目标对象直接有关的路径（BookPageSearche），在这个目标中应从此点着手释放内存。

下面一张图是和上一张对照的，可对照看。显示了BookPageSearche是当前页面时的对象图，未执行GC。

需要避免的误区

第一直觉肯定是目标对象的直接父对象，只要他释放，不用再管更上层的诸多引用，如果这么处理可能属于头痛医头脚痛，不找点最合适的切断路径的点，会给程序修改带来灾难，后续会出现数不清的需要释放的对象。所以在释放内存是一定要避免不分析清楚直接下手释放。

总解

不知道有多少人能看的懂，这篇的目的只是提供一种通用的分析方法，分析出从GC到目标对象的多条路径应该选择哪几条路径释放内存，选择了合适路径以后又该在路径中的那个对象出断开引用。这其中的分析大部分只能凭借经验。

一些技巧

多看几个类似的对象图，比如找View的内存泄露，多看几个View，如About、Home等，从中找到共同点。

对于某个对象图，只解决直接和这个对象有关的内存泄露，而忽略由其他对象引起的内存问题。

从最简单的泄露问题着手，解决了一个泄露问题，会发现对象图会小很多，再分析其他泄露问题会简单一些。

本文链接

Silverlight内存泄露（二）检测内存泄露

2011-04-13T09:32:00Z

理解GC

理解了GC如果工作，.net程序中的许多奇怪问题都容易理解了。虽然.net一直声称.net程序不需要显式的内存管理，GC会在后台释放不需要的对象，开发者不需要管理对象，但是.net 程序仍然需要关注内存泄露和性能问题。尤其Silverlight、WPF的内存泄露比其他.net程序严重的多。

GC解决了非托管程序中常出现的内存泄露问题，比如开发者忘记释放自己创建的资源。既然GC可以释放内存，为什么还会发生内存泄露呢？原因只有一个，GC与开发者在对象是否生存（”live”）、是否正被使用上有不同的认识。开发者认为对象无用了，可以被GC回收，但GC却认为对象正被使用，内存不会被回收。因此必须明白GC工作机制。

下面简单介绍GC，更多内容参见其他资料。

1. 大对象与小对象

对象大于85k或多维数组大于8k，对象将被分配到LOH堆。

其他对象是小对象。

2. GCroot

简单说：GC释放内存从Root开始，只要Root可达的对象都被认为live,不会被回收。

GCroot不是对象，任何被GCroot引用的对象都可以自动在下一次的GC中存活，有四种GCRoot：

a) 方法中的本地变量，在方法执行期内被认为是root。

b) 静态变量总被认为是Root：thread static 在线程生命期内不会被回收，其他类型将持续到程序结束。

c) 托管对象被传递到非托管代码中，托管对象被认为是ROOt。

d) 实现了 finalizer的对象，在GC以后，虽然GC认为对象已经不存活了，但是再执行finalizer之前，此类对象也被认为是ROOT。因此如果检查到finalizer对象仍然存在，并不一定是内存泄露，下一次GC才会回收。

3. 对象图

对象在内存的关系构成了对象图，一个对象可能存在多个从root到此对象的路径，释放此对象，必须切断所有引用。

上图：classC存在三个路径，root1->ClassC、root2->ClassC、root3->Class

B->ClassC.

释放ClassC的内存必须切断三个路径。

可以看出内存泄露通常是开发者忘记或者没有意识到一个对象可能存在多个根。

4. GC 代

5. LOH大对象堆

对象大于85k或多维数组大于8k，对象将被分配到LOH，大对象不会被压缩，容易形成碎片，将抛出OutOfMemoryException，大对象仅在执行完全回收时执行，即在Gen2时回收。大对象产生的内存问题，不讨论。

检测内存泄露

许多工具可以检测内存泄露，现在使用ANTS Memory Profiler工具。

使用帮助：http://www.red-gate.com/supportcenter/Content?p=ANTS%20Memory%20Profiler&c=ANTS_Memory_Profiler/help/7.0/amp_getting_started.htm&toc=ANTS_Memory_Profiler/help/7.0/toc.htm。

检测内存泄露步骤

1. 了解自己的代码，什么地方容易发生内存泄露。

对于Silverlight，可以关注UI。由于这次检测的阅读器程序，采用了MVVM架构，可能发生泄露的地方， MVVM结构简图：

可以看出，最容易出现内存泄露的地方是View。

2. 打开ANTS Memory Profiler，New Profile Session

Uri选择html或者xap地址，如果是OOB程序，必须保证OOB没有安装到本地，否则会显示：

3. 使用ANTS 发现泄露的步骤

a) 多执行几次跳转等操作，获取内存快照。

b) Class List 视图中查找View

可看到View实例为2，应该为1。

c) Instance Cataegorizer 视图查看实例类别，ANTS会对GCRoot到当前对象的所有Instace根据路径分类。在此可以对实例Live情况有个基本认识。

上图显示两个类别。其中第一个可能是内存泄露。

d) Instance List 视图，重新执行可能引起内存泄露的操作，再次获取快照，如下图：

可看到第一个实例是上次GC没有被回收的对象。

除了可以根据代码估算内存泄露对象外，一般距离GC远的可能是泄露对象，Gen 越大越可能是泄露对象。

e) Instance Retention Graph 视图，显示从Root到当前对象的所有路径。解决内存泄露问题，就从这里着手了。

通过比较两图，找到可能泄露的地方，主要着手点是上次没被回收的对象图。

注:下图不必细看，用以说明Instance Retention Graph 视图内容，在下一篇会细说。

对象保存在缓存。

技巧

1. GC回收时间不可控制，可以增加GC回收代码：

GC.Collect();

GC.WaitForPendingFinalizers();//因为为Finalize对象，再第一次GC后仍然作为root存在，在下次GC时才会释放内存。

GC.Collect();//确保Finalize对象被释放

2.执行两次快照操作

本文链接

从火狐放弃依据特性更新版本说起

2011-04-13T01:05:00Z

火狐也跟随google的步伐，加快了浏览器版本的升级。在过去一年Chrome以疯狂的速度更新了多个版本，火狐只更新了一个。

火狐放弃依据特性发布版本，是否意味着google的版本发布方式更优秀呢？

未必如此，最初软件功能不完善，存在许多要增加的特性，此时采用特性版本发布方式非常适合，随着新版本的发布，特性列表中存在的特性多是，非关键特性或实现困难的特性。如果到了此时仍然沿用特性版本发布方式就不合时宜了，采用类似google的版本发布方式也是不错的选择。

扩展开来，事物的每个发展阶段都有针对此阶段的最优解决方案，而不存在针对这个事物的最优方案，也更不会存在对每个事物都是最优的方案。软件架构也如此，EDA、SOA、Layer、MVC、MVP、MVVM等等随着问题领域、技术领域的不同需要选择不同架构，即使为解决同一个问题，问题所处阶段不同，架构选择也不同。

本文链接

Silverlight内存泄露（二）解决内存泄露之Dispose误用

2011-04-12T08:57:00Z

按顺序第二篇应该是”如何检测SIlverlight内存泄露”，但这一系列都是解决实际问题的日志，有些检测结果没有被保存下来，不可能为了写这些文章，而重现bug。想到哪就写到哪了。

看到许多文章在解决事件为被注销引起内存泄露时，通过在Dispose中注销事件，以释放资源，这可能会出现未预料的问题。

Dispose模式介绍

参考：Effective C# - 条款18：实现标准的Dispose模式

要点：

通过实现IDisposable接口，你写成了两件事：第一就是提供了一个机制来及时的释放所有占用的托管资源，另一个就是你提供了一个标准的模式让用户来释放非托管资源。这是十分重要的，当你在你的类型上实现了IDisposable接口以后，用户就可以避免析构时的损失。你的类就成了.Net社区中表现相当良好的成员。

但在你创建的机制中还是存在一些漏洞。如何让一个派生类清理自己的资源，同时还可以让基类很好的再做资源清理呢？(译注：因为调用Dispose方法时，必须调用基类的Dispose，当然是在基类有这个方法时。但前面说过，我们只有一个标记来标识对象是否处理过，不管先调用那个，总得有一个方法不能处理这个标记，而这就存在隐患) 如果基类重载了析构函数，或者自己添加实现了IDisposable接口，而这些方法又都是必须调用基类的方法的；否则，基类无法恰当的释放资源。同样，析构和处理共享了一些相同的职责：几乎可以肯定你是复制了析构方法和处理方法之间的代码。正如你会在原则26中学到的，重载接口的方法根本没有如你所期望的那样工作。Dispose标准模式中的第三个方法，通过一个受保护的辅助性虚函数，制造出它们的常规任务并且挂接到派生类来释放资源。基类包含接口的核心代码，派生类提供的Dispose()虚函数或者析构函数来负责清理资源

Dispose可能存在的问题

Dispose是Object就有的方法，任何代码都有可能调用，并且子类应该调用基类的Dispose。从中可看出：

1. Dispose是.Net固有的方法，任何代码都可能调用

2. Dispose是自上而下执行的，基类到子类。

这表明Dispose是不可控的，其他代码很可能会调用这个方法。

MVVM light最初也依赖Dispose释放资源，但在新版本中已经使用ICleanUp接口释放资源，就是由于Dispose太不可控了。但为了兼容前版本，Dispose仍然有效。

Dispose引起问题的例子例子

[ViewModelExport(typeof(ChapterViewModel), "Chapter")]

[PartCreationPolicy(CreationPolicy.NonShared)]

public class ChapterViewModel:NavViewModel

{

ChapterService service = new ChapterService();

public C

[ViewModelExport(typeof(ChapterViewModel), "Chapter")]

[PartCreationPolicy(CreationPolicy.NonShared)]

public class ChapterViewModel:NavViewModel

{

ChapterService service = new ChapterService();

public ChapterViewModel()

{

service.Loaded += new EventHandler<AsyncEventArgs<object>>(service_Loaded);

}

void service_Loaded(object sender, AsyncEventArgs<object> arg)

{

}

public void Dispose()

{

service.Loaded -= new EventHandler<AsyncEventArgs<object>>(service_Loaded);

}

}

hapterViewModel()

{

service.Loaded += new EventHandler<AsyncEventArgs<object>>(service_Loaded);

}

void service_Loaded(object sender, AsyncEventArgs<object> arg)

{

}

public void Dispose()

{

service.Loaded -= new EventHandler<AsyncEventArgs<object>>(service_Loaded);

}

}

按照预想Dispose会注销事件，避免内存泄露，但运行时会发现service_Loaded可能不被执行，原因是 Dispose()被第三方程序调用了，而这些调用可能很隐蔽。

在这个程序里，下面的代码调用了Dispose，并且不易被发现。

var viewModelFactory = viewModelMapping.CreateExport();

viewModel = viewModelFactory.Value as IViewModel;

viewModelFactory.Dispose();

解决方式

通过其他方式注销事件，比如显式的接口、弱引用、匿名方法，在事件引起的内存泄露的文章中会详述几种解决方式。

在MVVM Light的cleanup注销事件

public override void Cleanup()

{

service.Loaded -= new EventHandler<AsyncEventArgs<object>>(service_Loaded);

Messenger.Default.Unregister(this);

base.Cleanup();

}

MVVM Light的问题

按上面的方式本应该解决问题，但是service_Loaded 仍有可能不被执行。原来Mvvm Light为了保持和上一版本的兼容性在Dispose方法中调用了Cleanup。

重载Dispose

protected override void Dispose(bool disposing)

{

//,覆盖基类
禁止调用cleanup

}

结论

1. 尽量不要用Dispose释放托管资源，而使用自己的接口。

2. Dispose中绝对不应该调用其他方法，像MVVM light中调用cleanup，就会导致问题。

3.第三方框架引来的代码复杂性应该被考虑。

本文链接

Silverlight内存泄露（一）序

2011-04-12T07:45:00Z

不知道有多少人遇到过Silverlight程序内存狂涨的状况，点击几个按钮、跳转几个页面程序的内存使用量一直上升。

即使最简单的程序，用silverlight模板，创建一个导航程序，跳转几次页面silverlight内存使用也再增加。

托管代码内存由GC回收，在silverlight、wpf出现之前内存泄露出现的比较少，但是silverlight程序却很容易发生内存泄露。

最近一直再处理Silverlight内存泄露问题，但网上相关内容很少，一些经验和大家分享。

托管代码内存泄露原因

GC介绍：NET中GC小记

http://www.cnblogs.com/aaronbao/archive/2010/04/04/1692925.html

GC并不能保证不发生内存泄露，GC只会会根据自身算法回收GC认为不再使用的对象，由于程序bug，有些对象在GC看来仍然被使用，但是这些对象都不再使用了应该被回收。

托管代码可能发生内存泄露的情况：

Static references
Event with missing unsubscription
Static event with missing unsubscription
Dispose method not invoked
Incomplete Dispose method

文章中使用Dispose注销事件，个人认为这种使用方式是错误的，至少不被推荐使用，下面会讨论这个问题。

详细内容参考下面文章：.net程序如何避免内存泄露

http://msdn.microsoft.com/en-us/library/ee658248.aspx

WPF可能发生内存泄露的情况

Leak Description	Developer Error	NETFX 3.0	NETFX 3.5	NETFX 3/5 sp1
Improper Use of Event Handlers	X
Improper Use of Data Binding	X
Improper Use of Command Binding	X	X	X	X
Improper Use of Static Event Handlers	X
Use BitmapImage in ImageSource		X	X
Multiple Use of BitmapImage			X
Use of downloaded BitmapImage		X
CMilChannel leaks if initial HWND destroyed on XP		X (XP only)	X (XP only)	X (XP only)
ShutdownListener leaked for each thread using Binding		X	X	X
Create and Destroy WriteableBitmap on XP in HW				X (XP in HW Only)
SW Viewport 3D w/ VisualBrush, WB, etc. leaks on XP				X (XP in HW Only)

参考：http://blogs.msdn.com/b/jgoldb/archive/2008/02/04/finding-memory-leaks-in-wpf-based-applications.aspx

Silverlight内存泄露原因：

1. 由silverlight本身的bug导致

期待Silverlight新版本的能解决问题。但是如果真对性能要求很高，可以找出引起内存泄露的代码或者xaml，换一种实现方式。这部分不多讨论，下面链接讨论了silverlight引起内存泄露的情况http://forums.silverlight.net/forums/t/171739.aspx

2. 程序bug，除了上述引起内存泄露的情况外，Silverlight引起内存泄露的情况还有：

a) Command引起的内存泄露

b) Style、Xaml引起的内存泄露

c) 弱引用引起的内存泄露——按道理弱引用不会产生内存泄露，但实际情况并非如此，弱引用看似简单，但其实却很难用好。哪怕及时释放掉了实际的对象，但弱引用数组还是会继续持有引用，这就导致了内存泄漏。可能和silverlight的bug有关。参看wpf 弱引用补丁http://www.infoq.com/cn/news/2010/06/WPF-Memory-Leaks

d) MEF等第三方注入库可能引起内存泄露

文章列表

当前想到可能包含下面的文章，有时间就会写：

1. 如何检测SIlverlight内存泄露

2. 如何解决内存泄露问题

3. 事件使用错误引起内存泄露

4. 静态引用引起内存泄露

5. Command引起的内存泄露

6. Style、Xaml引起的内存泄露

7. 弱引用引起的内存泄露

8. MEF等第三方注入库可能引起内存泄露

9. Dispose为何不应该被用来解决托管内存泄露问题——mvvmlight

参考：http://stackoverflow.com/questions/620733/memory-leak-in-c

本文链接

Silverlight IReader阅读器第二版

2011-04-07T08:28:00Z

下载地址silverlight 阅读器

主要是非功能方面的改进，整个架构做了调整。

a) 采用MVVM架构

b) 使用自定义导航结构

c) 使用MEF

d) 用户可以通过配置文件新增解析站点。

e) 使用百度搜索，放弃google（由于经常被墙），下一版本会采用bing api。

功能方面：

a) 图书文本文件生成。使用手机的方便了，可以直接生成文本，不必再通过为下载一本小说的文本而费力搜寻。

b) 改进收藏功能，可手动、自动更新收藏的图书，使收藏图书保持最新状态。

c) 本地图书，不再读取在线内容。

d) 改进了搜索功能

e) 新增目录预加载，收藏界面、排行榜界面会预加载目录，此时打开目录没有延迟。

f) 调整字体、行距、段间距、字体颜色可自定义

g) 新增阅读器模式

h) 新增纵横中文网支持（在追看焚天，必须增加了）、3g华夏，去掉啃书中文（已经关闭）

i) 下载图书下载允许两个并发下载，尽量平衡下载与阅读（SL只允许8个）。

UI架构

新搜索界面

搜索结果来源于百度，从界面能看出来吗？

新收藏界面

点击读取最新，将从网上查找收藏图书的最新章节，并预加载目录。

选取自动更新，每次跳转到此页面将自动读取最新章节。

本地页面

本地图书页面，不自动同步网络更新。

新增生成文本功能，在此只使用下载的本地内容生成文本。

书页

新增生成文本功能，将先下载图书再生成图书。

如果网速慢或下载进度停止，可停止后重新下载，会自动下载未成功下载的章节。

文本生成页面

章节页面

新增背景色、前景色设置、阅读模式

增大了字体、调整了段落间距。

这种可以拖动目录阅读的方式是不是更好呢，并且预加载了当前章节的相邻三章，阅读无延迟。

键盘快捷键导航也比鼠标方便很多。

阅读模式

全屏下的阅读模式

排行榜

能看出来下面是起点的周推荐排行榜吗？

加载进度条做了调整，现在只要有一个Item加载完成，进度条就消失。

设置

缓存不再细分为缓存文本和图片。感觉分这么细没什么意义，现在图片、文本都自动缓存。

增加了预读取目录

本文链接