子玥酱 （掘金 / 知乎 / CSDN / 简书 同名）
大家好，我是 子玥酱，一名长期深耕在一线的前端程序媛 👩💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。
我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括 前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。
技术方向： 前端 / 跨端 / 小程序 / 移动端工程化 内容平台： 掘金、知乎、CSDN、简书 创作特点： 实战导向、源码拆解、少空谈多落地 **文章状态：**长期稳定更新，大量原创输出
我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在"API 怎么用"，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。
子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源 （工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学"明白"，也用"到位"
持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱
文章目录
-
- [短期性能 vs 长期性能，是两套完全不同的命题](#短期性能 vs 长期性能，是两套完全不同的命题)
- [Flutter 的性能：上限高，下限也很低](#Flutter 的性能：上限高，下限也很低)
-
- [Flutter 真正的优势是什么](#Flutter 真正的优势是什么)
- 但长期维护下，问题通常出在这里
-
- [Widget 层级不断膨胀](#Widget 层级不断膨胀)
- 状态作用域逐渐失控
- [Flutter 非常依赖"自律"](#Flutter 非常依赖“自律”)
- [RN 的性能：早期可控，后期非常脆](#RN 的性能：早期可控，后期非常脆)
-
- [RN 的核心问题不在列表，而在"通信成本"](#RN 的核心问题不在列表，而在“通信成本”)
- 长期项目中，常见的演变路径
-
- [Redux / Context 状态不断集中](#Redux / Context 状态不断集中)
- 优化手段越来越"工程化"
- [iOS 的性能：慢一点，但稳定很多](#iOS 的性能：慢一点，但稳定很多)
-
- [UIKit / SwiftUI 的几个"强约束"](#UIKit / SwiftUI 的几个“强约束”)
- [iOS 为什么很少出现"越维护越卡"](#iOS 为什么很少出现“越维护越卡”)
- 代价也很明显
- 长期维护下，三者的性能差异本质是什么？
- 一个跨平台通用的"长期性能安全模型"
- 总结
如果只看 Demo，Flutter、RN、iOS 的性能差距其实并不明显。
甚至很多时候，Flutter 和 RN 的首屏体验，看起来比 iOS 还"丝滑"。
但真正拉开差距的，从来不是第一版，而是：
- 两年之后
- 五个业务线叠加之后
- 三拨人维护之后
- 重构一次没重构干净之后
长期维护下的性能表现，才是平台真实的"体质"。
短期性能 vs 长期性能，是两套完全不同的命题
很多性能讨论，其实一开始就搞错了前提。
- Demo 跑得快 ≠ 项目跑得稳
- 首屏流畅 ≠ 长期不卡
- 一次优化 ≠ 可持续结构
长期性能问题，通常不是某个 API 写错，而是架构选择 + 心智模型 + 团队习惯叠加出来的结果。
而 Flutter、RN、iOS，恰好在这三点上走了完全不同的路线。
Flutter 的性能：上限高，下限也很低
Flutter 的性能问题，往往不是"框架不行"，而是框架太能给你自由了。
Flutter 真正的优势是什么
- UI 是自绘的，渲染链路极短
- 没有 Bridge，不需要 JS ↔ Native 往返
- List / Sliver / RenderObject 的上限极高
在结构正确的前提下，Flutter 的列表、动画、复杂 UI，性能天花板非常高。
但长期维护下，问题通常出在这里
Widget 层级不断膨胀
- 早期为了"好拆组件"
- 中期为了"复用逻辑"
- 后期没人敢动
结果就是：
- 一个 ListItem build 里套 6 层 StatelessWidget
- 每层都带点逻辑
- rebuild 范围越来越模糊
状态作用域逐渐失控
- Provider 套 Provider
- Consumer 包 Consumer
- setState / notifyListeners 的边界越来越大
很多项目后期卡顿，并不是 build 慢，而是：
你根本不知道这一行状态变化，会重建到哪里。
Flutter 非常依赖"自律"
Flutter 不会阻止你写出：
- build 里 new 大对象
- ListView 外包 setState
- 滑动过程中频繁 notify
它假设你知道自己在干什么。
如果团队里有人不懂 rebuild，本质上是在慢慢给项目埋雷。
RN 的性能：早期可控，后期非常脆
RN 的问题，其实在长期维护下更明显。
RN 的核心问题不在列表，而在"通信成本"
RN 的性能瓶颈，几乎都绕不开：
- JS ↔ Native Bridge
- 序列化 / 反序列化
- 批量更新时的调度抖动
长期项目中，常见的演变路径
Redux / Context 状态不断集中
- 一开始：统一、清晰
- 后期：全局状态越来越多
- 最终：一个 action 触发半个页面重渲
这在列表里表现得尤其明显：
- FlatList 本身没问题
- 问题是：renderItem 被无意义地反复调用
优化手段越来越"工程化"
到了后期，RN 项目里经常会出现：
- memo / useCallback 到处都是
- key 一大堆人为约定
- 一堆"不要动"的组件
RN 的性能优化，本质上是：
用工程纪律，去对抗运行时模型的先天成本。
而这件事，时间一长，非常累。
iOS 的性能：慢一点，但稳定很多
iOS 在三者里，长期性能最稳定，原因反而不复杂。
UIKit / SwiftUI 的几个"强约束"
- View 生命周期固定
- 更新路径有限
- diff / 刷新由系统接管
你想写出"全局乱 rebuild"的代码，其实没那么容易。
iOS 为什么很少出现"越维护越卡"
不是因为大家更会写代码，而是：
- MVC / MVVM 的结构本身就限制了状态扩散
- TableView / CollectionView 强制复用
- cell 更新是"定点刷新"
很多 iOS 老项目：
- 代码很丑
- 架构很老
- 但列表就是不卡
这不是巧合，是系统设计替你兜底了。
代价也很明显
- 灵活度低
- 改 UI 成本高
- 跨端能力弱
iOS 的性能稳定，是用开发效率和自由度换来的。
长期维护下，三者的性能差异本质是什么？
如果只说一句话：
Flutter 和 RN 把性能责任交给开发者，iOS 把性能责任留在系统里。
再拆细一点：
Flutter：结构决定命运
- rebuild 边界是不是清晰
- 状态是不是分层
- 列表是不是惰性构建
这些不是"优化"，而是基础写法。
RN：通信成本不可逆
- 再多 memo，也绕不开 Bridge
- 状态越集中，抖动越明显
- 项目越大，维护越累
iOS：约束即保护
- 写法受限
- 心智模型稳定
- 性能问题更可预测
一个跨平台通用的"长期性能安全模型"
不管 Flutter / RN / iOS，其实都适用下面这套思路。
状态分三层，而不是一层
- UI 状态：是否选中、是否展开
- 业务状态：数据结构、网络结果
- 会话状态：用户、权限、全局配置
绝对不要让三者混在一起更新。
列表项必须是"可预测的纯组件"
- 输入是什么
- 输出是什么
- 什么情况下会变
一旦 renderItem / buildItem 里掺了外部状态，后期一定出问题。
永远假设：项目会被别人接手
长期性能问题，很多不是"你写错了"，而是：
- 下一任不知道这段代码的 rebuild 边界
- 不知道哪些 state 是安全的
- 不敢删、不敢动
写给未来的人看的代码，本身就是一种性能优化。
总结
Flutter、RN、iOS，并不存在"谁一定更快"。
真正的差异在于：
- 谁更容易写出长期稳定的结构
- 谁更容易在混乱中失控
- 谁替你兜住了哪些底线
Flutter 很强，但它要求你一直清醒 。
RN 很灵活，但它要求你一直克制 。
iOS 很保守，但它让你很难彻底翻车。
理解这一点，平台选择、架构选择、甚至团队分工，都会清晰很多。