WinUI3开发_Scale用法以及Scale是什么?和Resize的区别

Scale说明

在WinUI3中可以通过Scale来对图像进行缩放,Scale的缩放不会去修改原图像数据,而是根据锚点和要缩放的大小(可以是变大也可以是变小)计算新的要显示的坐标系进行渲染。
Scale的概念是针对于渲染层的,它主要针对于渲染器,告诉渲染器在渲染某个控件时对要显示的坐标系进行缩放,但控件的原始坐标、宽高不会发生任何变化,仅仅是渲染层的效果。
这里有一个重要点需要说明一下,Scale是属于渲染层的概念,它不属于图像类,于Resize不同,Resize是会修改图像实际宽高并使用插值算法进行填充Scale不会修改图像的任何数据,仅仅是在渲染时将渲染系得坐标进行修改,使其视觉上尺寸变了,但实际上的宽度、坐标、控件数据不会有任何改变,仅仅是渲染时根据设置的锚点以及缩放比例在渲染时候会进行公式计算,其公式如下:

x′=cx+(x−cx)×sx
y′=cy+(y−cy)×sy
x, y:原始坐标
cx, cy:缩放锚点坐标
sx, sy:缩放因子

假设一个控件左上角是 (0,0),宽高是100×100,我们想以中心缩放2倍:

cx = 50, cy = 50
sx = 2.0, sy = 2.0

控件右下角 (100,100) 缩放后:

x' = 50 + (100 - 50) * 2 = 50 + 50 * 2 = 150
y' = 50 + (100 - 50) * 2 = 50 + 50 * 2 = 150

计算后x/y的像素会得到新的渲染坐标,然后从要缩放的锚点开始一步一步扩散计算,其中在渲染时渲染器会根据渲染时坐标是扩大还是扩小来决定是填充像素还是删除像素由渲染器决定,这些仅仅是发生在渲染时,所以它不会改变原本的数据
通常我们会用来缩放Image控件,当我们对Image控件进行缩放时会发现图像跟着一起变大了,注意这里不是图像变大了,是因为控件的渲染坐标变了,而图像属于Image的Visual层数据,也就是视图数据,渲染器会渲染这部分数据到界面上,所以看起来图像像是被Resize了,实际上只是渲染大小变换的结果真实的图像数据并没有被改变,当你尝试保存Visual的数据到本地时会发现图像大小以及数据没有任何变化。

**Tips
锚点是Scale的里的原点,也就是以这个点为坐标开始进行缩放,该点的坐标不变,以该点像素向四周扩散,根据公式锚点的像素坐标会加上像素坐标-锚点坐标(这一步是为了把新的坐标以锚点为原点进行偏移),离锚点近的变化就越小,离锚点远的变化就越大

在WinUI3上面使用Scale

想要在WinUI3上面使用它也非常简单,有两种方式,一种是静态的也就是XAML方式,第二种是代码方式,首先说第一种静态的,首先定义一张Image:

<Image Source="test.jpg" Stretch="UniformToFill">
</Image>

运行效果如下:
在这里插入图片描述
Scale可以在控件元素里使用RenderTransform模块,RenderTransform是一个用来对控件在 渲染阶段 进行几何变换的属性,例如旋转、缩放、平移、倾斜等。它不会影响控件的布局位置和大小,只是改变显示时的外观,也就是渲染层的模块,在使用Scale缩放时它会使用控件的RenderTransformOrigin属性来作为原点:

  <Image Source="test.jpg" Stretch="UniformToFill" RenderTransformOrigin="0.0,0.0">
      <Image.RenderTransform>
          <ScaleTransform ScaleX="1.1" ScaleY="1.1" />
      </Image.RenderTransform>
  </Image>

