Did, you know 22 years ago, Visual Basic 6 was released? I know, you probably feel really old right now. But it was released at a different time, a time when RAD (Rapid Application Development) was all the rage.

您知道22年前发布了Visual Basic 6吗？ 我知道，您现在可能真的很老。 但是它是在另一个时间发行的，当时RAD(快速应用程序开发)风行一时。

20 years later, and software development and design has changed considerably. But somehow, the company that gave us the OS (Windows), has given us the weakest tooling to make apps for its own OS. How did we get here?

20年后，软件开发和设计发生了巨大变化。 但是不知何故， 为我们提供了操作系统(Windows)的公司为我们提供了最弱的工具来为其自己的操作系统制作应用程序 。 我们是怎么来到这里的？

To understand this, we need to go on a journey through the history of making apps for Windows computers. It’s a bit of a detour but I’m making a point, I promise.

为了理解这一点，我们需要遍历为Windows计算机制作应用程序的历史。 我保证要绕道而行，但我要指出一点。

这一切都始于Win Forms (It all started with Win Forms)

When everyone (thankfully) moved on from Visual Basic 6, the next thing we had was WinForms. WinForms was great in that it maintained a lot of the drag’n’drop design that made making apps a breeze. But, your produced app would be pretty bland. Sure, there were custom controls and other things you could do to spruce up your app, but out of the box, it was the standard look and feel.

当所有人(感谢)从Visual Basic 6继续前进时，我们接下来要做的就是WinForms。 WinForms很棒，因为它保留了许多拖放式设计，使应用程序变得轻而易举。 但是，您制作的应用程序会非常乏味。 当然，您可以做一些自定义控件和其他事情来修饰您的应用程序，但是开箱即用，这是标准的外观。

WinForms apps also struggled with a very strong coupling between the business logic and the UI (User Interface) logic. This came from most of the actions in a standard WinForms app to be events, and those events being handled by something like an OnClick handler. At that point it was super easy to just throw all your business logic in that code and call it a day. Too often this was the case, leading to codebases that become harder and harder to maintain.

WinForms应用程序还难以在业务逻辑和UI(用户界面)逻辑之间实现非常牢固的耦合。 这是由于标准WinForms应用程序中的大多数操作都是事件，而这些事件是由诸如OnClick处理程序之类的事件处理的。 那时，将所有业务逻辑都放入该代码中并每天调用它是非常容易的。 这种情况经常发生，导致代码库变得越来越难维护。

Consequently, this made testing a nightmare. How would you write unit tests when your business logic was all caught up in the code behind? Sure, you could write actual tests to interact with your UI and assert an outcome. But that was pretty much it.

因此， 这使测试成为噩梦。 当您的业务逻辑全部被后面的代码所困扰时，您将如何编写单元测试？ 当然，您可以编写实际的测试来与UI交互并声明结果。 但是，仅此而已。

然后出现Windows Presentation Framework (And then came Windows Presentation Framework)

Windows Presentation Framework (WPF) was released with much fanfare in 2006. Finally, beautiful, graphical applications could be produced for Windows. It used XAML for the UI, and C# or VB.NET for the business code. It also provided for much easier use with architectures like Model-View, View-Model (MVVM) and IoC (Inversion of Control) containers.

Windows Presentation Framework(WPF)于2006年大张旗鼓地发布。最后，可以为Windows生产漂亮的图形应用程序。 它为UI使用XAML，为业务代码使用C＃或VB.NET。 它还使诸如Model-View，View-Model(MVVM)和IoC(控制反转)容器之类的体系结构的使用更加容易。

You could also re-use your knowledge of WPF to create excellent experiences for users on the web via Silverlight. Microsoft also had Blend which would let you tweak the visual aspects of your app and create something that could be genuinely visually impressive.

您还可以重新利用WPF的知识，通过Silverlight为网络上的用户创建出色的体验。 微软还拥有Blend，它可以让您调整应用程序的视觉效果，并创建真正令人印象深刻的内容。

And then Microsoft killed Silverlight.

然后微软杀死了Silverlight。

Don’t get me wrong, it was the right thing to do. HTML5 was seeing widespread adoption, the other competitor in this market (Flash) was known as buggy, and prone to security risks. Plus, installing a plugin to your browser was also universally hated and not completely platform friendly. Not to worry though, sure, you can’t make your web apps and re-use your WPF knowledge anymore, but you could make phone apps for Windows Phone, so that’s gotta be worth something right?

