在过去的24个月中，我们花费 17.193,00 个小时使用 Flutter 完成了10个商业应用程序，本文将分享我们的见解。

阅读本文后，您将学习到：

  • 选择Flutter的原因是什么？ Flutter对预算和稳定性有什么影响？

  • Flutter准备好用于企业应用程序了吗？

  • 与Xamarin相比，Flutter的表现如何？

  • Flutter适合哪些项目？

自2018年7月在LeanCode上开始在Flutter上开发我们的第一个商业应用程序以来，到现在已经有两年了，当我第一次了解Flutter时，尽管它很有前景，但我仍然持怀疑态度，主要是因为我们最近对Xamarin的投资给我们带来了负面体验。 由于我们的团队一直希望在项目中使用一些激动人心的新技术，因此我们希望它能够证明它能给客户带来真正的价值。

这是一个农业项目，与牧群管理打交道，这是一个非常有趣而且典型的项目，管理员使用该系统来计算对谷仓的需求，而我们的团队认为，从UX的角度来看，这是一个很好的见解。

在两天内，他们自豪地展示了概念验证方案，证明了制作动画非常容易，可以为您带来出色而流畅的体验。最终，这已演变为完整比例的动画，您可以在此处看到：

有了这个喜悦，我确信Flutter值得尝试。

最初，我们没有将自己100％投入Flutter，而是与 React Native 项目并行进行。在没有Flutter团队官方支持的情况下编写第一个Google Maps实现，对此我感到悲观。您可以在https://leancode.pl/case-studies/kezia-app 了解有关在Flutter中编写第一个商业应用程序的经验以及相关困难的更多信息。最终，我们交付的是一个相对简单的应用程序，少于40个视图，且Flutter开发时间不到500小时。

自从我们交付了第一个应用程序并从客户那里收集到了五星级好评，我们认为，我们应该开始更加积极地向客户推荐Flutter。从2019年5月开始，我们决定Flutter将是我们移动技术的第一选择。同时，我们将停止在其他不同框架上开发应用程序的工作。

自那时以来，我们已经在Flutter中交付了10多种移动产品，并提供了数十种MVP / PoC。现在，该得出结论了。

Flutter 更快

我们并未在这里讨论理论方法（在此处可以查找https://blog.codemagic.io/flutter-vs-ios-android-reactnative-xamarin/  ），尽管这也很有趣。后来我们重写了基于 Xamarin 和 ReactJS 的App，将二者进行对比，在后端使用相同API的情况下，与Xamarin（667h vs 987h）相比，我们减少了33％的时间，使用ReactJS（486h vs 704h）相比，则减少了31％的时间。

停下来思考一下这些数字。这些数据回答了如何更快，更便宜地构建移动应用程序（使用Flutter）。随着经济不景气，在预算范围内按时交付产品变得越来越重要。这也意味着对于相同的预算，您可以多交付50％的订单。想象一下，您是一名产品负责人，负责开发团队的优先事项，能够将预算壁垒进一步提高50％。

这将极大地提高团队的创造力和他们交付的工作质量。有关GastroJob案例的详细分析，请查看我们在 Flutter Europe Conference 上的演讲，或在https://leancode.pl/case-studies/gastrojob 上查看我们的案例研究。

平均90％的代码在iOS和Android之间共享。

我们的90％的代码不会在两个本机平台上都编写两次。与本地应用程序开发相比，节省了90％的时间，并且由于一致性和团队围绕一个目标团结而不是分成两个本地流，因此释放了很多创造力。除了共享业务逻辑和用户体验外，我们还可以使用大量现成的库，这些库带来了更多的好处。首先，他们可以通过为应用程序内使用的许多不同事物提供常用逻辑来加快开发过程（例如与服务器（HTTP客户端）的通信，推送通知，安全存储，数据库，动画等）。其次，与许多流行的服务（例如Firebase，地图，支付，社交登录，分析，崩溃报告服务等）集成起来更加容易。因此，只有在编写特定于平台的自定义代码时，才需要编写两次代码（分别适用于iOS和Android）。但是，即使那样，在Dart和本机代码之间进行桥接还是相当合理的 简单，这将在本文后面进行解释。

更重要的是，如果考虑到质量因素，则可以节省更多，因此从长远来看，该应用程序的维护成本也更低。事实上，我们研究在Xamarin，React Native和Flutter构建的所有项目中修复bug的时间，，Flutter通常需要8–10％的修复bug时间。而 React Native 需要7–14％，Xamarin 需要11–23％。

与UX / UI的合作从未如此之好

在Flutter项目期间，需要UX / UI设计师和开发人员之间进行合作。可能是因为他们不需要进行这种乏味的本地改编，而使他们的创造力松散。但是，从React Native团队的经验中也可以期望得到同样的结果，事实并非如此。当我们更深入地挖掘时，我们发现Flutter为能够编写漂亮界面的开发人员带来了纯粹的欢乐，以前这些界面会带来额外的负担，从而减慢了步伐。因此，他们更愿意合作，并且我们已经看到结对编程会议开始于设计师与开发人员携手进行现场实验的过程中。经过几次这样的互动，得益于强大的主题引擎，团队能够为该应用程序提供一种自适应的设计语言，该语言不仅在Figma或Adobe XD中看起来很棒，而且还提供了最佳的用户体验以及连贯的感觉。正确的设计顺序。怎么样 在项目的整个生命周期中保持这种连贯性也很有趣。 以前，当UX / UI设计师在演示会议上审查产品时，他们在项目结束时拥有大部分评论，在实践经验之后改变主意或简化事情。 Flutter的独特之处在于，在项目结束时，设计师的参与已完全消失，因为他们在试验和错误的设计循环的初期就开始工作。 这也意味着后续sprint的优化花费的时间更少，并且这种持续的合作体现在下一个发行版的稳定Scrum速度上。

