Flutter: ☂ 添加对 UWP 的支持

可能暂时不会，请参阅#10881。

我想把我自己包括在这个功能请求中，Flutter 支持 Windows 10 UWP 真是太棒了。

这也应该涵盖 Xbox One，您可以在 Xamarin/UWP 中定位它

是的，请。 Windows 支持肯定会改变游戏规则。

这不是官方的，但你可以检查这个项目。 https://github.com/google/flutter-desktop-embedding我认为glfw也可以在 Windows 上使用，因此您可以尝试 :wink:

伙计...我想要真正的 xplat :)

我只是在输入相同的功能请求😉...我希望这能引起一些关注！

作为我家中拥有多个 Windows、MacOS 和 Chrome OS 设备的用户……最新型号的 Surface Pro 始终是我每年的日常驱动程序； 自 SP4 发布以来。 现在似乎在校园和工作中都非常受欢迎。 然而，优质 UWP 应用程序的选择不足仍然是我最大的痛处。

我相信 Flutter 的优雅和易用性可能会提供开发人员/团队所需的激励，将 Win10 纳入他们的多平台战略......并在此过程中，希望将 Flutter 提升到与 Java 相似的地位/流行度； 在为产品开发选择工具和平台时，供 IT 执行人员考虑。

Xamarin、Ionic 等包括 UWP，那么为什么选择 Flutter？

删除分配，因为这是一个非常广泛的伞形错误。 在单个错误中跟踪特定的子任务，这将像往常一样获得特定的受让人和里程碑。

从 Window MVP 项目中删除。 我们仍在评估 UWP 作为目标，并且最终可能会支持它，但最初的重点是启用 Win32 来限制范围。

我认为这是一个错误。 自 2020 年 1 月 20 日起，所有不支持 uwp 的平台均不受支持。即，当一切准备就绪时。

当您不需要时支持旧平台是没有意义的，因为大规模迁移现在正在积极进行。

唯一的焦点应该是 uwp，而 wpf 应该被忽略。

自 2020 年 1 月 20 日起，所有不支持 uwp 的平台均不受支持

首先关注 Win32 API 的决定是技术性的，而不是基于目标平台。

wpf 应该被忽略

目前没有使用 WPF 的计划。

对不起，win32 应该被忽略。

为什么？

因为win32限制了windows平台上的flutter。 Uwp 不支持，因为当你有这个时，将不支持不支持 uwp 的 Windows 平台，但是 Windows 上的平台不支持 win32（arm64 需要完全重建）

需要明确的是，仍然欢迎并鼓励任何有兴趣为 UWP 支持做出贡献的人这样做。

但是 Windows 上的某些平台不支持 win32（arm64 需要完全重建）

ARM 上的 Windows 10 支持 Win32，您只需要在 ARM64 下编译应用程序，与 UWP 一样。

自 2020 年 1 月 20 日起，所有不支持 uwp 的平台均不受支持。即，当一切准备就绪时。

对 Windows 8.1 的支持将于 2023 年结束。它不支持 UWP。

@stuartmorgan嘿，我对 UWP 支持很感兴趣。

您在上面提到“我们仍在评估 UWP 作为目标” - 我想知道您发现了什么。

谢谢，
-杰克

@Kapranov98我刚刚完成了将 Flutter 移植到 Windows 10 ARM 的实验。 Win32/UWP 是最少的问题。 Dart 本身需要大量更改才能在 WinARM 上运行。 dart 中的 ARM 特定代码从未被设计为在除了 posix'ish 系统（ios、android、linux 等）之外的任何东西上运行。 更不用说 WinARM只支持 Thumb-2 指令集，据我了解，dart jit 使用 ARM 指令集（虽然我需要得到官方的验证）。 让港口工作将是一项相当大的努力。

@Jakesays您是否尝试将 /appcontainer 作为实验的一部分？

您在上面提到“我们仍在评估 UWP 作为目标” - 我想知道您发现了什么。

我将开始一个初始文档以尽快收集信息并从此处链接它。 不过，目前还没有很多细节（一旦初始文档存在，您的 ARM 调查结果之类的内容将非常受欢迎作为补充）。 当我说“仍在评估”时，我的意思是我们仍然计划在未来支持它，并且作为其中的一部分将评估所有需要做的事情。 由于这不是我们对初始 MVP 的关注，因此目前没有很多积极的调查。

其中一部分将涉及分解特定方面，因为正如上面的评论所指出的那样，有许多不同的元素，每个元素都有自己的挑战。

