基本概念
WPF的一个特点就是支持动画，我们可以非常容易的实现漂亮大方的界面。首先，我们来复习一下动画的基本概念。计算机中的动画一般是定格动画，也称之为逐帧动画，它通过每帧不同的图像连续播放，从而欺骗眼和脑产生动画效果。
WPF的动画实现
简洁
这个是非常明显的，WPF的动画的代码非常容易理解，Timer的版本则要难懂得多。当然，我们也可以通过封装，使得用Timer也能用类似的API实现动画。但动画的API并不是仅仅这么一点，要把整个动画框架的API都封装也没有那么容易。
和XAML无缝继承
这个就是WPF的独有技术了，得益于XAML强大的表述能力，我们可以写出非常强大且容易维护的动画。这点WinFom的Timer版本是无法做到的。
流畅性
如果将这两种实现方式一起跑起来比较一下就会发现，Timer实现的版本明显要卡顿，并且并没有精准的按照我们设计的那样运动。具体原因为：
Timer精度的问题
由于是改UI控件的属性（按钮的宽度），因此必须在UI线程上进行，因此DispatcherTimer操作与其他操作一样需要放置到Dispatcher队列中，它并不保证恰好在改时间间隔中。它并不适合动画这种间隔很短的计时。
帧率的问题
逐帧动画的流畅性一般取决于每秒更新的帧数，也就是常说的帧率。人眼睛上限是70帧，而我这里代码中的Timer的固定了为20帧，因此是能明显感觉到卡顿的。而WPF的动画则不然，从它的API中可以看到，它是没有帧率的设置的。实际上，它是根据计算机的性能和当前进程的繁忙程度尽可能增大帧率的，因此WPF的动画是远大于20帧的，因此要流畅得多。
那么，是否只要修改参数，加大Timer的版本的帧率，也可以实现同样流畅的动画呢？ 试了一下，就算修改参数，也是无法达到WPF版本的流畅程度的。我认为原因主要有如下两点：
DispatcherTimer精度不够，无法实现大帧率下准确刷新。
通过简单的设置参数很难像WPF那样帧率根据计算机的性能和当前进程的繁忙程度智能匹配帧率。帧率设置过低，动画不流畅，设置过大，处理不过来仍然不流畅。并且UI线程的忙碌程度是会动态变化的，帧率也需要相应调整，这些都无法通过Timer来简单的处理。
From/To/By动画
这种过渡动画一般成为From/To/By 动画，是因为它们是通过From、To、By三个属性来决定了目标属性的起始值和结束值。首先我们来看下这三个属性代表的意义：
（1）From： 起始值，在动画开始的时候将目标属性设置为该值。
（2）To： 结束值，动画结束是目标属性为改值。
（3）By： 偏移值：动画结束的时候目标属性为"初始值+偏移值"。
很明显，To和By的效果是有可能冲突的。实际上，这三个属性都是可选设置的，并且在设置了To和By的时候，是会忽略By属性的。下面我再通过一些简单的场景介绍一下这三个属性如何组合使用。
属性具有动画功能的要求
（1）它必须是依赖项属性。
（2）它必须属于继承自 DependencyObject 并实现 IAnimatable 接口的类。
（3）必须存在可用的兼容动画类型。
WPF的一个特点就是支持动画，我们可以非常容易的实现漂亮大方的界面。首先，我们来复习一下动画的基本概念。计算机中的动画一般是定格动画，也称之为逐帧动画，它通过每帧不同的图像连续播放，从而欺骗眼和脑产生动画效果。
WPF的动画实现
简洁
这个是非常明显的，WPF的动画的代码非常容易理解，Timer的版本则要难懂得多。当然，我们也可以通过封装，使得用Timer也能用类似的API实现动画。但动画的API并不是仅仅这么一点，要把整个动画框架的API都封装也没有那么容易。
和XAML无缝继承
这个就是WPF的独有技术了，得益于XAML强大的表述能力，我们可以写出非常强大且容易维护的动画。这点WinFom的Timer版本是无法做到的。
流畅性
如果将这两种实现方式一起跑起来比较一下就会发现，Timer实现的版本明显要卡顿，并且并没有精准的按照我们设计的那样运动。具体原因为：
Timer精度的问题
由于是改UI控件的属性（按钮的宽度），因此必须在UI线程上进行，因此DispatcherTimer操作与其他操作一样需要放置到Dispatcher队列中，它并不保证恰好在改时间间隔中。它并不适合动画这种间隔很短的计时。
帧率的问题
逐帧动画的流畅性一般取决于每秒更新的帧数，也就是常说的帧率。人眼睛上限是70帧，而我这里代码中的Timer的固定了为20帧，因此是能明显感觉到卡顿的。而WPF的动画则不然，从它的API中可以看到，它是没有帧率的设置的。实际上，它是根据计算机的性能和当前进程的繁忙程度尽可能增大帧率的，因此WPF的动画是远大于20帧的，因此要流畅得多。
那么，是否只要修改参数，加大Timer的版本的帧率，也可以实现同样流畅的动画呢？ 试了一下，就算修改参数，也是无法达到WPF版本的流畅程度的。我认为原因主要有如下两点：
DispatcherTimer精度不够，无法实现大帧率下准确刷新。
通过简单的设置参数很难像WPF那样帧率根据计算机的性能和当前进程的繁忙程度智能匹配帧率。帧率设置过低，动画不流畅，设置过大，处理不过来仍然不流畅。并且UI线程的忙碌程度是会动态变化的，帧率也需要相应调整，这些都无法通过Timer来简单的处理。
From/To/By动画
这种过渡动画一般成为From/To/By 动画，是因为它们是通过From、To、By三个属性来决定了目标属性的起始值和结束值。首先我们来看下这三个属性代表的意义：
（1）From： 起始值，在动画开始的时候将目标属性设置为该值。
（2）To： 结束值，动画结束是目标属性为改值。
（3）By： 偏移值：动画结束的时候目标属性为"初始值+偏移值"。
很明显，To和By的效果是有可能冲突的。实际上，这三个属性都是可选设置的，并且在设置了To和By的时候，是会忽略By属性的。下面我再通过一些简单的场景介绍一下这三个属性如何组合使用。
属性具有动画功能的要求
（1）它必须是依赖项属性。
（2）它必须属于继承自 DependencyObject 并实现 IAnimatable 接口的类。
（3）必须存在可用的兼容动画类型。
