Android
Flutter 的性能接近原生应用，但并不能超越它。也就是说，无论怎么优化 Flutter，它的极限也就与原生应用持平。这是需要明确的第一个前提。其次，开发原生应用对程序员的要求远高于前端开发。例如，在原生开发中，开发者必须熟悉多线程并发、线程同步、锁机制、事件循环、消息队列以及线程池等复杂概念。而这些知识在 Web 前端开发中通常并不需要深入掌握。目前，很多从 Web 前端转到 Flutter 开发的工程师缺乏原生开发的经验，他们可能不了解
Android 和
IOS 的主线程消息循环机制，也不清楚什么是 Jank（掉帧现象）。尤其是在使用 Flutter 插件库时，许多原生插件直接运行在应用的主线程上，没有开启额外的线程来处理耗时任务。这往往会导致一些用 Flutter 开发的应用出现性能不佳或卡顿的问题。我在实际工作中也多次遇到这样的情况。还有一个重要的原因在于混合栈架构。很多人以为那些号称采用 Flutter 开发的应用都是纯 Flutter 实现的，但实际上，很多项目是基于混合栈模式构建的，比如闲鱼就是一个典型的例子。混合栈意味着在一个以原生框架为主的应用中嵌入了几个由 Flutter 开发的页面。这种架构虽然听起来很时髦，但从性能角度来看，通常表现并不理想，甚至还不如完全使用原生开发的应用。为什么会出现这种情况？很多时候，这其实是原生开发团队为了尝试新技术而做出的选择。他们希望通过引入 Flutter 页面来展示自己对新技术的关注，避免被贴上落伍的标签。于是，他们在原本的原生应用中加入一两个 Flutter 页面进行实验。然而，这种做法往往会导致整体性能下降，用户体验变差。既没有充分发挥 Flutter 的跨平台优势，也没有保留原生开发的高性能特点，唯一的好处可能只是为某些主导项目的开发者贡献了一些 KPI。相比之下，如果选择纯原生或者纯 Flutter 开发，反而可以避免这些问题。混合栈不仅增加了技术复杂性，还带来了诸多兼容性和性能上的挑战。开发者为了应对这些问题，往往会花费大量时间去设计和实现一些低效的解决方案，最终形成一堆蹩脚的轮子。而这恰恰成为了某些人制造问题后再解决问题、从而积累业绩的手段。简单来说，就是先无中生有地制造问题，再通过一系列不完
美的补丁去修复问题，以此提升自己的工作量和价值感，达到升职加薪的目的。总结来说，无论是从技术实现还是从业务需求的角度来看，混合栈都不是一条正确的道路。对于追求高质量用户体验的应用而言，纯原生或纯 Flutter 才是更好的选择。