不要误会我的意思，这是正确的做法。 HTML5正在被广泛采用，该市场中的另一个竞争者(Flash)被称为越野车，并且容易产生安全风险。 另外，在浏览器中安装插件也是普遍讨厌的，并且并不完全是平台友好的。 不过，请不必担心，您不能再制作Web应用程序并重新使用WPF知识，但是可以为Windows Phone制作电话应用程序，所以值得这样做吗？

Well it was, until 2017, after many years of missed expectations, Windows Phone was finally laid to rest.

好吧，直到2017年，在多年未实现预期之后，Windows Phone终于安息了。

So now, you couldn’t use your XAML knowledge on web apps, because Silverlight is gone. And you couldn’t use it on mobile either because Windows Phone is over. We’re left with, you guessed it, the venerable desktop. For a moment, think, if you made an app today that only targeted desktop computers, what would your market penetration be? Probably pretty bad — can you imagine if you could only use Instagram while sitting in front of your computer?

所以现在，您无法在Web应用程序上使用XAML知识，因为Silverlight已经消失了。 而且您也无法在移动设备上使用它，因为Windows Phone已经结束。 您猜对了，我们剩下了古老的台式机。 想一想，如果您今天制作的应用程序仅针对台式机，那么您的市场渗透率将是多少？ 可能非常糟糕-您能想象如果只能坐在电脑前使用Instagram吗？

In 2016, Microsoft bought Xamarin. One of Xamarin’s products was Xamarin Forms, which let you deploy to iOS, Android, and Windows. It also utilised XAML for the design language and C# for the business logic. That’s great news, right? You can just roll into Xamarin Forms from UWP and re-use all your knowledge.

2016年，微软收购了Xamarin。 Xamarin的产品之一是Xamarin Forms，它使您可以部署到iOS，Android和Windows。 它还将XAML用于设计语言，并将C＃用于业务逻辑。 那是个好消息，对吗？ 您可以从UWP滚动到Xamarin Forms，然后重新使用所有知识。

Except that you never really could. Syntax differences abounded between WPF, UWP, and Xamarin Forms. You want to lay your widgets out top to bottom, in a column, what would you use? On Xamarin Forms, you would use StackLayout, while on UWP, you would use StackPanel . These syntactic inconsistencies tended to bite frequently and become frustrating (an incomplete list of all these differences is here) and honestly, why is a StackLayout called something different than a StackPanel when they both ultimately achieve the same thing? And sad to say, in an article about apps for desktop, I can’t remember the last desktop app I used that was written in Xamarin Forms (not counting the ones that I made).

除了您永远无法做到。 WPF，UWP和Xamarin形式之间的语法差异很大。 您想将您的小部件从上到下放在一栏中，您将使用什么？ 在Xamarin Forms上，您将使用StackLayout ，而在UWP上，您将使用StackPanel 。 这些语法上的不一致往往会经常被咬而变得令人沮丧( 这里是所有这些差异的不完整列表)，老实说，为什么当它们最终都实现相同的目的时，为什么StackLayout与StackPanel有所不同？ 而痛心地说，有关的应用程序桌面的一篇文章中，我不记得我上次使用的桌面应用程序，这是写在Xamarin形式(不包括我做的那些)。

To briefly clarify, when I say desktop apps, I don’t necessarily mean the apps that come out of the Microsoft Store and are proper bona fide Universal Windows Platform apps. Let’s face it, so few of the apps that we use come in this format. I mean desktop apps, in the way that Steam is a desktop app, or the Discord client is a desktop app. Both typically come from an installer and execute in a window on your desktop.

简而言之，当我说台式机应用程序时，我并不一定意味着这些应用程序是来自Microsoft Store的并且是真正的通用Windows平台应用程序。 面对现实吧，因此我们使用的应用程序很少采用这种格式。 我的意思是台式机应用程序，就像Steam是台式机应用程序，或者Discord客户端是台式机应用程序一样。 两者通常都来自安装程序，并在桌面上的窗口中执行。

If I were making a desktop app today, I wouldn’t use Win Forms, Windows Presentation Framework or Universal Windows. By extension, I probably wouldn’t use Xamarin Forms either, despite supporting Windows 10 as a deployment target. So what else is out there?