既然 Windows 10 X 是一件事，这种对话是否会改变？ Win32 将能够在 Windows 10 X 上运行，但我认为 UWP 会更合适。 Flutter 是否计划支持双屏设备？ Surface Duo 和 Surface Neo？

@nerocui据我了解，Duo 是一款 android 设备，所以我想 Flutter 可以正常工作（至少在一个屏幕上）。 我不确定 Neo 运行的是哪个 CPU，但如果它是 ARM，那么 Flutter 几乎已经死在水中了。 Dart 目前不为 winarm 生成兼容的汇编代码（winarm 专门使用 thumb-2 指令，而 IIRC Dart 使用 thumb-2 和 arm 指令）。 让它发挥作用将是一项艰巨的任务。

@JakeSays Neo 使用 Intel Lakefield，所以它是 x86。 我更关心故事的 UWP 部分。 在 Neo 这样的移动设备上，来自 UWP 应用模型的托管生命周期将派上用场。 Win32 对于电池寿命来说并不理想。 此外，Neo 上的 win32 应用程序将在容器中运行，这对性能不利。 瞄准 UWP 实际上是一个非常聪明的举措。 Android 和 iOS 都运行托管应用模型，UWP 应该带来更多的一致性。 Windows 8 几乎可以忽略不计，没有任何统计数据显示任何有意义的市场份额。

@nerocui好的，那么应该可以将目标对准 UWP。 最大的问题是 UWP 中缺乏对 OpenGL 的支持，但这应该可以通过在 Flutter 下使用 ANGLE 来解决。

我正在研究 UWP，但我的目标是 ARM/WinIOT。

@JakeSays UWP 对于大多数设备来说应该没问题，但对于 ARM 上的 Windows 来说却是一件令人头疼的事情。 具有讽刺意味的是，UWP（如果有的话）flutter 将不得不在基于 ARM 的 Windows 设备上保持模拟。 你对 Flutter/uwp 端口的完成程度如何？

@nerocui一旦我发现 Dart 问题，我就停止了工作。

虽然绝对需要 UWP，但 Win32 绝对不会去任何地方。 微软最近宣布他们正在向 Windows 应用商店添加 Win32 支持。 此外，许多游戏还在继续在 Win32 平台下开发。

是的，微软在 Store 上接受 Win32 应用程序，它在世界上比 UWP 广泛使用。 Win32 应用程序具有最佳性能，但在电池消耗方面存在限制。 Win32 只有 2 个状态 Running 或 Not Responding (Freeze)，但 UWP 有更多状态（对移动设备更友好），例如 Running in background、Suspended。

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle

电池对于笔记本电脑或 Windows 10x 设备等移动设备很重要

这应该是一个简单的对话：

截至 1 月 14 日，有 0 个受支持的 Windows 版本不支持 UWP。

在商店或其他地方部署了不支持 win32 应用程序的主要版本的 windows。

Win32 是一个遗留平台。 如果您维护的是旧系统，那肯定是 win32。 但颤振是全新的代码。 当它可以为 UWP 编写并在支持 windows 的任何地方都支持时，为遗留且不支持 arm 的 API 编写它是 0 理由。

但颤振是全新的代码。

实际上并非如此。 我已经与对添加到应用程序场景感兴趣的人进行了交谈，以允许在现有的 Win32 应用程序中采用 Flutter。

当它可以为 UWP 编写并在支持 windows 的任何地方都支持时，为遗留且不支持 arm 的 API 编写它是 0 理由。

上面的评论已经说明，支持这些设备并不是 Win32 与 UWP 的简单问题。 同样，某些部署或分发模型所需的沙盒限制将适用于引擎，这是一个大型的现有代码库，而不是绿地开发，因此也存在复杂性。

这个论点也忽略了这样一个事实，即有很多人在开发新代码，他们关心的是安装基础，而不是受支持的版本。 现实情况是，Windows 7 仍然是安装基础的重要组成部分，而且在不久的将来不太可能发生巨大变化。

支持 UWP 有充分的理由，正如我多次说过的，我们确实计划在未来支持它。 然而，为了声称决策很简单而过分简化所涉及的权衡并不会加速该过程。 同样，当然欢迎任何对 UWP 支持有强烈感觉的人为 UWP 嵌入的开发做出贡献。

@stuartmorgan您是否知道有关解决 winarm 拇指 2 唯一限制的任何讨论？

@stuartmorgan UWP 可用于 win32/Winforms/WPF 应用程序。 XAML 岛很简单并且得到很好的支持。 正如@JakeSays 所说，Win32 在 winarm 上不起作用。 因此，在将颤振嵌入遗留应用程序的情况下，你的论点是 0 意义，并且不是颤振针对遗留 API 的理由。

