担心WPF。我应该为 Windows GUI 使用 WPF 还是其他库？

Question

我已经在一个执行数值计算的库上工作了一段时间。它是用纯原生 C++ 编写的，直到现在我一直在使用简单的控制台应用程序来测试它的功能。

现在是在库之上构建 GUI 的时候了 - 以更好地显示结果表并以图形形式呈现它们。

我一直计划使用 WPF 来实现 UI，并花了一些时间研究它，但我现在有了新的想法。我对 WPF 的担忧是：

1. 是否值得为了用户界面而将我的程序耦合到 .NET 框架？ .NET 和 WPF 似乎以多种形式增加了开销，包括：
   • 程序复杂性
     • 使用 .NET 意味着使用第二语言 - 因此会编写大量杂乱的互操作代码。
   • 运行时性能
     • 特别是 WPF 应用程序的启动似乎非常缓慢。
   • 部署
     • .NET 框架的安装是否快捷方便？是否需要重启机器？

2. 渲染质量
   • 这在 WPF 4 中有所改进，但标准元素的显示在某些区域似乎仍然很差。

3. 担心未来性能和质量是否会提高
   • Microsoft 内部确实不重视 WPF（支持 Silverlight）吗？

人们离开 WPF 也面临类似问题的消息加剧了我的担忧 - 最近和最引人注目的是 Evernote。

你会建议我坚持原来的计划并使用 WPF 吗？

如果是，您对上述问题有何看法？
如果没有，我可以使用哪些替代库来创建高质量的 Windows GUI？

---

编辑：

感谢 Reed Copsey 提出我的个人观点。回复表明我在 WPF 中遇到的大多数问题都可以解决。

似乎使用 WPF 将涉及比理想情况更多的工作 - 包括编写互操作代码和进行调整以确保良好的性能和高质量。人们是否普遍同意这样一种说法，即尽管如此，产生高质量 UI 的最佳方式是使用 WPF，而不是使用任何其他框架？

Answer 1

我将尝试按顺序解决这些问题。剧透：在我看来，在大多数情况下，答案是肯定的。

是否值得为了用户界面而将我的程序耦合到 .NET 框架？

这取决于接口要求。你的用户需要一个好的、可靠的、现代的用户界面吗？如果是这样，您将需要使用正确的工具来满足该要求。

.NET 和 WPF 似乎以多种形式增加了开销，包括：

• 程序复杂性
  • 使用 .NET 意味着使用第二语言 - 因此会编写大量杂乱的互操作代码。

您可以通过 C++/CLI 使用 GDI+，并以一种语言处理所有事情。话虽如此，人们为此使用其他语言的部分原因是生产力——与用 C++ 制作 GUI 相比，它实际上非常非常快。通过 C++/CLI 的互操作代码一点也不杂乱，至少如果您的例程是基于类的，则不会。

运行时性能 - 特别是，WPF 应用程序似乎启动非常缓慢。

在某种程度上，这可能是一个问题。但是，您可以做很多事情来缓解它 - 但这可能总是比精简的原生代码库慢一点，因为它必须启动 CLR + 库。

部署 - .NET 框架安装是否快捷方便？是否需要重启机器？

通常情况下，这两个方面都是。话虽这么说，大多数人已经安装了框架（特别是如果你的目标是 .NET 3.5，但 4.0 很好地出现了），所以这不是问题。不过，我总是将其视为一次性的事情——我宁愿以良好的用户体验换取一些部署时间，尤其是当它是一个相对无痛的部署时（.NET 非常易于安装，只是大而有点费时间）。

渲染质量 - 这在 WPF 4 中得到了改进，但标准元素的显示在某些区域似乎仍然很差。

我强烈反对这里。 WPF 是（尤其是在 v4 中），优质用户界面的首要平台。在 WPF 中很难击败渲染质量选项 -

担心未来性能和质量是否会提高 - WPF 在微软内部被淡化（支持 Silverlight）是真的吗？

没有。甚至在 PDC 上就 WPF 的未来进行了很好的讨论。 Silverlight 得到了更多的关注，但这主要是因为它的技术还不够成熟，所以它的变化更快。 WPF 仍然是他们的顶级 UI 体验，并且仍在添加新功能。它也是与本机代码互操作的建议平台 - 虽然在 SL 中使用 COM 是可能的，但它不像在 WPF 中那样令人愉快。

根据 PDC 的谈话，性能、线程问题和空域问题似乎是未来的改进。详情请看“The Future of WPF”。