原文作者：medium.com/@leancode
发布时间：2020年7月28日 - 10分钟阅读
作者：Łukasz Kosman和Jakub Wojtczak。
在过去的24个月内，我们在Flutter项目上花费了约17.193,00小时，制作了前10个商业应用，现将制作后的心得与大家分享。
读完这篇文章，你会了解到:
- 选择Flutter的原因是什么？Flutter对预算和稳定有什么影响？
- Flutter是否为企业应用做好了准备？
- Flutter与Xamarin相比表现如何？
- Flutter适合哪些项目？
从2018年7月在LeanCode开始用Flutter开发第一个商业应用，到现在已经两年了。当我第一次了解到Flutter时，虽然它很有前景，但我仍然持怀疑态度，主要是因为我们最近投资Xamarin的负面经验。由于我们的团队总是有一些新的和令人兴奋的技术想要带到项目中，我们向他们提出了挑战，并要求证明这如何能够为客户带来真正的价值。这是一个农业项目，涉及到牛群管理。有一个有趣的工件，是这个行业的典型特征，它被饲养者广泛用于计算对牛舍的需求，我们的团队认为，从用户体验的角度来看，这是一个很好的洞察力。
在两天之内，他们自豪地展示了概念证明，展示了构建一个动画轮子给你带来的巨大而流畅的体验是多么容易。最终，这已经演变成了完整的动画，你可以在这里看到。
Kedzia App项目中Flutter中的简单动画示例。
有了这个喜闻乐见的东西，我确信Flutter是值得尝试的。
起初，我们并不想把自己100%的精力投入到Flutter上，所以我们保持了React Native项目的并行。当面对我们在没有Flutter团队官方支持的情况下编写Google地图的第一个实现时，我觉得这种悲观主义是合理的。你可以在这里了解更多关于用 Flutter 编写这第一个商业应用的经验和相关困难。最终我们交付的是一个相对简单的应用，只有不到40个浏览量，成本低于500小时的Flutter开发。
当我们交付了这第一个应用，并收集了客户的五星好评后，我们认为从2019年初开始，我们应该开始更积极地向客户推荐Flutter。从2019年5月起，我们决定Flutter将成为我们在移动技术方面的第一选择，我们将停止参与在不同框架上开发应用程序。
从那时起，我们已经在Flutter上交付了10多个移动产品和几十个MVP/POC。现在，是时候得出结论了。
Flutter更快。
我们在这里并不是在谈论理论方法，虽然这也很有趣（在这里找到Bran De Connick的论文）。我们有一个独特的机会从Xamarin（面向客户端的移动应用）和ReactJS（面向餐厅经理的Web应用）重写应用，结果是相当的。与Xamarin相比，我们花了67%的时间(667h vs 987h)，用ReactJS创建应用所需的69%的时间(486h vs 704h)，在非常相同的范围内，使用后端相同的API。停下来思考一下这些数字。这就是如何更快、更便宜地构建移动应用的终极答案。在经济不景气的情况下，在预算范围内按时交付新的数字产品从未如此重要。这也意味着，在同样的预算下，你可以交付更多50%的积压产品。想象一下，你作为一个产品所有者，为你的开发团队制定优先级，能够将预算障碍进一步提高50%。
从移动Xamarin和web ReactJS版本重写项目到Flutter所花费的时间。
这将极大的提升你团队的创造力和他们所交付的工作质量。关于GastroJob案例的详细分析请看我们在Flutter欧洲大会上的演讲，或者在这里查看我们的案例研究。
平均90%的代码是iOS和Android共享的。
我们90%的代码不会为两个原生平台写两次。与原生应用开发相比，90%的时间被节省了，由于一致性和团队团结在一个目标上，而不是分成两个原生流，大量的创造力被释放出来。除了共享业务逻辑和用户体验之外，我们还可以使用大量的即用型库，带来额外的好处。首先，它们可以通过为应用内使用的许多不同事物(如与服务器(HTTP客户端)的通信、推送通知、安全存储、数据库、动画等)提供常用的逻辑来加快开发进程。). 其次，它更容易与许多流行的服务（如Firebase、地图、支付、社交登录、分析、崩溃报告服务等）集成。因此，只有当你要编写定制的特定平台代码时，你才需要编写两次代码（分别为iOS和Android编写）。然而，即使如此，Dart和原生代码之间的桥接也是相当容易的，这将在本文后面解释。
更重要的是，当我们考虑到质量因素时，会有更大的节省，这使得应用程序从长远来看也更便宜的维护。事实启发我们调查了所有用Xamarin、React Native和Flutter构建的项目来寻找模式，我们发现Flutter项目通常需要8-10%的时间花在bug上，而React Native的范围是7-14%，Xamarin是11-23%。
与UX/UI的合作从来没有这么好过。
在Flutter项目中，UX/UI设计师和开发之间的合作有一些点击。可能是因为他们不需要进行这种繁琐的原生适配，他们把自己的创造力放飞了。然而，从React Native团队的体验来看，同样会有这样的预期，而事实并非如此。当我们深入了解之后，我们发现Flutter给那些可以写出漂亮界面的开发人员带来了纯粹的快乐，而以前这些都是和额外的负担联系在一起的，会拖慢节奏。因此，他们更愿意合作，我们观察到开始发生了设计师与开发人员手把手地做现场实验的配对编程环节。经过几次这样的互动，得益于强大的主题引擎，团队能够为应用提出一种适应性强的设计语言，这种设计语言不仅在Figma或Adobe XD中看起来很好，而且还能给用户带来最好的体验，以及连贯性和适当的设计顺序的感觉。这种连贯性如何在项目的生命周期中存在也很有意思。以前UX/UI设计师在Demo环节对产品进行评审时，他们的意见大多是在项目结束时，在亲身体验后改变了想法或简化了东西。Flutter的独特之处在于，在项目结束时，设计师的参与是完全消失的，因为他们在一开始的设计循环试错中就早早的做好了自己的工作。这也意味着后续sprint的完善需要更少的时间，这种持续的合作体现在下一个版本稳定的scrum节奏上。
动画很容易，也很实惠。
在Flutter中不仅很容易实现一些静态视图，而且在动画方面也提供了很大的新机会。这将这种UX-DEVs的合作带到了另一个层面，使得漂亮的过渡效果变得前所未有的容易。到目前为止，这只是大预算项目的典型。如今，多亏了Flutter，所有的开发者都可以使用。这是因为Flutter在裸机上渲染，直接在画布上完全控制绘图，这使我们能够在所有平台上创建像素完美的图像，而不像其他跨平台框架那样需要额外的条件格式化。例如用React Native绘图时，你是基于默认的视图，这可能会改变你的新控件的外观，因此，构建一个臭代码，这是对平台的依赖，直接与共享代码不应该带入部署的平台的方法相矛盾。
Flutter应用则轻巧得多。
这一点是值得考虑的，当面对PWA业务选择时，这证明了在手机上添加快捷方式保存网站是多么的简单，就像一个应用程序一样。我们不评论用户体验，只评论下载app的这个负担。是的，这两种情况下都是不费力的。根据SimiCart博客的数据，最好的PWA网站在加载时需要用户下载4.9mb到11.6mb。这远远低于我们Xamarin应用的平均大小，即25mb，甚至低于我们React Native 32mb应用的平均大小，但非常接近Flutter的平均大小，即11mb，而我们所有Flutter应用的大小范围是9-14mb（只需在
Flutter应用更轻巧。
这一点在面对PWA业务选择时值得考虑，这证明了在手机上添加快捷方式保存网站是多么的简单，就像一个应用程序一样。我们不评论用户体验，只评论下载app的这个负担。是的，这两种情况下都是不费力的。根据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上顺利运行，因为它在Flutter华沙Meetup期间由Jakub Biliński展示的由ING为商业开发的银行应用中得到了展示（链接）。
Flutter中的概念证明很容易。
当我们需要构建概念证明以检查最风险假设测试时，与原生代码集成的便利性带来了额外的好处。 这意味着，在客户决定签署整个项目的合同之前，我们可以构建尽可能小的应用程序，以回答最关键的业务或技术问题。这一点，我们不能高估Flutter的能力。每一次我们都是把这样的举措时间框定在两天的开发时间内，试图找出在这么短的时间内可以实现的目标。到目前为止，我们正在试验各种PoC，从AR支持的图像检测系统（下图）。
在2天内完成了概念验证的例子，Flutter展示了AR。
通过白板图和高级动画。
建立一个快速的PoC不仅能让我们展示开发速度，还能帮助我们为最终项目提供更准确的估算。
DEV们很开心。
从内部团队建设的角度来看，事实证明Flutter是一个不错的选择。起初，Flutter的开发人员很少，因为没有人有专业经验。然而，与Xamarin等开发者有C#背景的公司相比，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个优秀的应用后，在下一年的总结中分享这些实施中的经验教训。
通过www.DeepL.com/Translator（免费版）翻译