进一步为所有新的发展：

Windows 7 安装基数正在像石头一样下降。 WinARM 即将在明年大规模爆发。 到 7 月份，Windows 7 将占 Windows 市场的 5% 以下（不到 5000 万台设备，而且没有任何人为软件付费），并且与 Windows XP 和 Vista 一起跌至谷底（几乎完全是由于嵌入式系统由于缺乏支持，他们永远不会在不替换操作系统的情况下推出基于 Flutter 的新应用程序。

您的陈述和 Win32 的整个方法表明无法理解 Windows 版本如何扩展然后下降（在 Windows 10 无休止的修订之前，所有这些都具有 UWP，因此此流程无关紧要）：

1. 新版本发布，仅在新设备​​上且仅在消费者领域的采用速度非常缓慢。
2. （Win 7 => 10）消费设备更新更快，市场份额增长。
3. 增长受到不喜欢变化的技术极客的限制，他们声称新版本比旧版本更糟糕，即使事实并非如此。
4. 随着新版本在消费领域获得大部分市场份额，企业继续观望。
5. 随着消费者开始忽视技术极客并意识到新版本比旧版本好得多，微软宣布了对旧版本 Windows 的支持和补丁的终止日期。 采用率达到 50% 左右。
6. 企业承受来自更喜欢新版本的用户的压力； 在新版本上运行更好的软件； 以及迫在眉睫的过时最后期限开始在替换硬件上部署新版本。 采用率达到约 60-65%
7. 具有前瞻性的 IT 经理开始按组进行新版本的受控推出。
8. 截止日期迫在眉睫，其余的 IT 经理只是匆匆忙忙，抱怨问题，因为他们没有正确计划，并猛烈抨击 Windows（这些是上面的技术极客）为他们的问题。 随着支持截止日期的匆忙完成，市场份额在 6-8 个月内从 65% 上升到 90%。
9. 剩下的唯一系统是嵌入式系统，他们为安全补丁支付额外费用，因为更换这些系统的成本很高，这些系统是为以前的操作系统设计的硬件，通常需要更换硬件。
10. 嵌入式系统开始受到黑客攻击，因此企业确实获得了成本效益并开始更换硬件。
11. 只有使用操作系统的人是无法使用其他任何东西的第三世界国家，被黑客入侵不是问题。

我们现在排在第 8 位。 如果开发人员将 Windows 7 用于新软件，他们对历史一无所知。 Windows 10 的推出与之前的 Windows 7 的推出完全相同。 定位 #9 的理由是 0，因为即使硬件版本之间的 win32 应用程序存在增量波动，它们也不会推出主要的软件更新。

因此：

1. XAML 岛解决了您的增量 win32 应用程序，其中包含颤振参数。 到今年 9 月，大约 0% 的实际购买（并且不窃取）软件的人将使用无法使用 XAML island 的平台，此时 Flutter 桌面将足够稳定以用于生产。
2. 将 Windows 7 用于新应用程序没有合乎逻辑的市场。 绝对没有任何了解历史以及桌面市场如何在消费者和企业之间运作的人会在 win32 中编写新的应用程序，除非 API 上有绝对的阻止程序（这非常值得怀疑，现在 API 在很大程度上是镜像的）。 即使他们这样做了，它也会在 Windows 10 上运行，因此他们没有理由不能在那个 win32 应用程序中使用 XAML 岛进行颤动。

因此，使用 win32 的颤振决定是荒谬的，表明完全不了解 Windows 市场。 （可悲的是，这并不奇怪从谷歌出来）

@JohnGalt1717我可能弄错了，但我与 winarm 的问题与 win32 无关。 另外，这只是一个建议，但您可能想稍微拒绝一下修辞。 使用诸如无知之类的术语并提出广泛的，未经证实的主张确实会阻碍您的观点。

让 Flutter 在 winarm 上运行并非易事，正如该线程中多次指出的那样。 让 Flutter 在 win32 上运行是一项相当简单的工作，因为它需要对 Flutter 本身进行少量更改。 从容易实现的目标（win32）开始是有意义的，特别是考虑到我所看到的关于 Flutter 和 windows 的大部分兴趣都与桌面有关。 这与 win32 与 uwp 几乎没有关系，更多的是与现实情况有关，即现在有很多 win32 系统。

@JakeSays WinArm 不允许将 win32 应用程序发布到 Arm 上的商店。 （Office 除外）除了编译问题。