动画是如此的简单和实惠

在Flutter中实现静态视图不仅容易，而且在动画方面也提供了许多新的机会。这将这种UX-DEV的合作推向了新的高度，从而实现了前所未有的出色过渡效果。到目前为止，这仅对大型预算项目而言是典型的。如今，感谢Flutter，所有开发人员都可以使用它。之所以会发生这种情况，是因为Flutter可以直接在画布上进行渲染，并且可以完全控制图形，这使我们能够在所有平台上创建像素完美的图像，而无需像其他跨平台框架一样进行附加的条件格式设置。例如，在使用React Native进行绘制时，您基于默认视图，这些视图可以改变新控件的外观，因此，构建了一个臭代码，该代码依赖于平台，并且与共享代码不应采用的方法直接矛盾进入部署平台。

Flutter应用程序更轻巧

面对PWA业务选择时，PWA证明了在手机上添加快捷方式来像保存应用程序一样保存网站是多么容易。我们先不讨论用户体验，而只考虑下载应用程序的负担。是的，在两种情况下都并非易事。根据SimiCart博客，最佳PWA网站要求用户在加载时从4.9MB到11.6MB。这远远低于我们的Xamarin应用程序的平均大小25MB，甚至低于我们的React Native 32MB应用程序的平均大小，但非常接近Flutter的平均值11MB，所有Flutter应用程序的范围为9-14MB （请注意，尽管这些数字突出显示了模式，但它们不能直接比较）。您必须承认，对于本机应用程序体验，平滑的外观，快速的反应以及本机应用程序典型的所有服务（例如推送通知）而言，此（11MB）的空间非常低。这意味着没有障碍。 用户下载该应用程序，并开始与所有插件和集成一起尽可能高效地使用它。 这也意味着应用程序性能更高，因为它们可以使用较小的代码执行类似的任务。 与其他跨平台框架相比，这种性能上的提升直接转化为毫秒数，从而为您提供了较冷的应用程序，动画，CPU和内存使用方面的更快体验（实际上，在Flutter可以提供更好的冷启动应用程序的情况下，即使相比 到Swift / Kotlin本机应用程序）。

需要时可以访问本机代码。

Flutter的优点在于，移动团队更希望使用本机代码并编写一些Kotlin / Swift软件包，因为它们可以完全控制本机实现，而Xamarin就是这种情况最终代码在一个孤立的黑匣子中生成。到本机代码的桥也更强大，因为它们是完全透明的，因此对于从本机环境转移过来的开发人员来说更友好。由于采用了这种方法，因此可以轻松实现特定功能，例如本地支付提供商或一些复杂的库。更重要的是，即使是需要生物特征识别算法进行面部识别或指纹检查的高级功能，也可以在Flutter上顺利运行，这是由ING商业在Flutter中开发的银行应用程序展示的，该应用程序是在JakubBiliński在Flutter Warsaw Meetup上展示的。

Flutter中的概念非常简单

当我们需要构建概念证明以检查最危险的假设测试时，与本机代码的集成带来的其他好处。这意味着在客户决定签署整个项目的合同之前，我们可以构建最小的应用程序，以回答最关键的业务或技术问题。在这一点上，我们不能高估Flutter的功能。每次我们将此类计划定为两天的开发时间，试图找出在这么短的时间内可以实现的目标。到目前为止，我们正在尝试各种PoC，包括支持AR的图像检测系统（如下），

通过白板图纸绘制高级动画。

建立快速的PoC不仅使我们能够展示开发的速度，而且还有助于我们为最终项目提供更准确的估算。

开发人员很高兴

从建立内部团队的角度来看，Flutter被证明是一个不错的选择。最初，Flutter开发人员很少，因为没有专业经验。但是，与开发人员具有C＃背景的Xamarin相比，情况有所不同，在Flutter的情况下，所有候选人都是已经从本地（主要是Android）背景转移的移动开发人员。随着Flutter变得越来越受欢迎，并且由于社区组织的活跃以及定期聚会和网络研讨会的兴起，可用的候选人数量呈指数增长，如今，有大量的专业人士愿意在Flutter项目中寻找工作经过多年的本机应用程序开发，我们改变了看法。得益于文件详尽的Flutter代码以及社区提供的其他库的可用性，进行此类转移非常容易。因此，一些以前拥有独立移动团队的公司 正在投资以使它们围绕Flutter。 在LeanCode，我们甚至组织了Flutter训练营，在湖边进行了为期三天的培训计划，以提供动手经验，并为密集的，为期两个月的学习计划选择最佳人选，在那里学习Flutter 伴随着做一些非商业项目。 我们惊讶地注意到，经过9个星期的培训，开发人员准备与他们的同事并肩工作，他们从早期就开始在Flutter中进行编码。 如此短暂的学习周期证明，从企业主的角度出发，选择从本地应用程序切换到Flutter并不是一场革命，而是一场内部团队可以发挥重要作用的演变。

对技术栈做出正确的决定可能会对您的业务和个人职业产生持久的影响。然而，很少有选择如此简单。 Flutter已经成为不可阻挡的运动，不可忽视的力量，并且它仍在发展并向具有银行或保险等极高质量标准的非常保守的行业扩展（例如NuBank，ING和AXA等）。

如果考虑到甚至在生产阶段发布Flutter for Web或Flutter for Desktop之前都会发生这种情况，则表明Flutter for mobile具有足够的价值，可以在这个非常先进的市场上竞争。无论您从事的行业是什么，早期采用者的时代都已经过去，我们很快就会见证越来越多的成熟参与者进入Flutter生态系统。我希望这将使我们能够在Flutter中制作出另外10款出色的应用程序后，在明年的总结中分享从这些实现中学到的经验教训。