合并字典和资源查找 [英] MergedDictionaries and Resource lookup

问题描述

我通常对资源字典和合并字典有疑问，尤其是在资源查找性能方面.经过一些性能测试后，我发现ResourceDictionary.get_MergedDictionaries是命中次数最多的调用(已在ANTS探查器中选中).我们大约有300个资源字典xamls，其中很多都使用合并字典来包含"其他样式.好吧，get_MergedDictionaries依靠我们的应用程序的一部分(点击量不大)被击中了大约一千万次.所以我的猜测是，我们通常对资源词典所做的事情完全错误.因此，我试图重构所有内容，并希望摆脱所有合并的字典.

i have a problem with Resource dictionaries and mergeddictionaries in general, especially when it comes to resource-lookup performance. After some performance testing i found that ResourceDictionary.get_MergedDictionaries is the call with the most hits (checked in ANTS profiler). We have around ~300 resource dictionary xamls, and a lot of them are using merged dictionary to "include" other styles. Well the get_MergedDictionaries count on one part of our application, where not much is happening, was around 10 million hits. So my guess is we are doing something completely wrong with Resource dictionaries in general. So i tried to refactor everything and i want to try to get rid of all the merged dictionaries.

现在是实际问题.我试图摆脱合并词典，但失败了.我的理解是，当您使用StaticResource时，查找需要在当前资源之前定义资源.我举了一个简短的例子:

Now to the actual question. I tried to get rid of the mergeddictionaries but i failed. My understanding is that when you use StaticResource the lookup needs the resource to be defined before the current one. I made the following short example:

一个主项目和一个自定义控件库.

One main project and one custom control library.

自定义控件库包含2个xamls.

the custom control library contains 2 xamls.

<!-- Colors.xaml -->
<ResourceDictionary [stripped namespaces] >
    <SolidColorBrush x:Key="myColor" Color="Green"/>
</ResourceDictionary>

<!-- Templates.xaml -->
<ResourceDictionary [stripped namespaces]>
    <ControlTemplate x:Key="myTemplate" TargetType="Button">
        <Rectangle Fill="{StaticResource myColor}"/>
    </ControlTemplate>
</ResourceDictionary>

现在在主项目中，MainWindow.xaml看起来像这样

Now in the main project, the MainWindow.xaml looks like this

<Window x:Class="ResourceTest.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Window.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/ResourceTestLib;component/Themes/Colors.xaml"/>
                <ResourceDictionary Source="/ResourceTestLib;component/Themes/Template.xaml"/>
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Window.Resources>
    <Grid>
        <Button Template="{StaticResource myTemplate}"/>
    </Grid>
</Window>

这是理想的目标.但是不幸的是，这崩溃了，因为找不到资源"myColor".我当然知道如何修复它，在Templates.xaml中添加一个mergeddictionary并引用Colors.xaml，但是我一直认为，以及我从未真正检查过，根据逻辑树和元素的资源来查找资源.我的理解是按钮已创建；尝试查找模板..发现；尝试查找在自己的资源上找不到的颜色，然后步行并使用Windows资源.

That is the desired goal. but unfortunately this crashes because the resource "myColor" cannot be found. I of course know how to fix it, add a mergeddictionary in Templates.xaml and reference Colors.xaml but i always thought, well i never really checked, that resources are looked up depending on the logical tree and the resources of the element. My understanding is; Button is created; try to lookup template .. found; try to lookup color, not found on own resources, walk up and use the windows resources.

看来我错了. 因此，我希望有人可以为我阐明这一点.我们大量使用WPF，尽管如此，我们还是做了很多事情，但是由于一开始学习到的错误行为，由于资源查找，我们的性能非常差. 任何帮助将不胜感激

It seems that i'm wrong. So i hope someone can shed some light on this for me. We make heavy use of WPF and despite of this we accomplished a lot with it, but because of some wrong learned behaviour in the beginning, our performance is pretty bad just because of the resource lookup. Any help would be greatly appreciated

先谢谢了 最好的祝福 尼科

Thanks in advance Best regards Nico

推荐答案

好吧，我不喜欢回答我自己的问题，但是我想很多人可能会偶然发现这个问题，因此我想给他们提供我们当前的解决方案可以考虑的选择.

Well I don't like answering my own question, but I guess a lot of people might stumble into this and I want to give them our current solution as an option to consider.

就像我之前说过的，我们有很多XAML，大约300种，用于各种不同的事物，例如共享资源(画笔，颜色)，但也有许多XAML，它们包含不同的DataTemplates，控件的样式以及自定义控件.在一开始，使用大量XAML的方法对我们来说是合理的，因为我们对类进行相同的操作，并使其小而有条理. 不幸的是，WPF不喜欢那样.您拥有的ResourceDictionaries越多，通过MergedDictionaries合并它们的次数越多，您的性能就会越差. 我能给您的最佳建议是使用尽可能少的ResourceDictionary XAMLs .

Like I said before, we have a lot of XAMLs, around ~300 for all different kinds of things like Shared Resources (Brushes, Colors) but also many XAMLs containing different DataTemplates, Styles for controls and also for Custom Controls. In the beginning this approach of having a lot of XAMLs was reasonable for us, because we do the same with our classes and keep them small and organized. Unfortunately, WPF doesn't like that. The more ResourceDictionaries you have and the more you merge them via MergedDictionaries the worse your performance will get. The best advice I can give you is, use as few ResourceDictionary XAMLs as possible.

我们咬紧牙关，将其中的许多内容合并为一个巨型XAML，实际上，我们现在是通过预编译器来做到这一点的，同时兼顾了两者的优点.遵循一些约束，然后将它们合并到大型XAML中的编译器中，我们可以根据需要使用任意数量的XAML.我们获得的性能提升非常显着.在我的问题中，我写了对getMergedDictionaries进行了1100万次匹配"……只是预编译"了我们的一个程序集，结果降至200万次匹配，并且在整个应用程序中的性能在任何时候都好得多.

We bit the bullet and merged a lot of them into one giant XAML, in fact we do this now with a pre-compiler keeping the best of both worlds. We can use as many XAMLs as we want, just following a few constraints, and merging them on a compile in a giant XAML. The performance increase we get was remarkable. In my question I wrote "11 million hits on getMergedDictionaries" ... just "precompiling" one of our assemblies, we went down to 2million hits and the performance is in the whole application at all times a lot better.

最后. XAML资源不应被视为要编译的源代码，而应将其理解为一种实际资源，该资源在声明时存在，会占用空间和性能.

So in the end. XAML resources should not be considered as source code that gets compiled, instead it should be understand as an actual resource that, when declared, exists, takes up space and performance.

好吧，我们不得不学习这种艰难的方式.我希望阅读此书的每个人都可以通过从我们的错误中学习来改善他们的项目.

Well we had to learn that the hard way. I hope everyone reading this can improve their projects by learning from our mistakes.

感谢所有评论和建议.

最诚挚的问候 尼科

这篇关于合并字典和资源查找的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！