我的主张有哪些没有得到证实？ 数据 100% 支持我的立场。 当 Flutter for desktop 准备好在 Windows 上发布时，将有 5% 或更少的 Windows 机器无法运行 UWP，还有大量您无法部署 win32 应用程序。 （即所有 ARM 设备，包括 Duo 或 Neo 或任何运行 Windows 的设备，以及所有正在升级的第 3 方版本。）

在适用于 WinArm 和 WinX64 和 WinX86 的 UWP 下运行 Flutter 应该不会比 win32 更难。 它还可以让你在文本框等中进行拼写检查，基于 DPI 进行适当的缩放，而不需要英雄，以及开箱即用的更好的文化支持。 （更不用说媒体播放比win32好得多，也更容易。即我可以在UWP中用3行代码轻松播放widevine，playready，AES加密视频。在win32中做同样的事情是一项巨大的努力。更不用说字幕了.

win32 与 UWP 没有“容易实现的目标”。 UWP 是桌面。 其他一切都是旧版桌面。 （显然是 Silverlight 除外）他们正在重新移植 UWP，它是用于遗留平台的 API，以支持不重写其应用程序的公司。 他们为将 Flutter 添加到现有应用程序（以及其他任何 UWP）的用例添加了 XAML 岛。

“现在有很多 win32 系统”。

以下是 9 月份图表的样子：到 9 月份，5% 的运行 windows 的人将被锁定。 在这 5% 的人中，几乎没有人根据历史数据购买软件。 到 10 月，5% 的 Windows 用户将在某种形式的 ARM 上使用它，并将被锁定在 Win32 之外。

所以选择你的毒药。

但是请注意，当您这样做时，被 UWP 锁定的人数将不断减少，而被 Win32 锁定的人数将不断增加。 因此，如果您使用 win32 而不是 UWP all，那么您实际上可以保证在 12-24 个月内重写，因为您无法有效地支持一个垂死的市场，因为微软不会修复 Windows 7 中的错误，只有安全性为他们付费的人的更新。 （无论如何都不会使用带有颤振的应用程序）

它还确保 Windows 版本的视频播放器将始终受到极大限制，因为要使 DRM 在 Win32 上运行需要大量提升，不会有内联拼写检查器或自动更正那些使用软件触摸键盘的人，而文化的东西将更难正确。

这被称为逆向思维。

如果你不喜欢无知这个词，那不是我的问题。 如果您不了解事实和历史，那么根据定义，您就是无知。 在这种情况下有害如此。 如果您想使用尚未被禁止的社交正确词，请告诉我您希望我使用什么，我会查找并替换。

告诉我我实际上错在哪里。 即使我的假设和预测略有偏差，请告诉我，随着时间的推移，我的断言是不正确的，而且与替代方案相比，它的危害性和工作量更少随着时间的推移，其他平台用于视频、拼写检查等。无论你如何分割它，到明年这个时候，几乎没有人会使用 Windows 7。这意味着 Flutter 将 100% 可供几乎每个人使用如果它是在 UWP 而不是 win32 中完成的。 与 win32 相比，它迎合了死机的操作系统并将开发者锁定在 WinARM 的新的和不断增长的市场之外。

例如，我现在可以在 UWP 中创建一个视频播放器，它具有当前视频播放器的所有功能，加上 UWP 中的字幕和 DRM，并在几分钟内提供优秀的文档，Flutter 可以将其作为颤振视频库。 我知道他们现在正在为颤振视频播放器开发字幕和 DRM。 除了 UWP 调用之外，我什么都不需要知道。 这意味着使用 UWP 在 Flutter 中提供完整的视频功能是微不足道的，几乎任何 C# 都可以做到这一点，这与那些知道如何使用 C++、创建 DirectX 表面以及创建媒体编码器/解码器/转码器和把它全部连接起来。 （是的，在 win32 中，如果没有 UWP 开箱即用支持的自定义库，您将无法播放许多格式）在 UWP（即使用 C++ 编写）与 win32 之间创建相同产品的努力大约是 1/100多少时间。

串行通信、蓝牙、位置跟踪等也是如此（位置跟踪和传感器 API 刚刚在 Windows 10 2020/H1 中进入 win32，并且在以前版本的 windows 中不起作用10 所以你依赖于使用最新版本的 Windows 10 的每个人甚至可以访问此功能，而 Windows 10 中 100% 的用户可以访问这些 api 的 UWP 功能。）命名你认为理所当然的功能使用适用于 Android/iOS 的 Flutter 插件，您会看到同样的事情：在 UWP 中实现它们与 win32 相比是微不足道的，因此您更有可能在 UWP 中实现它们，而不是在 win32 中为桌面编写 Flutter所有其他问题。