如果我今天要制作桌面应用程序，则不会使用Win Forms，Windows Presentation Framework或Universal Windows。 通过扩展，即使支持Windows 10作为部署目标，我也可能不会使用Xamarin Forms。 那还有什么呢？

Well, there’s other solutions that let you write apps in JavaScript and web technologies, like Electron. So would I use Electron?

嗯，还有其他解决方案可让您使用JavaScript和网络技术(例如Electron)编写应用。 那我会用电子吗？

在桌面应用程序中使用Electron (Using Electron for your desktop app)

Electron’s opening paragraph on the website is “If you can build a website, you can build a desktop app.”. And it’s technically true — you can re-use your web talent on making desktop apps. But just because you can, does that mean you should?

Electron在网站上的开头段落是“ 如果可以构建网站，则可以构建桌面应用程序。 ”。 从技术上讲，这是正确的-您可以在制作桌面应用程序时重用网络人才。 只是因为可以，这是否意味着您应该这样做 ？

I guess the thought is that if you know how to make a web frontend, and enough JavaScript or TypeScript then you can apply that to Electron to make a desktop app. Electron is used as the basis for very popular pieces of software like Visual Studio Code or Microsoft Teams. People have a variety of experiences with VS Code, or even Microsoft Teams, and for the most part they are completely fine.

我猜想这是如果您知道如何制作Web前端以及足够JavaScript或TypeScript，则可以将其应用于Electron来制作桌面应用程序。 Electron用作非常流行的软件(例如Visual Studio Code或Microsoft Teams)的基础 。 人们在VS Code甚至Microsoft团队方面都有各种各样的经验，并且在大多数情况下，他们是完全可以的。

Electron works and powers a lot of great experiences today. But of the primary areas where we are concerned with as developers is performance. JavaScript is compiled Just In Time (JIT), which means that code is compiled to machine code by the JavaScript interpreter. Don’t get me wrong, these interpreters are very fast these days (helped by threaded workloads and huge clock speeds). But other languages like C++ or Dart compile Ahead Of Time (AOT). This means that at execution time, no time is spent compiling your code to machine code, it just executes as is.

如今，Electron可以为许多出色的工作提供动力。 但是，作为开发人员，我们关注的主要领域是性能 。 JavaScript会按时(JIT)进行编译，这意味着代码会由JavaScript解释器编译为机器代码。 不要误会我的意思，这些口译器现在非常快(在线程化的工作负载和巨大的时钟速度的帮助下)。 但是其他语言(例如C ++或Dart)会提前编译(AOT)。 这意味着在执行时，无需花费任何时间将代码编译为机器代码，而是按原样执行。

As you would expect, code that is compiled ahead of time executes faster on the processor at runtime,as it doesn’t have to be compiled just before it is executed.

如您所料，提前编译的代码在运行时在处理器上的执行速度更快，因为不必在执行之前就对其进行编译。

用HTML设计桌面应用 (Designing desktop apps in HTML)

HTML was originally designed for making web pages. Then, as time went on, various JavaScript frameworks added data binding capabilities to HTML, and we wound up with frameworks like Angular and React. While these frameworks can lead to an excellent experience on a responsive web, I think they’re not the best fit for desktop applications.

HTML最初是为制作网页而设计的。 然后，随着时间的流逝，各种JavaScript框架为HTML添加了数据绑定功能，而我们最终采用了Angular和React这样的框架。 虽然这些框架可以在响应式Web上带来出色的体验，但我认为它们并不是最适合桌面应用程序的框架。

Laying a website out with elements like <div> make sense on a web page, but the logic starts to break down when designing desktop apps. The elements themselves have no styling, so you rely on style sheets to give your app a certain look. Later versions of CSS let you utilise flex box and flex elements to help this process, but this can quickly become convoluted.

在网页上使用诸如<div>类的元素来布置网站是有意义的，但是在设计桌面应用程序时，逻辑开始崩溃。 元素本身没有样式，因此您依赖样式表使应用程序具有一定的外观。 更高版本CSS允许您利用flex box和flex元素来帮助完成此过程，但是这很快就会变得令人费解。

Plus, to make an app that looks good, you wind up between HTML for your general app layout, JavaScript for your business logic, and CSS for your look and feel. So you have to be across all three languages in order to build anything that looks good.