运行效果:
在这里插入图片描述
可以看到图像渲染扩展到了下面的控件上面去了,我使用的是StackPanel,无视了StackPanel的布局规则,因为这是渲染坐标系变了但实际上的宽高坐标并没有变,所以没有受到StackPanel规则的限制,这样的机制就像C语言里使用指针指向const变量,然后通过指针修改该值并不违规一样的原理。
如果想通过代码实现XAML的方式也非常简单,其实代码与XAML是对应的,只不过是WinRT解释器会将XAML代码翻译成WinRT代码,我们需要使用Media功能,首先需要包含头文件以及声明对应的名字空间:

#include <winrt/Microsoft.UI.Xaml.Media.h>
using namespace Microsoft::UI::Xaml::Media;

下面是缩放代码示例:

 auto scale = ScaleTransform();
 scale.ScaleX(1.1);
 scale.ScaleY(1.1);
 TestImage().RenderTransformOrigin({ 0.0, 0.0 });
 TestImage().RenderTransform(scale);

ScaleTransform是缩放比例描述类,TestImage是要变换的控件,也是使用RenderTransform功能。
在代码实现缩放上还有另外一种方式,这个方式比较特别,它的缩放是使用控件的Visual来实现的,这些类型在前几篇文章中有过介绍,这里就不过多讲解了。
下面是它的一个代码示例:

auto visual2 = ElementCompositionPreview::GetElementVisual(TestImage());
// 设置原点,x、y、z
visual2.CenterPoint({
    static_cast<float>(yu2().ActualWidth()),
    static_cast<float>(yu2().ActualHeight()),
    0.0f
});
visual2.Scale({ 1.8f, 1.8f, 1.0f });

Visual是较为底层的实现,它的变换不会影响坐标系,仅对图像实际有效Visual进行变换:
在这里插入图片描述
可以看到图像中心区域被放大了,实现了类型图像放大的功能,但渲染坐标并没有发生变化。

搭配上动画效果

当图像搭配上Scale动画时会有不错的效果,当图片是山或轮廓分明的作为入场动画效果时缩放过程能突出主体,产生明显的视觉冲击力。
下面是使用visual实现的动画效果:
请添加图片描述
可以看到当加了这个效果之后图像控件更能突出主体,产生明显的视觉冲击力。
下面是完整代码的实现, 动画效果使用compositorVector3KeyFrameAnimation实现:

  auto visual2 = ElementCompositionPreview::GetElementVisual(TestImage());
  auto compositor2 = visual2.Compositor();

  visual2.CenterPoint({
      static_cast<float>(yu2().ActualWidth() / 2.0),
      static_cast<float>(yu2().ActualHeight() / 2.0),
      0.0f
      });
  visual2.Scale({ 1.1f, 1.1f, 1.0f });

  auto scaleAnim2 = compositor2.CreateVector3KeyFrameAnimation();
  scaleAnim2.InsertKeyFrame(1.0f, { 1.0f, 1.0f, 1.0f });
  scaleAnim2.Duration(std::chrono::milliseconds(700));
  visual2.StartAnimation(L"Scale", scaleAnim2);

上面的代码使用的是compositor的动画方法,也可以使用纯XAML实现,在XAML里可以使用Storyboard来实现动画,通过Triggers来监听事件然后执行对应的动画:

<Grid>
    <Image Source="test.jpg" Stretch="UniformToFill" RenderTransformOrigin="0.0,0.0">
        <Image.RenderTransform>
            <ScaleTransform x:Name="imgScale" ScaleX="1.1" ScaleY="1.1" />
        </Image.RenderTransform>
    </Image>

    <Grid.Triggers>
        <EventTrigger RoutedEvent="Image.Loaded">
            <BeginStoryboard>
                <Storyboard>
                    <DoubleAnimation Storyboard.TargetName="imgScale"
                             Storyboard.TargetProperty="ScaleX"
                             To="1.0"
                             Duration="0:0:1.0"
                             EasingFunction="{StaticResource EaseOut}" />
                    <DoubleAnimation Storyboard.TargetName="imgScale"
                             Storyboard.TargetProperty="ScaleY"
                             To="1.0"
                             Duration="0:0:1.0"
                             EasingFunction="{StaticResource EaseOut}" />
                </Storyboard>
            </BeginStoryboard>
        </EventTrigger>
    </Grid.Triggers>