@JakeSays还在等你证明我所说的任何不尊重（或错误）的地方。 据我所知，你只是不喜欢我正确使用的一个词。 而且，最重要的是，我在摘要中使用了它，而不是针对您或其他任何人。 这不是广告同音词攻击。

@stuartmorgan您是否知道有关解决 winarm 拇指 2 唯一限制的任何讨论？

@Jake说我没有关注 Dart 编译器级别的讨论； 我不知道有关 ARM 支持的讨论，但这并不意味着它们没有发生。 如果您还没有提交 Dart 功能请求，则绝对应该提交。

最大的问题是 UWP 中缺乏 OpenGL 支持，但这应该可以通过在 Flutter 下使用 ANGLE 来解决。

当前的 Windows 嵌入已经使用 ANGLE，并且 James 从他从事嵌入工作的早期开始就一直在试验 UWP 支持，因此这已经在进行中。

@stuartmorgan我会这样做的。
是的，我忘记了 windows embedder 正在使用 ANGLE。

@JohnGalt1717 ，请查看我们的行为准则。 Flutter 的社区标准需要专业和尊重的话语，并积极地尽最大努力让人们感到受欢迎。

有很多热情和才华横溢的人致力于 Flutter，并且有很多充分的理由追求或不追求特定的发展路线。 我可以告诉你，你热衷于让 Flutter 在 UWP 上工作。 其他人也是如此。 有些人还热衷于让它在 win32 上运行。 这是一个开源项目，实现它所需要的只是贡献。 同时，请避免暗示从事替代路径的贡献者无知、浪费时间或从事倒退思维。

如果您看不到为什么您最近的几篇帖子未能达到我们在这个社区中渴望的相互尊重的水平，请扮演一个不那么积极的角色。

/cc @timsneath @Hixie

@dnfield鉴于我没有做任何我看不到你的意思的事情。 我概述了事实历史，以及确保必须重写且不会与其他平台相提并论的路径。

如果您仔细阅读，我绝不会称任何人无知（字面意思是不了解事实，不是贬义，本身就是事实陈述），我也没有指责任何人的倒退思维。 （即针对一个遗留平台，该平台会在 1 月 14 日之前将你与未来隔绝，同时拥抱一个死去的、越来越不相关的过去）

所以我无法理解任何人会被冒犯，除非他们决定认同我使用的一般性并且我无法控制。

如果您对未发表的关于您的陈述感到冒犯，那么我很抱歉您有这种感觉。 也许解决方案是认真对待我的立场并从逻辑上思考它并证明您确实考虑到了这些事实并且并非无视它们并且您对win32如何在需要的Windows上工作有一些长期计划store 并且该商店不允许发布 win32 arm 应用程序。 并且使用 win32 的开销将确保 windows 始终落后于其他平台，因为您通过此选择将可能的贡献者减少了 90% 以上。 那你就清楚了，你既不是无知，也不是思想落后，所以我说的不应该得罪你。

相反，我得到“我被冒犯了（关于一些不是针对我的事情），因此你错了”。 这不是任何辩论中的论点。

鉴于我的立场无论如何措辞都没有得到解决，很明显，flutter 不太可能及时成为 Windows 上的可行解决方案，并允许为 iOS、android 和 Windows 编写的应用程序平价。 这确保了我的团队不会按计划在我们的下一个项目中使用颤振，因为你强迫我们使用至少 2 个框架（因此至少 2 种编程语言）作为这个决定的结果，所以我不妨选择一个即使有更多的开销，也要追求卓越而不是妥协。

自从他在嵌入工作的早期开始，James 就一直在试验 UWP 支持，所以这已经在进行中。

@stuartmorgan @clarkezone有没有在 UWP 上运行 Flutter 的公开示例？ 即使它处于非常早期的阶段，我也很想尝试一下。

我目前正在开发 UWP 支持的原型。 现在还为时过早（例如，我还没有看到像素），但我确实有一个如何去做的计划。 这将取决于对我之前所做的角度更改的小修改。我已经编码但尚未提交给角度。 免责声明：这并不构成交付某些东西的承诺，它仍然是对可能性的探索。 当我取得更有趣的进展（例如像素）时，我会在这里报告。

感谢您的及时回复@clarkezone

我在您的 FDE fork 中发现了一个名为uwptest的分支。 它是你正在试验的那个吗？ 我很乐意关注您对这条路线的更新。