另外，要使一个应用程序看起来不错，您可以在HTML(一般应用程序布局)，JavaScript(业务逻辑)和CSS(外观)之间切换。 因此，您必须使用所有三种语言才能构建看起来不错的东西。

People who use Electron will fall into two camps. Either they will be fairly good at HTML, JavaScript (or TypeScript) and CSS. Or, they will be learning from scratch these technologies to design and build applications. In the latter case, should someone learn web technologies to build a desktop app in Electron? I would say no. Don’t get me wrong, it’s not bad to learn more, or to cross pollinate and learn more than you absolutely have to, or even still, learn one language and use it in more than one place. It’s just that it may not make the best sense to learn about a technology that defines how web pages are laid out when you are trying to lay out your desktop app.

使用Electron的人将分为两个阵营。 他们要么会相当擅长HTML，JavaScript(或TypeScript)和CSS。 或者，他们将从头开始学习这些技术来设计和构建应用程序。 在后一种情况下，是否应该有人学习网络技术以在Electron中构建桌面应用程序？ 我会说不。 别误会我的意思，了解更多信息或进行授粉和学习比您绝对需要的知识还好，甚至仍然可以学习一种语言并在不止一个地方使用它。 只是，当您尝试布局桌面应用程序时，了解一种定义网页布局方式的技术可能并不是最好的选择。

As we’ve covered off, what you can build in Universal Windows Platform, Windows Presentation Framework or maybe even Electron will be ‘completely fine’. But are you chasing ‘completely fine’, or something more? Because you should be targeting ‘the most amazing, beautiful experience your user has ever used’. It doesn’t have to start like that, but you should be able to grow it into that.

正如我们已经介绍的那样，您可以在通用Windows平台，Windows Presentation Framework甚至是Electron中构建的内容都将“完全正常”。 但是，您追求的是“完全正常”，还是更多？ 因为您应该针对“用户使用过的最神奇，最美好的体验”。 它不必那样开始 ，但是您应该能够将其发展成那样。

然后还有其他一切 (And then there’s everything else)

Over the years, many languages have risen and fallen in the battle for desktop computing. Java and QT come to mind, but none have really secured a dominant market share — nobody really ‘defaults’ to one or the other when they want to make a desktop application. In my average day I might go between WebStorm (written in Java) to Microsoft Teams or Visual Studio Code (Electron).

多年来，在桌面计算之战中，许多语言兴衰成败。 想到了Java和QT ，但是没有人真正获得了主导的市场份额-当他们想要制作桌面应用程序时，没有人真正“默认”彼此。 在平常的一天中，我可能会介于WebStorm(用Java编写)和Microsoft Teams或Visual Studio Code(Electron)之间。

Of course, the title of this article is on why Flutter will “win the desktop” — why in the future Flutter will (in my opinion) become the de facto standard for applications written for the Windows, macOS and Linux desktop. But how is that going to happen? Here’s how it might.

当然，本文的标题是关于Flutter为什么会“赢得桌面”的原因-在我看来，为什么Flutter将来会成为为Windows，macOS和Linux桌面编写的应用程序的事实上的标准。 但是那将如何发生？ 这可能是这样。

明智的设计 (Sensible design)

Flutter has opinions on how you should do things behind the scenes like make network requests etc, but it also has strong opinions on how you should lay out your application. You lay out your application using rows and columns, and define how much those rows and columns should extend in the overall layout. The Flutter design tooling is a huge topic and beyond the scope of this article, but from using Xamarin Forms and WPF XAML to lay out applications, to using HTML, and in my opinion, laying your app out with Flutters’ widgets is vastly superior. Everything seems to wind up where you want it, and if it doesn’t, its configurable to get it exactly to where you want it. I found myself battling with how Xamarin Forms wanted to lay out my app, instead of how I wanted it laid out. Most times, in the end, I just let Xamarin lay it out how it wanted to and dealt with it. A lot of the reason why this this way is because Flutter uses it’s own rendering engine, unlike Xamarin Forms or Electron that rely on the native system controls or how the browser renders those controls. Flutter is capable of rendering each pixel in your app the exact way that you want it, at a speed that is equal or almost equal to a native app.

