WF3设计时性能I

译自：http://blogs.msdn.com/kushals/archive/2010/04/05/wf3-design-time-performance-i.aspx

在我们开始讨论WF3设计时性能之前，让我们先澄清一些术语。

1. WF3是作为.NET Framework3.0和3.5的一部分发布的，要注意的是尽管WF3也做为.NET  Framework 4.0的一部分，但是System.Workflow.*程序集是其最新的版本。
2. WF4是第一次作为.NET Framework 4.0的一部分发布的，System.Activities.*是其最新的版本。

没错，WF3和WF4在.NET Framework 4.0中是同时发布的。

关于设计时的性能，我们听到了很多反馈。一般来说，抱怨是设计器的性能随着活动的数量增加而呈指数性的降低。

接下来的几篇文章中，我们将讨论如何提高设计器的性能，以及我们所做的一些改进性能的修补程序。这里有一篇关于工作流性能的白皮书可以参考。

下面是需要牢记的一些Tips：
1. 将工作流中使用到的类型转移到一个不同的项目中
将接口，事件类型，自定义活动，helper类转移到不同的项目中，例如有一个客户的解决方案，有10个项目，10个工作流都有一个对应的事件类型。这样当用户每次更改工作流的时候都会重新解析更新设计时的类型信息。将这些事件类型转移到一个不同的程序集中有助于提高性能。

2. 减少一个项目中工作流的数量
每一个工作流都是一个类型，不管是c#/VB代码形式的，还是xoml形式的。他们都需要解析并生成对应的设计时类型，所以如果一个项目中有10个工作流，我们第一次打开任何一个工作流的时候都需要解析其他所有的工作流。我们可以根据功能分组将每2到3个工作流放到一个项目中有助于提高性能。

3. 将大的状态机工作流重构小的
一个例子是我们从一个客户发现他有一个工作流有780个状态和1000个活动，导致InitializeComponent()中有16000行代码。将此状态机工作流重构为一些较小的可重用的工作流有助于提高性能，并且可以减少大量的冗余状态。

4. 在活动的构造函数中不要做长时间的任务
活动的构造函数在设计时会被调用，所以象类似连接数据库这样的事情永远都不要放在构造函数中，他会导致使用这些活动的设计器打开时间过长。

当然上述4点不会解决您所有的设计器的性能问题，请您关注后续关于这个主题的文章。