NP，是的，那是 FDE 分支。 短期内会有很多临时黑客来证明某些理论。

嗨，@clarkezone！ 请问，你的工作有微软支持吗？ 我们可以期待微软支持 Flutter 来创建 Windows 应用吗？ 如果是这样，是否有让 UI Fabric 可用于 Flutter 的计划？

我认为，最近人们对构建漂亮的企业软件以提高员工敬业度/满意度越来越感兴趣。 我目前正在从事一些这样的项目。 就在最近，我们为四大金融公司之一发布了基于 Flutter 的 Android 应用程序。 虽然这些企业倾向于在其内部软件中使用 C# 和 Xamarin，但他们希望为他们的工作场所体验移动应用程序提供更高质量的 UI——在这种情况下，Flutter 被证明是一个更好的选择。 同时，Microsoft 生产了用于企业环境的出色设备，可以运行这些 Flutter 应用程序，因此很高兴看到 Microsoft 和/或 Google 提供更多支持来实现这一目标。

嗨卢卡斯。 我的工作没有 MS 的支持，它是在我的空闲时间以个人为基础完成的。 肯定同意你的其他观点。 FWIW 我取得了一些相当不错的进展，我有原型 Flutter runner 端到端工作以进行输出/渲染（还没有输入），我目前正在处理的大/下一个任务是让所有内容正确链接而无需拉动在 user32/gdi32 等中。这一步是能够成功看到原型在非桌面设备上运行所必需的，例如 XBOX、Windows 10x 模拟器，并且被证明是（另一个）yak shave :-)

请添加 Windows 商店！！！！

@daniele777这就是我一直在做的事情；-) 状态更新：从 84 个链接器错误减少到 10 个

我能提供帮助吗 ？？ 改善项目？？ 可以做我的任务吗？

@daniele777 目前还没有，仍在使基本的 PoC 正常工作。 链接器错误已清除，但在调用 Dart 时出现构建问题，进入构建管道中的无限循环。 还有其他问题。 我将休假几个星期，因此一旦我回来并且我们已经完成 PoC 阶段，可能会有一些可并行的项目，我将在此报告这些项目。

好吧，一切顺利！

迫不及待地想尽快到达这里。 我在 Windows 上尝试了当前基于 win32 的颤振。 天哪，渲染是如此像素化，以至于它看起来像是现代设计，但使用了 10 年的老框架实现。 这不是人们期望在 4k 屏幕上看到的东西。 习惯于 UWP 应用程序和现代 Web 应用程序中文本的平滑边缘，win32 渲染看起来非常过时。

@nerocui - 如果您在 Windows 上看到像素化渲染，这很可能是一个不同的错误，仅通过迁移到 UWP 就无法修复。 您能否提交一个关于该问题的新问题，并附上重现步骤（也许是像素化的屏幕截图）？

@dnfield这不像图像是像素化的。 只是文本和形状在没有硬件加速的情况下被渲染（看起来像），所以边缘看起来不平滑。 我看到的很多win32程序都会发生这种情况。 没有复制步骤，因为它只是默认模板页面上的文本和按钮。

@nerocui这是因为与 UWP 相比，win32 应用程序没有适当的 DPI 缩放。 使win32文本渲染正常工作可能需要大量工作，但这非常困难。

@JohnGalt1717谢谢，这正是我的意思。 Flutter 应该是关于构建漂亮的跨平台应用程序，但 win32 是让应用程序变得丑陋的唯一因素。 它使 windows 上的颤振实现看起来不如其他平台。

win32 是让应用程序变得丑陋的唯一原因

正如@dnfield所说，这种情况极不可能发生。 Flutter 文本渲染完全由 Skia 完成，进入（针对 DPI 适当缩放）GL 上下文。 使用 UWP API 创建 GL 上下文不会改变渲染。

请提交一个带有屏幕截图的错误，突出显示您所描述的问题。

例如，它可能就像在某处忽略抗锯齿标志的嵌入一样简单。 但是如果没有重现的步骤，我们无法判断。

https://github.com/flutter/flutter/issues/53308
提出的问题。 请查看它是否准确/足够的信息。

我猜如果您将 DPI 设置为 150% 或更差的 175% 并加载一些文本，您会看到它。

请停止在此处发布有关渲染的详细信息； 根据我上面的解释，它与这个问题无关，因此离题。

准备好在 Windows 商店上发布了吗？ 任何新闻？

不，尚未准备好发布到商店。 像素和输入在 XBOX 和 Windows 10x 上运行。 仍在对 API 进行迭代。 还有很多工作要做。