Flutter对如何在幕后进行操作(例如发出网络请求等)有意见，但对如何布置应用程序也有很强烈的意见。 您使用行和列对应用程序进行布局，并定义这些行和列应在整体布局中扩展多少。 Flutter设计工具是一个巨大的话题，超出了本文的范围，但是从使用Xamarin Forms和WPF XAML布局应用程序到使用HTML，在我看来，使用Flutters的窗口小部件布局应用程序都非常优越。 一切似乎都在您想要的地方结束，如果不需要，可以对其进行配置以将其准确地到达您想要的地方。 我发现自己与Xamarin Forms 想要布局我的应用程序而不是我想要它布局的方式发生争执。 多数情况下，最后，我只是让Xamarin列出它想要的方式并进行处理。 之所以如此，是因为Flutter使用了它自己的渲染引擎，这与Xamarin Forms或Electron依赖于本机系统控件或浏览器如何渲染这些控件不同。 Flutter能够以等于或几乎等于本地应用程序的速度，以所需的精确方式渲染应用程序中的每个像素。

工装 (Tooling)

You’ve likely heard the phrase ‘Hot Reload’ and ‘Flutter’ in the same sentence enough in the past few months to make you want to scream. And I hear you, I was much the same before I started learning Flutter. Normally, this is demonstrated in the fact that the UI hot reloads, as in, you change the text on a button, hit save, and the text in the button has changed.

在过去的几个月中，您可能已经在同一句话中听到了“ Hot Reload”和“ Flutter”这两个短语，足以让您尖叫。 而且我听说您，在开始学习Flutter之前，我几乎是同一个人。 通常，这可以通过以下事实来证明：UI热重新加载，例如，您更改按钮上的文本，然后单击保存，并且按钮中的文本已更改。

In my opinion, the true power of this functionality is that everything benefits from hot reload. If you are working on a service to provide a function, simply saving the Dart file is enough to update the code for that particular function. The next time that code path executes, it runs the new path that you have just written, meaning you spend considerably less time rebuilding your app when something changes. XAML in WPF or Xamarin Forms also has hot reload, but this is strictly limited to the UI and, at least in my opinion, Flutter’s hot reload works more reliably.

我认为，此功能的真正力量在于， 所有内容都可以从热重装中受益。 如果您正在使用提供功能的服务，则只需保存Dart文件就足以更新该特定功能的代码。 下次执行该代码路径时，它将运行您刚刚编写的新路径，这意味着在发生某些更改时，您花费更少的时间来重建应用程序。 WPF或Xamarin Forms中的XAML也具有热重载，但这严格限于UI，至少在我看来，Flutter的热重载工作更可靠。

支持macOS，Linux和Windows作为构建目标 (Supports macOS, Linux and Windows as build targets)

Because of how Flutter works, you can target any desktop platform you like and develop for it. macOS and Linux support are already in alpha, and with Canonical partnering with Google to get this out the door, I feel like this will develop quite quickly before long.

由于Flutter的工作方式，您可以针对自己喜欢的任何桌面平台进行开发。 macOS和Linux支持已经处于测试阶段， 并且通过与Google的Canonical合作将其发布 ，我觉得这很快就会发展很快。

Windows is listed as being ‘in development’ but in my personal experience, if you switch to the master (cutting edge) channel of Flutter, you can quite easily create a Flutter app with a Windows target and everything works quite well, even Hot Reload. It’s an incredibly strong base to build on.

Windows被列为“开发中”，但以我个人的经验，如果切换到Flutter的master渠道(最前沿)，则可以轻松地创建带有Windows目标的Flutter应用，并且一切运行良好，即使是Hot Reload 。 这是一个难以置信的强大基础。

高效的跨平台调用 (Efficient cross platform invocation)

When it comes down to it, especially when writing apps that are cross platform, per platform implementations of various functions are important. This is something that was hard on platforms like Xamarin Forms, as you had to express what you wanted via a C# ‘binding library’ for the target platform. I never found it an intuitive experience.

归根结底，特别是在编写跨平台的应用程序时，每个平台的各种功能实现非常重要。 在Xamarin Forms等平台上，这是很难做到的，因为您必须通过针对目标平台的C＃“绑定库”表达所需的内容。 我从来没有发现它是一种直观的体验。

