Binding 和 x:Bind 的区别

Question

在 UWP 中使用什么，

Binding

或

x:Bind

，它们之间有什么区别？

因为我看到很多帖子中人们使用

Binding

而我只在 UWP 中与

x:Bind

绑定。

在 MSDN 主页上仅表示“由

{x:Bind}

和

{Binding}

创建的绑定对象在功能上基本上是等效的”。并且

x:Bind

更快。

但是它们之间有什么区别呢？

因为“功能很大程度上等同”并不意味着等同。

我引用的链接：MSDN

所以我的问题是：

在 UWP 中使用 Binding 或 x:Bind 有什么区别？

Answer 1

以下内容可能并不完整，但一些主要区别是

• 老款

  {Binding }

  • 绑定到 DataContext
  • 绑定到属性名称，对实际源类型灵活

• 新款式

  {x:Bind }

  • 绑定到框架元素（代码隐藏类）
  • 需要在编译时修复所有类型
  • 默认为更节俭的 OneTime 模式

并且 从版本 14393 开始，

{x:Bind }

支持：

• 直接 BooleanToVisibility 绑定，无需 ValueConverter
• 扩展功能绑定
• 铸造
• 字典索引器

较新的 {x:Bind } 在运行时速度更快一些，但同样重要的是，它会因错误的绑定而给出编译器错误。使用 {Binding } 在大多数情况下你只会看到一个空的控件。

深入比较检查：{x:Bind} 和 {Binding} 功能比较

Answer 2

{x:Bind}

执行在编译时生成的专用代码。

{Binding}

使用通用运行时对象检查。因此，

{x:Bind}

具有出色的性能，并提供绑定表达式的编译时验证。它通过使您能够在作为页面的分部类生成的代码文件中设置断点来支持调试。

因为

{x:Bind}

使用生成的代码来实现其好处，所以它需要在编译时提供类型信息。这意味着您无法绑定到您事先不知道类型的属性。因此，您不能将

{x:Bind}

与 Object 类型的 DataContext 属性一起使用，并且在运行时也会发生更改。

{x:Bind}

标记扩展（Windows 10 的新增功能）是

{Binding}

的替代方案。

{x:Bind}

缺少

{Binding}

的一些功能，但它比

{Binding}

运行时间和内存更少，并且支持更好的调试。

Answer 3

其他答案是正确的，但添加一些背景（和一点毫无歉意的颜色）。

WPF 几乎完全用托管代码编写；绑定系统大量使用 .NET 反射，虽然比直接代码慢，但如果巧妙使用，它并不像某些人想象的那么糟糕。毕竟，WPF 运行在 2006 年的硬件上，而且表现得相当不错。

当需要构建新的基于 XAML 的 UI 框架时，Windows 8、Windows RT 和 Metro 就陷入了崩溃。由于微软现在无疑感到遗憾但我们仍然在受苦的原因，该框架需要在 2014 年 ARM 硬件（即 Surface RT）上运行。显然，考虑到最低硬件要求，在托管代码中实现太多框架被认为（我不知道正确与否）不可行。

因此，他们没有从 WPF 代码库开始对其进行现代化改造，而是分叉了 Silverlight 代码库，该代码库已经主要是 C++，因为它是一个浏览器扩展。为了跨语言支持，他们发明了

IInspectable

，这是现在所谓的 WinRT 的基础，并创建了一个几乎难以理解且效率极低的系统，用于将本机类“投影”到 .NET 和其他语言。 （你知道，因为 C++ 端的普通 COM 以及 C# 接口和对象包装器的代码生成器太简单了）。

将本机代码投影到 C# 是一回事，但为了支持动态绑定到视图模型等，本机代码需要反射和调用托管对象/代码，这要复杂得多。因此，与 WPF 相比，Metro/UWP/WinUI 中的数据绑定性能很糟糕，或者至少直到最近都是这样。

所以

x:Bind

是不良架构的解决方法。它将尽可能多的动态绑定的繁重工作推回到编译时生成的托管代码（它最初所属的地方），以减少本机端和托管端之间所需的编组/反射量。

作为旁注，这解释了 WinUI 的许多其他限制和遗漏，例如没有

MultiBinding

、样式设置器中没有绑定、没有祖先类型

RelativeSource

绑定、本质上缺乏触发器、缺乏默认值

BindingMode 

代表

DependencyProperty

等等。他们真的非常希望你尽可能少地进行数据绑定，因为他们破坏了它的性能，而这一切都是为了支持导致 10 亿美元冲销的产品。