我一直在考虑一种稍微不同的方法 - 我还没有尝试过，但如果我有空闲时间可能会这样做 - 在桌面上使用带有 Skia WASM 的 Flutter for Web 怎么样（可能由 Blazor 支持）？ 我可以认为对 I/O 的访问受限是一个缺点，但实际的 UI 呈现和事件处理应该按预期工作。 Windows 似乎对 PWA 有很好的支持（Chrome 操作系统也是如此），这种方法可能更容易实现，同时仍能获得良好的性能。

@lukaszciastko不，那将是另一个 Electron。 Flutter 应该被渲染到原生 Windows 窗口（HWND）中，然后它可以嵌入到任何类型的原生 Windows 应用程序（win32、Winforms、wpf）中。
恕我直言 uwp 不应被视为主要的 Windows 应用程序。 连MS都没有。

@clarkezone我迫不及待地想看到你的工作融入到项目中，这样我们就可以在 Windows 上运行应用程序

所以我们可以在 Windows 上运行应用程序

在 Windows 上运行 Flutter 应用程序已经成为可能，并且已经有一段时间了。 这个问题现在专门针对 UWP。

我将更新标题以使其更清晰。

所以我们可以在 Windows 上运行应用程序

在 Windows 上运行 Flutter 应用程序已经成为可能，并且已经有一段时间了。 这个问题现在专门针对 UWP。

我将更新标题以使其更清晰。

Stuart，我在文档中没有看到关于如何在 Windows 上构建和运行 Flutter 应用程序的任何地方。 你能告诉我在哪里可以找到这些信息吗？

@steskalja你在这里有一些文档https://github.com/flutter/flutter/wiki/Desktop-shells#create
在简历中，您必须在master分支中运行：
flutter config --enable-windows-desktop

在你想尝试的项目中：
flutter create . // 会添加windows文件夹，注意android和ios文件夹的变化，
flutter run -d windows

更具体地说，我对这个开发的想法。 就是希望和Project Union有一些关系。 我喜欢颤振，很高兴这个 SDK 是一个东西。 我担心 Windows 操作系统中 Win32 应用程序的未来。

Flutter 团队有哪些知识库？

当你完成这一步后，是否意味着我们可以在 C# 中实现 Flutter 插件并从插件中使用 UWP 应用程序可用的任何 API、SDK 和 NuGet 包？

@kinex我很想知道为什么你会认为这两者相关。 为插件添加 .net 支持相对简单，并且不需要 UWP。 不过，这有点超出了颤振的范围。

@JakeSays 据我了解，执行环境（在本例中为 UWP）定义了插件的创建方式以及插件可用的内容。 所以也许我的问题的答案是“当然”，但我并不完全确定。

在 Android 插件中，您可以使用 Kotlin（或 Java）和任何 Android API、SDK 和包。 在 iOS 插件中，您可以使用 Swift（或 Objective-C）以及任何 iOS API、SDK 和 Pod。 我希望 UWP 也能做到这一点，它会让这非常棒。

让在插件中使用 C# 变得更容易是我们打算做的事情，但与 UWP 支持是正交的。

UWP 运行器意味着能够在插件中使用特定于 UWP 的 API，但我的理解是很少有 API 实际上是特定于 UWP 的（例如，根据本文档“一般规则是桌面应用程序可以调用通用 Windows 平台（UWP）API。”）

@stuartmorgan这实际上不是真的。 最终，项目重聚将是真的，但不是现在，即使那样，它也适用于遗留软件，而不是像颤振那样的新应用程序。 如果没有 UWP，您将无法完成大量工作（即访问各种视频编解码器的插件、DRM 视频播放器等），这就是为什么我一直对 Flutter 团队采用的方法有疑问的原因. 微软支持的操作系统（因此是安全的）有 0 个操作系统无法在市场上运行 UWP（即针对 Windows 7 是荒谬的，不应该成为 Flutter 的目标，只有 Windows 10 应该是目标）。 因此，从第一天起这不应该是本机 UWP 的原因为 0。

更糟糕的是，所有 Windows 10 S 和变体都无法运行 win32 应用程序，因此 Flutter 将被锁定。 它们也将被 ARM/ARM64 设备锁定，除非它们在 UWP 和 Windows X 上运行，使用远程桌面在 docker 容器中运行 win32 应用程序，结果将比原生 UWP 应用程序体验更差，尤其是在涉及到图形性能。