Flutter instead lets you write the platform specific implementations on each platform’s native language, so swift on macOS, C++ on Linux and Windows (C#/.NET is apparently possible, and is coming, according to this). This means that you benefit from all the code samples out there already for these platforms, and reduces the barrier to writing your own plugins.

颤振，而不是让你写上的每个平台的本地语言的特定于平台的实现，所以在MacOS，C ++在Linux和Windows快捷(C＃/。NET显然是可能的，而且快到了，按照这个 )。 这意味着您可以从这些平台已经获得的所有代码示例中受益，并减少编写自己的插件的障碍。

漂亮的应用程序易于制作 (Beautiful apps are easy to make)

When you build a WPF, UWP, Xamarin Forms or Electron app, the styling is entirely up to you, or whatever styling package you bring in to give your app a certain look. By default, it’s quite plain.

当您构建WPF，UWP，Xamarin Forms或Electron应用程序时，样式完全取决于您，或者您带来的任何样式包都可以使您的应用程序具有一定的外观。 默认情况下，它很简单。

Most apps in Flutter use the MaterialApp widget at the top level, meaning that apps immediately benefit from Material styling. Even if you absolutely despise Material design, it’s still a better look than a completely unstyled HTML or Xamarin Forms app (which is really just black text on a white background). Even little things like putting your text in a circle with a gradient background, things that would be almost impossible to express in XAML, are much easier in Dart.

Flutter中的大多数应用程序都在顶层使用MaterialApp小部件，这意味着应用程序会立即从Material样式中受益。 即使您绝对鄙视 Material设计，它仍然比完全未样式化HTML或Xamarin Forms应用程序(实际上只是白色背景上的黑色文本)看起来更好。 在Dart中，即使是像将文本放在带有渐变背景的圆圈中这样的小事情，在XAML中几乎无法表达的事情，也要容易得多。

跨设计，业务逻辑和样式的统一 (Unification across design, business logic, and style)

With Flutter, whether you are designing the app’s look and feel, or working on the business logic, you’re using the Dart programming language. You’re not chopping and changing between XAML, HTML, CSS, and C# or JavaScript, etc, no, there’s just the one language. This means that when you learn a neat trick in Dart in the UI or service layer, you can also apply this to other facets of the application. Previously, as your skills with CSS, HTML and JavaScript (or C# and XAML) would grow independently of each other, now your skill with Dart just grows as one. The benefit in that along is significant.

使用Flutter，无论您是设计应用程序的外观和风格，还是处理业务逻辑，都在使用Dart编程语言。 您无需在XAML，HTML，CSS和C＃或JavaScript等之间切换或切换，不，只有一种语言。 这意味着，当您在UI或服务层中的Dart中学习巧妙的技巧时，也可以将其应用于应用程序的其他方面。 以前，随着您使用CSS，HTML和JavaScript(或C＃和XAML)的技能会彼此独立增长，现在您使用Dart的技能也越来越多。 这样做的好处是巨大的。

Flutter will win the Desktop because today, in very early alpha/dev release, it demonstrates a surprising level of competence, even when compared to solutions that have been in this space for a very long time. Can you imagine what it will be like when Windows, macOS and Linux support are supported in in the stable channel?

Flutter之所以会赢得桌面版，是因为今天，在很早的alpha / dev版本中，即使与在该领域已经存在很长时间的解决方案相比，它也具有惊人的能力。 您能想象稳定频道中支持Windows，macOS和Linux支持时的情况吗？

I for one, cannot wait.

我一个，等不及了。

This is an opinion piece, so parts of the above are sampled from my anecdotal experiences. I’m happy to debate my position, after all, I could be wrong. Write a comment in if you think I’ve got something totally backwards. Also worth noting, WPF, UWP, Xamarin Forms and Electron are all projects that have taken thousands, if not tens of thousands of man hours to produce. A framework built today (like Flutter) no doubt builds on the decades of experience yielded from these solutions, and nothing that I’ve said above is supposed to disparage those individual projects. Be good to each other 🤗

这是一个观点，因此以上部分是从我的轶事经验中抽取的。 我很乐意辩论自己的立场，毕竟，我可能是错的。 如果您认为我有些事完全落后，请发表评论。 同样值得注意的是，WPF，UWP，Xamarin Forms和Electron都是需要花费数千甚至数万个工时才能完成的项目。 今天构建的框架(如Flutter)无疑是建立在这些解决方案数十年的经验基础之上的，而我上面所说的任何东西都不应该贬低那些单独的项目。 互相善待🤗

https://www.twitter.com/FlutterComm

https://www.twitter.com/FlutterComm