检测到论坛CSS可能没有正确加载,如出现排版混乱请刷新重试。

We detected that the CSS might not be loaded correctly. If the website displays abnormally, Please refresh and try again.

  • Windows
  • 微软笑话之:蛇精病的“照片”应用

CPU占用翻倍,内存占用翻倍,bug数量翻倍,闪退概率翻倍,右键菜单砍亚克力,不能记住窗口位置和大小……

总结:

微软傻逼!

实际上微软昨天推送了一些版本,修复了一些问题。而且,WinAppSDK版本直接打开照片的速度非常快。比原来上了几个台阶。

在这个资源富足的年代,为了实现软件更好的性能,适当增加资源开销是合理的。


另外,Windows Latest的新闻少看,具体原因:ThinkBou

    ThinkBou 并没有……如果是已经打开过照片,新版的加载速度确实比旧版的快那么肉眼不可见的一点点,但如果是重启后第一次打开,那就得转两次圈(都是直接从桌面打开照片文件)

    另外,这货为什么不能记忆窗口位置和大小?

      熊猫火狗 为什么不能记忆窗口位置和大小?

      一般的 Windows 程序都不会记忆窗口位置和大小,UWP 是个特例。
      UWP 框架会把程序窗口的位置和大小写到注册表里面。

        熊猫火狗 要么是开发软件的框架自带这个功能(比如 UWP),要么是开发者自己实现了这个功能。
        直接使用 Win32 API 的 Win32 程序,WinForms 程序和 WPF 程序,如果不自己想办法记录窗口大小,那就没有这个功能。
        WinUI 3 程序同理。

          Baka632 我感觉很大一个原因是 WASDK 自身并没有记录窗口大小和位置的 API,在我的印象里,WASDK 的应用想要记录窗口大小,就必须调用 Win32 的 API,总之就是没有 UWP 那么方便了。

          BTW,最新版本 WASDK 版本的照片(11050.29009)已经能记住图片查看窗口的大小和位置了,只是图库主窗口暂未支持。

            FYI,在 Windows Latest 原始报道中,提到了性能缓慢的因素,很重要的原因是新版照片很多界面基于 Web,例如照片的编辑界面就是 web based,启动时会默认加载这些 WebView2 组件,这一机制很大程度上拖累了启动的速度。

            然而这一点,某红白图标新闻平台丝毫不提,直接剪掉了,真的是新闻学典范。我个人并不推荐在国内尤其某红白图标的新闻平台看 Windows 讯息,断章取义的情绪营私太严重了。

            ThinkBou 而且,WinAppSDK版本直接打开照片的速度非常快。比原来上了几个台阶。

            正如三楼所说,单纯看加载图片的速度,WASDK 版本的速度要远快于 UWP,这得益于 WASDK 平台自身更为优秀的机制与特性,与微软工程师过去数年对 dot net 和 WASDK 的性能改进。

            最后,我很高兴看到 Windows App SDK 公开发布了第一个原生支持 NativeAOT 的版本(1.6-exp1),这代表 WASDK 接收 UWP 的遗产已经到了尾声(不过楼主提及的照片还没上)。对于不知晓的人:UWP 应用启动速度快且内存占用低,很大程度上得益于 UWP/WinUI2.x 混合编译了 dot net Native,但微软在 WASDK/WinUI3 开发中为了对齐 dot net 平台的技术栈,暂时选择回归 JIT 方案。

              Stakarilky FYI,在 Windows Latest 原始报道中,提到了性能缓慢的因素,很重要的原因是新版照片很多界面基于 Web,例如照片的编辑界面就是 web based,启动时会默认加载这些 WebView2 组件,这一机制很大程度上拖累了启动的速度。

              最好也别看Windows Latest的小作文,他们自己都搞不明白。实际上打开图库的时候根本不加载web框架的内容,只有照片编辑器在用。如果打开图库的时候加载web框架的内容,那么直接打开照片也会慢……

              之家裁剪掉已经算是比较追求事实了。

                Betta_Fish 因为现在这部分东西(map)给Azure了,原来那套基本上废了

                Stakarilky 我怎么记得老版照片(不是那个照片旧版)的编辑页面也是网页套壳呢?

                然而刚刚打开发现不是,我又记错了吗?

                  熊猫火狗 那就不知道了,反正 WinUI 自带的 MenuFlyout 有亚克力背景
                  请看下图效果:

                    Betta_Fish UWP最有代表性的的InkCanvas还没上呢(

                    在 WASDK 的路线图中,它们计划在 1.7 版本中提供 Inking control

                    ThinkBou 最好也别看Windows Latest的小作文,他们自己都搞不明白。实际上打开图库的时候根本不加载web框架的内容,只有照片编辑器在用。如果打开图库的时候加载web框架的内容,那么直接打开照片也会慢……

                    之家裁剪掉已经算是比较追求事实了。

                    实际上,在某家的网页上,这篇新闻标题下摘要写的是

                    科技媒体 Windows Latest 在最新博文中指出,Windows 11 照片(Photos)应用升级至最新 2024.11050.3002.0 之后,拥抱 WebView2 的“副作用”就是打开时间比以往更长了。

                    (然而,正文中搜索 WebView 查无此词,所以我说是“剪掉”了)

                    对于你说的内容,在一番尝试后,我发现这玩意启动时确实不会连带 WebView。但会耗费大量资源联网接受数据,这些网页内容的加载一定程度上拖累了应用的启动速度。为了验证,计算开机后第一次启动的速度,在断网的情况下,确实启动速度加快了,怀疑跟 OneDrive 同步等乱七八糟的东西有关。Web 技术确实让这个应用更慢了。

                    仔细嚼了原文的用词,发现原作者似乎也在营造情绪陷阱,把 Photos 的慢与读者对 Outlook PWA 的不满进行关联,并在人们难以验证的点上把 WebView2 树立成稻草人……果然新闻学定律不削不能玩

                      熊猫火狗 InkCanvas是那堆笔工具?

                      这是一个 Custom Control,类似新 Explorer 中的地址栏,并不是 Gallery 中的标准控件

                      熊猫火狗 右键菜单亚克力呢?

                      Baka632 那就不知道了,反正 WinUI 自带的 MenuFlyout 有亚克力背景

                      Photos 的右键菜单并不是调用标准的菜单,是一个基于 MenuFlyout 的自定义控件,边角的 Padding 就很明显。
                      不过理论上 UWP 的自定义控件样式直升到 WASDK 需要改的应该很少,微软估计是脑子抽了先把亚克力砍了

                        Stakarilky 这是一个 Custom Control,类似新 Explorer 中的地址栏,并不是 Gallery 中的标准控件

                        查看SnippingTool的XAML,仍然可以看到这是一个标准InkToolbar,只是删了几个按钮


                        Photos 的右键菜单并不是调用标准的菜单,是一个基于 MenuFlyout 的自定义控件,边角的 Padding 就很明显。

                        再对比一下右键菜单的XAML结构...可以说非常相似
                        很可能是把标准的菜单拿过来改了一下样式

                        标准WinUI3菜单(来自Pixeval)

                        Photos

                          © 2025 wvbCommunity 管理团队

                          删封申诉 | 知乎专栏 | 状态监控 | 用户协议(EULA) | 隐私政策

                          本站文章除其作者特殊声明外,一律采用CC BY-NC-SA 4.0许可协议进行授权,进行转载或二次创作时务必以相同协议进行共享,严禁用于商业用途。