标题基本概括了所有内容.我做了一些谷歌搜索,但我能找到的唯一信息是至少一年,有些信息比Windows 7旧.所以我很好奇,使用WPF会有性能损失吗？
对于某些事情(例如数据绑定)来说,它比你在WinForms上一起攻击的速度更快吗？
这将是一个用.NET创建的项目,以防对任何人都很重要.
编辑
我正在看的这个项目有一个基本的UI风格,但是可能会显示很多信息(它查询文件/目录并在屏幕上显示它们).我还没有决定它是否会自动刷新屏幕,但我想它可能会.
可能会有相当多的控制,但任何人都不应该考虑"图形"密集.
从业务应用程序的角度来看,我正在关注性能.
我不打算使用第三方控件.
Mik*_*bel 18
对此没有任何有意义的"是"或"否"答案.这取决于许多因素,包括但不限于:
你正在构建什么样的UI.
显然,您正在设计的视图的复杂性将影响两个平台上的性能.它们具有不同的布局和渲染管道.
如何有效地优化每个平台的性能.
当然,使用两个平台实现性能较差的UI很容易.实现复杂的UI以使其执行得非常好,需要知道如何有效地利用每个平台的优势和劣势.
无论您是使用开箱即用的控件还是第三方控件,以及这些控件的质量.
第1项和第2项也会转移到任何第三方组件.
如果您是一位经验丰富且称职的WinForms开发人员,那么您可能已经知道如何在WinForms中创建高性能视图.WPF的学习曲线很陡; 任何经验丰富的WPF开发者都可以告诉你.他们还会告诉您,您可以使用它来构建性能良好的丰富UI.这也是事实.WinForms也是如此.
两个平台都很成熟.两者都被广泛使用.除了错误修复之外,两者都不可能看到任何未来的改进.
所有这一切,如果你还没有在任何一个平台上投入大量资金,我会选择WPF路线.它是一个丰富的(虽然是重量级)框架,可以使其表现良好.使其运行良好所需的工作量在很大程度上取决于您正在创建的视图类型,但我使用WPF构建了许多高容量,高频率数据视图.我还用WPF构建了一个视觉丰富的策略游戏.但不要觉得有必要忍受它; 如果您的开发人员已经熟悉WinForms,那么它仍然是一个非常可行的选择.
更新:我认为未来几年WinForms支持不太可能从.NET中删除,但如果这是一个问题,那么我会选择WPF.您描述的视图类型可以在WPF中轻松创建.为了比较,我有几个视图能够显示50,000到500,000行,60列以上; 每秒数千行更新; 应用自定义,多级排序和分组; 自定义过滤; 自定义摘要; 所有都保持最新的伪实时("人"实时).获得这种性能水平并不容易,但可以做到.使用任一平台和仅使用内置控件套件,您描述的数据量和频率应该更容易实现.
Fed*_*gui 18
如果您正在进行复杂的UI,那么WPF就是您的选择.winforms不支持任何东西.
如果您正在使用简单的UI,WPF是可行的方法,因为:
如果你担心长期:
WPF是要走的路.当前/未来的Windows UI框架是WinRT XAML.最终将WPF应用程序移植到WinRT XAML比使用winforms应用程序更容易.而且,由于MVVM实际上与技术无关,因此您最终可以在任何其他UI技术中重用ViewModel.
编辑:由于我一直收到许多downvotes并且围绕这个答案进行了很多讨论,我将特别关注OP的问题并尝试提供一个相当客观的答案:
性能:当您比较WPF反对的WinForms为非常简单的用户界面内存使用(一个Window或Form仅含有TextBox例如),WPF似乎消耗比的WinForms更多的内存.这是因为WPF框架比winforms大得多,因此它还有更多"要加载的东西"才能工作.比较冷启动时间(同样,在1控制情况下)也是如此.
相比之下,当您创建由多个控件/ Buttons/DataGrids/ComboBoxes/TextBoxes /等(在业务应用程序中非常常见的事物)组成的较重的UI时,差异开始减小,直到它甚至支持WPF.这是因为WPF的DependencyProperty系统,它将默认属性值存储在单个内存空间中,而不是基于每个实例.
WPF旨在从一开始就用于复杂/丰富的UI,并且针对有数千个控件而非1个控件的情况进行了优化.
从数据为中心的角度比较WPF和winforms之间的性能时要考虑的另一个非常重要的方面是,如上所述,UI虚拟化.只需看一下这个视频,很明显WPF在需要显示20k行的情况下表现得更好ListBox.我被一个winforms大师告知winforms似乎也支持这个,但是由于winforms没有正确支持,你需要求助于P/Invoke,并且据他所说,如果其他控件放在一边对我来说并不明显从ListBox也支持winforms(例如DataGridView和TreeView).ItemsControls默认情况下,所有WPF 都已经或可以使用一些简单的应用程序范围样式进行虚拟化.
硬件加速:你可能会认为"我不需要这个",但是如果你环顾四周,有很多情况下winforms在更新UI时会开始出现可怕的闪烁,不一定是在复杂的绘图情况下,而是在调整大小时包含许多控件的窗口.有一些方法可以解决这个问题,但是再一次,你必须开始浪费时间来解决一个你永远不应该开始的问题,而不是专注于你的业务逻辑.你永远不会遇到WPF这个问题,不仅因为它是硬件加速的,而且因为它是基于矢量的,而不是基于Bitmap的.
结论:尽管winforms在1控制案例中的表现可能更好,但WPF在现实世界数据中心UI的各个层面都是明显的赢家.
除此之外,正如@Blam所提到的,选择一项技术需要您不仅要分析性能方面,还需要分析可扩展性,可定制性,可维护性,易于开发,长期视角以及许多其他方面.
在所有这些方面,WPF再次成为明显的赢家.精心设计的WPF MVVM应用程序具有非常干净,简洁,漂亮的代码库.winforms,无论你是多么专家,都会一直强迫你进入解决方案背后的脏代码,只是因为它不支持真正复杂的场景,并且需要几乎所有人都能想到的自定义代码.
特别是可定制性,我会说,即使你not计划创建一个完全自定义,丰富的用户界面,选择WPF仍然是一个更明智的决定,因为有了winforms,如果你想要显示你的最终你可能会碰壁数据采用默认不支持的格式.然后你将不得不开始痛苦,并失去你的时间与可怕的技术,如"所有者绘制",而在WPF所有你需要的是一个简单的DataTemplate
当然,WPF是一个复杂的框架,但实际上并不是它的复杂性使得学习曲线陡峭,而是所需的心态变化才是大多数来自其他框架的开发人员所挣扎的.
而且,如上所述,您必须对抽象进行编码,而不是针对特定的一组类进行编码,这样您的代码最终可以根据需要移植到其他框架.WPF允许这样做,winforms没有.
如果你在winforms上编码,那么你将永远陷入winforms的无能力和黑客攻击的代码中.确实,如果你在winforms上使用MVP,这有点缓解,但仍然是演示者与UI框架的耦合比MVVM中的ViewModel更紧密,这完全与UI无关.
如果使用XAML和MVVM在WPF中编码,最终可以将WPF XAML视图替换为其他内容,并保持ViewModel不受影响,这意味着您实际上不必从头开始重写整个应用程序,因为ViewModel 是 Application,不是意见.
小智 9
我尝试在winforms的面板上绘制大量的线条,并在画布上使用WPF绘制相同的dt,发现winforms在不到一秒的时间内创建了旋转,WPF花了很多秒,即使我在WPF中使用Pathgeometry而不是而不是shpes
小智 6
我已经用 MVVM 模式为 Windows 窗体和 WPF 编写了许多应用程序，当您比较在两者上实现的相同应用程序时，Windows 窗体在数据绑定应用程序中胜出。如果您有多个子数据网格绑定到单个父数据网格或结构，您会注意到更多的影响，永远不明白为什么。因此，对于业务应用程序，我总是只在必要时才使用 WPF 进行编码。我还发现 Windows 窗体上的排序和过滤也更容易。
| 归档时间： |
|
| 查看次数： |
23268 次 |
| 最近记录： |