</Grid>

上面代码使用了EasingFunctionEasingFunction是WinUI3里面设置曲线动画的属性,这样让动画不是线性的,看起来会更加自然:

<Page.Resources>
    <ExponentialEase x:Key="EaseOut" EasingMode="EaseOut" Exponent="4"/>
</Page.Resources>

XAML可以说提供了足够的可扩展性,写少量的代码实现复杂的功能,更多的时候建议使用XAML来实现UI方面的功能,因为这样才符合MVVM模型。
MVVM模型用WinUI3来说,一句话:XAML负责UI,C++负责业务,通过DataBind实现数据交互
这样代码耦合度直线降低逻辑清晰。

<think>好的,我现在要帮助用户比较WinUI 3MAUI在Windows开发中的适用场景,以便他们选择合适的框架。首先,我需要回顾之前的对话,确保信息的一致性。用户之前询问了Windows平台最新的表单开发方法,我介绍了WinUI 3、MAUI、Blazor HybridAvalonia,并给出了技术选型对比表。现在用户明确想比较WinUI 3MAUI,所以需要深入这两个框架的优缺点适用场景。 首先,我应该明确两个框架的定位。WinUI 3是微软为Windows原生应用设计的UI框架,专注于利用最新的Windows特性,如Fluent DesignWindows 11的视觉元素。而MAUI是跨平台框架,允许开发者用单一代码库构建多个平台的应用,包括Windows、macOS、AndroidiOS。用户需要的是在Windows开发中选择两者之一的依据。 接下来,我需要考虑用户可能的场景。比如,如果用户的应用只需要在Windows上运行,并且希望充分利用系统的最新功能,那么WinUI 3可能更合适。如果用户希望同时覆盖其他平台,或者未来有跨平台的需求,MAUI会是更好的选择。此外,性能方面,WinUI 3因为是原生框架,可能在性能上优于MAUI,尤其是在图形密集型应用中。 然后,我需要回顾之前提供的对比表,其中提到WinUI 3的性能是四星,跨平台仅限Windows,学习曲线中等;MAUI性能三星,全平台,学习曲线低。这可能意味着用户如果重视性能原生体验,WinUI 3更好,而如果需要跨平台支持,MAUI更适合。 用户可能需要具体的对比维度,比如开发效率、维护成本、社区支持、未来兼容性等。另外,是否需要考虑现有代码库的迁移,比如如果已经有Xamarin.Forms的经验,迁移到MAUI会更顺畅。而如果现有的是WinForms或WPF应用,迁移到WinUI 3可能更直接。 还要考虑开发工具的支持,Visual Studio对两者的支持情况,是否有热重载、调试体验等。比如MAUI的XAML Hot Reload可以提升开发效率,而WinUI 3可能需要更多手动调整来达到理想的UI效果。 另外,社区文档资源也是一个因素。WinUI 3作为较新的框架,虽然官方支持强,但社区资源可能不如MAUI,因为MAUI继承了Xamarin的社区基础。不过,MAUI在跨平台方面可能会有更多的第三方库插件支持。 性能方面,WinUI 3直接调用Windows Runtime API,可能比MAUI的抽象层更高效,特别是在处理复杂UI或高性能图形时。而MAUI由于跨平台的抽象,可能会有一些性能损耗,但对于一般业务应用可能影响不大。 未来维护更新方面,微软对两个框架的路线图也需要考虑。WinUI 3作为Windows原生开发的核心,可能会持续获得更新新特性支持。MAUI作为跨平台战略的一部分,也会得到长期支持,但可能更侧重于多平台的一致性而非单一平台的深度优化。 可能还需要提到部署目标,比如WinUI 3应用只能运行在Windows 10及以上,特别是某些特性需要Windows 11,而MAUI的Windows版本可能有更广泛的兼容性,或者相反?需要确认系统要求。 最后,总结关键点,给出选择建议,并可能举几个典型应用场景的例子,帮助用户根据自身情况做决定。</think>### WinUI 3 vs .NET MAUI:Windows开发框架选型指南 #### **核心差异对比** | **维度** | **WinUI 3** | **.NET MAUI** | |-------------------|------------------------------------------|-----------------------------------------| | **定位** | 纯Windows原生应用开发 | 跨平台应用开发(含Windows) | | **技术架构** | 直接调用WinRT API | 基于Xamarin.Forms的跨平台抽象层 | | **性能** | 原生级性能(60fps+图形渲染)[^1] | 中等性能(跨平台抽象层有损耗) | | **系统特性支持** | 完全支持Windows 11 Fluent Design | 仅实现通用跨平台控件 | | **部署范围** | 仅Windows 10/11(版本1809+) | Windows 10/11 + macOS/Android/iOS | --- #### **选择WinUI 3的场景**(优先考虑Windows深度集成) 1. **系统级功能依赖** - 需要调用Windows独有的API(如注册表操作、Win32互操作) - 集成Windows Hello生物识别或DirectX 12 Ultimate图形 - 示例:专业图像处理软件、系统工具 2. **极致视觉体验** - 要求完整实现Windows 11的Mica材质/亚克力效果 - 需要自定义标题栏或系统托盘交互 - 案例:新一代Office风格的生产力工具 3. **高性能需求** - 实时数据可视化(如股票交易终端) - 游戏辅助工具(需低延迟渲染) ```csharp // WinUI 3调用Windows系统API示例 var storageFile = await StorageFile.GetFileFromPathAsync(@"C:\data\config.xml"); ``` --- #### **选择.NET MAUI的场景**(优先考虑多平台覆盖) 1. **跨平台部署需求** - 已有Android/iOS版本需要同步更新 - 业务逻辑代码复用率需超过70% - 案例:企业级CRM/ERP移动办公套件 2. **快速迭代开发** - 利用XAML Hot Reload实时调试UI - 共享UI组件库(如统一登录模块) 3. **现有Xamarin.Forms迁移** - 已有移动端代码基础需扩展至Windows - 案例:医疗行业跨平台数据采集系统 ```xml <!-- MAUI跨平台数据绑定示例 --> <Label Text="{Binding SensorData}" FontSize="{OnPlatform WinUI=14, Android=12, iOS=13}"/> ``` --- #### **关键决策流程图** ``` 是否需要深度集成Windows特性? → 是 → WinUI 3 → 否 → 是否需要覆盖其他平台? → 是 → .NET MAUI → 否 → 项目是否要求最低硬件消耗? → 是 → WinUI 3 → 否 → .NET MAUI ``` --- #### **混合开发策略** 对于复杂项目可采用**模块化架构**: - 核心业务逻辑:.NET Standard库共享 - Windows专属模块:WinUI 3组件 - 跨平台UI层:MAUI Shell集成 ``` [数据层] ← [WinUI特性模块] ↑ ↓ [共享业务逻辑] → [MAUI跨平台UI] ``` --- #### **迁移成本评估** | **原有技术栈** | 迁移到WinUI 3 | 迁移到MAUI | |-----------------|-----------------------------------|-----------------------------------| | WPF | 中等(XAML语法相似) | 较高(需适配跨平台约束) | | WinForms | 高(需重构为MVVM模式) | 高(需完全重写UI层) | | Xamarin.Forms | 不推荐(平台特性不匹配) | 低(官方提供迁移工具) | --- ### **总结建议** - **选择WinUI 3**:若应用是Windows生态核心工具,需要系统深度融合或高性能图形处理 - **选择MAUI**:若需快速覆盖多平台,或团队已有Xamarin/.NET跨平台开发经验 - **混合方案**:对大型企业应用,可采用MAUI为主框架+WinUI 3插件扩展的模式[^2] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

17岁boy想当攻城狮

感谢打赏

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值