因此，如果 google/flutter 对 Windows 支持进行前瞻性思考，那么它从第一天起就完全是 UWP，它允许 C++ 和 .NET（绝大多数 Windows 开发人员使用 .net，而不是 C++）并以最好的方式支持所有当前和未来的 Windows 设备可能的交互性。 当前的 win32 方法既短视又缺乏研究（这表明 Google 内部存在一个非常巨大的盲点，考虑到运行 Windows 的十亿多台设备，这令人担忧）。

鉴于 Skia 已经在 UWP 上运行，几乎没有理由说明这不会成为事实上的环境以及 100% 谷歌在 Windows 上努力的重点。 （实际上，与微软合作以获得整个 Xamarin 远程模拟器并直接部署到 Windows 上的 iOS 设备也能正常工作）

@JohnGalt1717你已经在这个问题上多次提出过这个论点； 重复它是没有建设性的。 如果您想加速 UWP 支持的开发，欢迎您为它做出贡献。

@stuartmorgan我很想知道您对使用 c# 的想法。 我对如何使这项工作有一些想法。

@kinex实际上，flutter 插件本质上只是通过简单的 api 与 flutter 交互的 C 代码。 用 C# 编写它们基本上需要一个用 C 语言编写的“.net 插件”，它可以承载 CLR 并连接颤动世界和 c#。 理论上可以在windows上用java或者任何语言编写flutter插件，只要语言环境可以在目标操作系统上运行。

@JakeSays我用我目前对 C# 的想法提交了https://github.com/flutter/flutter/issues/64958 ，因为我显然从未在这里提交过。 任何对 C# 感兴趣的人都应该关注这个问题。

@JakeSays好的，感谢您的澄清。 如果没有更好的知识，我假设是这样的：C# 插件（可能实现为 .NET 库？）将由 UWP 运行程序加载，Dart 代码可以通过 UWP 运行程序进程调用它们。 在这个虚构的架构中，这些 C# 插件可以访问与 UWP 应用托管的任何 .NET 库相同的 API、SDK 和 NuGet 包。

无论如何，很高兴知道有关于 C# 支持的计划。 如果可以使用 C# 而不是 C++，我相信会有更多的插件作者（=更多的插件更快）和更稳定的插件。

@kinex你说得对，c# 插件可以访问完整的 .net 库集以及 nuget 包。 执行 c# 代码时，它会在完整的 .net 环境（或 .net 核心，视情况而定）中运行。

FFI 是一个更轻量级的插件解决方案。 例如，参见https://pub.dev/packages/win32 。 但这对于一个表面上是关于构建基于 UWP 的运行器的问题来说离题太远了。

@timsneath我认为 ffi 和插件解决了两个不同的问题。 iirc 对 ffi 可以做的事情有很多限制（例如它是同步的）。

同样，我为 C# 插件提交了#64958； 请继续任何关于 C# 但不是 UWP 的讨论。

好事发生
有人应该告诉微软也在这里做出贡献

@airbus5717你是什​​么意思？ 微软一直在为这里的讨论做出贡献。

我认为值得分享 2020 年 9 月关于我一直在从事的 Flutter UWP 实验状态的更新。 进展比我想的要慢，因为这是一个业余时间/尽力而为的项目，我只在晚上和周末工作。 但是，在过去六个月左右的时间里，我已经取得了相当大的进步，并让一些场景发挥作用，即：

• 使用CoreWindow与在 AppContainer 沙箱中运行的 WinRT 输入 API 结合使用的概念验证 WinRT Flutter 嵌入器： https ://github.com/clarkezone/engine
• 一个对应的测试 Flutter UWP runner（只有 115 行 c++！），使用Flutter Gallery演示 Flutter 体验： https ://github.com/clarkezone/fluttergalleryuwp
• 使用这些我能够成功地将 Flutter Gallery 的 MSIX 打包版本发布到 Microsoft Store，通过 WAC API 检查以获取商店认证（最后:-)）

仍然需要做大量工作才能将其用于生产就绪，我不知道这需要多长时间，但它肯定表明 Flutter UWP 是可行的。

还有一些较大的剩余问题需要解决，例如如何与flutter create进行工具集成，如何获得热重载和观察支持工作等等。 更多细节在这里。

在下面的示例中，我能够从https://github.com/miickel/flutter_particle_clock获取Flutter Particle 时钟的源代码，以针对 Windows 的发布模式构建它，获取生成的app.so二进制文件，将其打包为UWP 使用与上面用于 Flutter Gallery 相同的 Flutter Runner，发布到 Microsoft Store 并安装在我的 XBOX 上：