我有两个级别的深度集合,我渲染成一个像标题,子项目。
粗略地说,我的代码看起来像这样:
<ScrollViewer>
<ItemsControl IsEnabled="{Binding Path=IsEnabled}"
ItemsSource="{Binding Path=HeaderViewModels, Mode=OneTime}">
<ItemsControl.ItemsPanel>
<ItemsPanelTemplate>
<StackPanel Orientation="Horizontal" />
</ItemsPanelTemplate>
</ItemsControl.ItemsPanel>
<ItemsControl.ItemsTemplate>
<DataTemplate>
<StackPanel Visibility="{Binding Path=ShouldShow, Converter={StaticResource SomeConverter}}">
<TextBlock Text="{Binding Path=Description, Mode=OneTime}" />
<ItemsControl ItemsPanel="{StaticResource WinRTXAMLWrapPanel}"
ItemsSource="{Binding Path=ChildViewModels, Mode=OneTime}">
<i:Interaction.Behaviors>
<SomeClass:AdjustSizeBehavior SizeFromParentMode="Height" />
</i:Interaction.Behaviors>
<ItemsControl.ItemsTemplate>
<DataTemplate>
<ContentControl>
<i:Interaction.Behaviors>
<SomeClass:IsEnabledBehavior />
<SomeClass:PointerPressBehavior />
<SomeClass:PointerLeaveBehavior />
</i:Interaction.Behaviors>
<StackPanel>
<TextBlock Text="X">
<i:Interaction.Behaviors>
<SomeClass:SetXMarkColor />
</i:Interaction.Behaviors>
</TextBlock>
<TextBlock Text="{Binding Path=Description, Mode=OneTime}" />
</StackPanel>
</ContentControl>
</DataTemplate>
</ItemsControl.ItemsTemplate>
</ItemsControl>
</StackPanel>
</DataTemplate>
</ItemsControl.ItemsTemplate>
</ItemsControl>
</ScrollViewer>
省略了样式,但它有相当多的背景,边距,字体大小等。另外,你可以看到我使用了大量的绑定和行为。
我已经完成了我能想到的大部分优化。删除了不必要的UI元素(例如用于'背景'的矩形),使用StackPanel而不是Grid,将列/高度设置为静态而不是自动。基本上我可以在此链接上完成所有工作:Twelve ways to improve wpf performance和Best practices for Windows Store Apps
通过我所做的优化,我实际上减少了10个标题的加载时间+每个8个孩子(总共80个),从1.8秒到大约0.5毫秒 - 0.6毫秒。
然而,我希望它达到不到0.5毫秒,所以它就像'即时'。
我还能做些什么来改善表现吗?
谢谢!
答案 0 :(得分:1)
看起来你的XAML很干净。你的C#代码怎么样?
如果您使用async / await,并将任务推送到后台线程,它可以真正提高性能。 Async / await是创建快速响应应用程序的秘诀。
Visual Studio 2015在识别和修复WPF性能瓶颈方面有一些很大的改进。
您可以使用分析器确定哪些代码行占用时间最长,因此可以使用async / await推送到后台线程。分析器非常棒:它在编辑器中显示每个块或代码行所用的时间(以毫秒为单位)。
更多:
虽然我们在此,但如果Microsoft在WPF中实现编译时绑定,它将极大地提高性能。绑定速度可以快10倍,因为它不再基于反射。在此处添加您的投票以实现此功能:https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/7810488-implement-x-bind-for-wpf
答案 1 :(得分:1)
是否使用主/细节网格的问题是一个有趣的相关问题。我和一个自2006年发布以来一直使用WPF的开发者聊天。他是一个大师,他认为主/细节网格并不总是从可用性和速度点来看都是最好的观点。原因是你几乎总是在启动时加载所有细节,这很慢,除非你在后台使用一些有趣的技巧来延迟加载。如果您扩展了一些细节网格,屏幕开始显得凌乱。
它几乎就像主/细节网格一样,但它们通常不是一个好主意。四处寻找使用主/细节网格的成功,可用的软件。除了Windows资源管理器风格的界面外,它们在进化领域相对较少。它们在Apple领域并不常见,这暗示从用户的角度来看它们可能不是最佳选择。
真正奇怪的是,相对有经验的程序员往往喜欢主/细节网格 - 很多。它们似乎对程序员具有直观的吸引力,因为它们对数据进行了很好的建模。但是从用户的角度来看,他们宁愿拥有一个快速加载的平面网格,并且网格下方的Properties
面板始终显示我们选择的当前行的详细信息。
是的,这个答案并没有解决你的确切问题 - 它太过哲学了 - 但它肯定会在一个整洁的重构中解决你的速度问题,并可能使你的应用更加直观你的用户。