XAML 中嵌套的容器会影响呈现性能吗？答案

【问题标题】：Does containers nesting in XAML affect rendering performance?XAML 中嵌套的容器会影响呈现性能吗？
【发布时间】：2013-11-12 12:55:54
【问题描述】：

如果 WPF 应用程序的 XAML 包含 lot 嵌套的Grid、StackPanel、DockPanel 和其他容器，渲染性能是否会严重下降？

【问题讨论】：

@SonerGönül 对基本答案感兴趣（例如，如果 CLR 以某种方式优化该代码会怎样）
@SonerGönül 停止拖钓，并贡献一些有用的东西，除了在阳光下重新格式化每个问题。这个问题很复杂，性能测试不是一个简单的操作。
@Gusdor 他每天回答多个问题。你可以查看他的活动。他的代表表明他不会“[重新格式化]阳光下的每个问题”。这绝对是可测试的，最好是经过测试而不是留给理论。
@MillieSmith 我不否认它是可测试的。让我们把权重放在答案的质量上，而不是数量上，好吗？。

标签： c# .net wpf performance xaml

【解决方案1】：

真的，答案很简单“是”。更多的东西将使用更多的处理器时间。 惊喜！

在 WPF 的情况下，元素被排列成分层的场景图。与向现有元素添加同级元素相比，向该图添加深度级别会降低您的应用程序的速度。您应该始终努力保持图表的深度较低。考虑使用Grid 而不是嵌套StackPanels。

那么为什么深度比原始元素数量更重要呢？嗯，深度通常意味着；

布局依赖性 - 如果调整父级的大小，则可能会重新渲染子级。
遮挡 - 如果 2 个元素重叠，使一个元素失效通常会使另一个元素失效。
递归 - 大多数图形操作都受 CPU 限制 - 它们完全依赖于 CPU 速度并且没有专门的硬件支持（渲染器尽可能使用您的图形芯片）。循环遍历图表的各个级别以获取资源和布局更新是很昂贵的。

关于遮挡，BitmapCache 类可以提供很大帮助！

【讨论】：

【解决方案2】：

当您创建一个非常复杂的 UI，包含大量嵌套对象和包含大量元素的 DataTemplate 时，您可能会严重影响 App 的性能，因为 UI Tree 越大，渲染所需的时间就越大，如果该框架无法以 30FPS 渲染，您将开始看到性能下降。您应该使用您需要的最轻量级的面板，以避免不必要的额外逻辑。为了让您的应用程序更快，这里有一些性能提示：

http://msdn.microsoft.com/en-us/library/bb613542(v=vs.110).aspx

【讨论】：

很好的链接，尤其是关于仔细选择您的Panels。没有其他人注意到并非所有面板都是平等的。 Grid 用途广泛，但其渲染逻辑涉及更多。如果您真的不需要使用它，请不要使用它！
没错，例如在 Winwodws 8.1 中，所有与项目选择相关的逻辑都已被删除，以使 ItemContainers 更薄更快。我鼓励您阅读这篇关于提高 Windows 8.1 XAML 应用程序性能的文章，因为它也适用于 WPF 应用程序。 msdn.microsoft.com/en-us/library/windows/apps/hh994641.aspx希望对您有所帮助！

【解决方案3】：

WPF 使用 MeasureOverride 和 ArrangeOverride 方法来呈现 UIElement。 MeasureOverride 根据父控件的宽度和大小测量 UIElements 的宽度和大小。 ArrangeOVerride 方法将根据这些措施在运行时安排 UIElements。这些方法针对更快的性能进行了优化，不会导致任何渲染性能问题。

但是应该有能力让这些方法在最短的时间内处理 UIElements。如果超过此限制，则应该存在性能问题。

例如：假设一辆自行车可以载 2 个人。如果5个人超载会发生什么:)

Jet Brains .Trace 是一种分析性能问题的工具，有助于了解这两种方法

【讨论】：

这个答案似乎取决于“如果你让它太慢，它会很慢”的逻辑。