停止使用Flutter；它会比你想象的更快死亡。如果您正在使用Flutter，您应该考虑停止在项目中使用它。请将这篇文章呈现给您的首席技术官、首席执行官或任何相关人员，但您需要预测自己和技术团队的未来。

Flutter会死的暗示是什么？

谷歌在2023年解雇了许多在Fuchsia的开发人员

谷歌可能会放弃它

谷歌可能会放弃Flutter，因为它的优先级发生了变化。就像苹果和AppleCar一样，谷歌有能力停止投资数十亿美元，你应该记住，停止一个十亿美元的项目就像一家小公司停止一个10万美元的项目，没什么好说的。为了理解谷歌为什么放弃它，我们必须理解他们为什么创建它。Flutter应该像Fuchsia的旗舰，这是一个开源操作系统，Flutter将是编程的默认语言。但为什么谷歌想投资一个新的操作系统呢？我没有答案，你有，请写评论。我们可以假设，当甲骨文起诉谷歌违反Java Api时，如果AOPS遇到麻烦，这对Android来说是一个安全的选择。无论如何，使用Flutter（如Xamarin、ReactNative、KMM）使你成为一种工具（说实话，不是本文的主题）。谷歌发布这个不是为了让移动开发人员的生活更美好，而是因为他们需要他们。直到现在。2020年，我们到处都听说过紫红色，但到目前为止，自2021年以来只在Nest Hub上使用。为了结束这部分，谷歌在2023年解雇了这个项目的许多开发人员。随着Flutter附带的大约12%的应用程序，谷歌不会后悔停止支持并停止支持，就像微软为Xamarin......

iOS开发人员不喜欢谷歌技术

是的，这是事实，作为苹果的粉丝，通过确信或任何其他原因，iOS开发人员不喜欢第三方，特别是当它来自谷歌时。在项目中没有iOS开发团队的认同的跨平台技术，在公司采用Flutter是NO-GO。你会为此解雇你才华横溢的iOS开发人员吗？

此外，我们可以注意到，iOS原生和Android原生构建应用程序之间有10%的差异，这可以解释为Flutter比iOS开发人员更令人信服。通常，如果我们假设一个提供iOS应用程序的公司也提供相当于Android的公司，那么iOS和Android%应该看起来相似。

这项技术还不成熟

是的，该技术还不成熟，在Flutter年度开发人员会议上，我听到了一些“新的酷功能”或API或错误修复，当您使用原生代码编写应用程序时，这甚至不是一个主题。Flutter有超过12.5k个打开问题/功能请求等......这是世界上第二个累积这么多问题的项目。ReactNative有一个更大的社区，但只有>700个问题。它在设计上也是不成熟的，就像任何跨平台框架一样：每个新的本机功能都必须由框架以延迟（例如这里或这里）重新实现，有时在拥有后端口之前几年。使用Flutter是产品决策还是纯技术和财务决策？

如果您是Android原生kotlin开发人员，那么您是KMM开发人员

Kotlin多平台杀死了它，面包屑将进入ReactNative。

为什么React Native还在这里？因为有一个庞大的JavaScript开发人员社区。JavaScript很受欢迎，将React Native添加到ReactJS/Node.js前端/全栈开发人员的技能集中是增长/赚取更多钱的一种方式。谁写Dart代码？在Flutter项目中发生人员流失后，谁可以雇用Dart工程师？这将花费你更多。

JetBrains巧妙地将Kotlin用于KMM。Kotlin看起来像Swift，名声很好，更受欢迎，也被谷歌推开。而且......如果您是Android原生Kotlin开发人员，那么您就是KMM开发人员！ReactJS和React Native的想法是一样的，但有更多的论点：

• KMM仍然让你成为一名移动软件工程师。对于学习React Native的开发人员来说，情况并非如此；他们必须停止像网络开发人员一样思考，他们会犯工程错误。
• 对于Android来说，它是原生的，几乎没有性能损失。
• 它在技术上是灵活的；通过设计，您可以非常轻松地在iOS和Android之间共享您想要的东西。

我们应该花时间使您的代码库变得简单，为大三学生，为我们自己，我们的团队，挑战产品，花时间制作一些新功能的MVP，这些新功能将为我们公司带来更多资金，而不是通过随机的炒作技术选择将其置于危险之中，这是我们的目标

验尸：再一次，你为什么选择Flutter！

我告诉过你‍♂ -> iOS 17.4如何提醒我们为什么依赖原生技术是安全和可持续的。您应该保持原生状态或考虑转向跨原生心态来构建您的代码库，安全地->介绍跨原生开发方法。但现在你应该问问自己为什么会犯这个错误。从我们的错误中吸取教训是可以的，但这不是第一次：Xamarin，Rubymotion。与其尝试公司为硅谷的经济战争推动的炒作技术，并成为一个工具，我们应该花时间让我们的代码库变得简单，为了年轻人，为了我们自己，我们的团队，挑战产品，花时间制作一些新功能的MVP，这些新功能将为我们公司带来更多的钱，而不是通过随机的炒作技术选择将其置于危险之中，这是我们高级软件工程师的目标，作为第一个用户来改进我们正在开发的产品。你的部署自动化了吗？如果您错过了编写单元测试，您是否使用危险系统来阻止您的拉取请求？您是否使用Maestro来覆盖您的E2E关键路径？

使用KMM或Flutter将使您的产品具有更多功能？有更多的用户？更稳定？嗯，这不是这些框架的口号。

结论：我的观点

即使我不信任像KMM这样的第三方（它可能被微软和这样的公司收购，或者不收购），如果我必须在2024年选择跨平台技术，我肯定会选择KMM。Flutter可能有一些很好的论点，但在我看来，它的未来是非常黑暗的，我不会建议任何人开始投入时间。你不同意，想辩论或提出证据证明Flutter在这里已经很多年了？你可以写评论部分。