Question

已经有一段时间了，我对以下内容感到不满。假设我们有一个具有此默认样式的控件：

<Style TargetType="r:PhoneButton">
  <Setter Property="Background" Value="Transparent"/>
  <Setter Property="BorderBrush" Value="{StaticResource PhoneForegroundBrush}"/>
  <Setter Property="Foreground" Value="{StaticResource PhoneForegroundBrush}"/>
  <Setter Property="BorderThickness" Value="{StaticResource PhoneBorderThickness}"/>
  <Setter Property="FontFamily" Value="{StaticResource PhoneFontFamilySemiBold}"/>
  <Setter Property="FontSize" Value="{StaticResource PhoneFontSizeMediumLarge}"/>
  <Setter Property="Padding" Value="10,3,10,5"/>
  <Setter Property="ActiveMargin" Value="{StaticResource PhoneTouchTargetOverhang}"/>
  <Setter Property="Template">
    <Setter.Value>
        <ControlTemplate TargetType="r:PhoneButton">
            <Grid Background="Transparent">
                <Border BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}" Background="{TemplateBinding Background}" Margin="{TemplateBinding ActiveMargin}">
                    <ContentControl ContentTemplate="{TemplateBinding ContentTemplate}" Content="{TemplateBinding Content}" Foreground="{TemplateBinding Foreground}" Padding="{TemplateBinding Padding}"/>
                </Border>
            </Grid>
        </ControlTemplate>
    </Setter.Value>
</Setter>
</Style>

上面的模板有点简化，但它的编写方式与标准的Button模板相同。（实际上我们采用了标准模板并对其进行了一些调整。）

然而，我无能为力，但看到了几个性能问题：

首先将填充初始化为0，然后更改为（10,3,10,5）。如果我们从样式中删除了setter并使用了默认属性值（10,3,10,5），我们会失去什么？
BorderBrush也是如此。我们可以使用默认值而不是样式设置器（刷）Application.Current.Resources [ “PhoneForegroundBrush”]
上面的画笔可以是静态的，并可以重复用于前景默认。
等。我们可以摆脱所有风格的制定者。该样式现在只包含模板定义。但是，即使这样也可以转移到代码中。（我们可以使用方法XamlReader.Load（）从字符串加载模板。）
使用TemplateBinding肯定比标准绑定更快。但是，如果我们在代码中有模板，那么对于在我们的类中定义的DependencyProperties（例如ActiveMargin），我们可以选择完全删除绑定：我们可以使用PropertyChangedCallback。

如果您认为我们只能使用上述技术获得花生，那么这里有一个具体的例子：我有一个包含11个相当复杂的控件的表单 - 每个控件都由2个或更多更简单的控件组成。使用上述技术后：

初始表单加载速度提高了25％
后续的表单加载速度提高了40％。

我测量的是输入页面构造函数和页面Loaded事件之间所花费的时间。因此，测量的时间也包括页面初始化。（该页面包含带有自定义图标的标准标题和应用程序栏）。换句话说，实际的业绩增长大大高于上述25/40％。

我的问题： 使用上述优化后，您会看到哪些问题？

Answer 1

您似乎正在消除灵活性（绑定数量和可配置属性）以及为每个模板化项目所做的更改次数，以提高性能。

实现灵活性变化的后果意味着，如果您需要，将来您将没有那么多的灵活性。根据应用和您的情况，这可能是也可能是不可接受的。 - 如果你正在为一个应用程序构建一些东西，那么它应该不是问题。（不要担心将来可能遇到的小问题。）但是，如果你正在开发一个控制计划重新使用，那么它的灵活性可能很重要。

关于模板效率

1 个答案: