1.1 为什么是 Flutter：一份代码的承诺与代价
1.1 为什么是 Flutter：一份代码的承诺与代价
本节摘要：跨平台不是免费的午餐。本节先算清"每个平台各写一套"的真实成本，再看 Flutter 以自绘引擎换来了什么、又付出了什么，最后给出一套可操作的选型判断。读完你将能回答：这个项目到底该不该用 Flutter。
先算一笔账：三份代码的真实成本
在 Flutter 出现之前，一家想做 Android 和 iOS 应用的公司，标准配置是两条产品线：Kotlin 或 Java 一条，Objective-C 或 Swift 一条。成本远不止"代码写两遍"这么直白。
第一个坑是人力结构。两套代码意味着两组工程师，各自熟悉各自的工具链。招人、排期、代码评审、知识沉淀，全部乘以二。团队小的时候更疼：三个人的移动组要拆成两组，每组不到两人在维护一个完整应用。
第二个坑是功能对不齐。产品经理提一个需求，两端各写一遍，逻辑细节难免走样。轻记账项目原型期就遇过：Android 端把"本月支出"按自然月统计，iOS 端却按账单周期——两边的代码都没错，错的是逻辑写了两遍。测试也要翻倍：同一轮用例在两端各跑一次，缺陷单里的"复现步骤：仅 iOS"从此成为常态。
第三个坑最隐蔽：体验分叉。两端各自调用平台控件，视觉细节随系统版本漂移。设计师给了一份标注稿，两端各还原一遍，还原度永远差着几个像素，而 Pixel 级的对比评审本身就是一份全职工作量。
把这些坑摆出来，就能理解跨平台框架的吸引力：业务逻辑写一遍，界面写一遍，测试主体跑一遍。剩下的问题只有一个——用什么代价换这份"一遍"。
版图上的四个流派
把主流方案按"界面从哪来"分类，分歧立刻清晰：
| 流派 | 代表 | 界面来源 | 逻辑运行位置 | 观感一致性 |
|---|---|---|---|---|
| 原生双线 | Kotlin / Swift | 平台控件 | 各端各自编译 | 无（本来就是两套） |
| 桥接映射 | React Native | 映射为平台控件 | JS 引擎 | 跟随系统版本漂移 |
| 自绘引擎 | Flutter | 引擎直接画像素 | Dart AOT 机器码 | 逐像素一致 |
| 共享内核 | Kotlin Multiplatform | 各端原生写 UI | Kotlin 编译到各端 | 无（UI 不共享） |
桥接流派（React Native、早期 Ionic）的思路是"逻辑共享，界面委托给系统"：JS 写布局，框架把布局翻译成原生控件。好处是观感天然像原生，代价是中间隔着一层桥——数据序列化过桥、渲染指令过桥，列表一长、动画一密，桥就成了瓶颈；系统升级还可能改变原生控件行为，去年的还原度今年突然不对。
自绘流派（Flutter、以及游戏引擎出身的方案）反其道行之：界面不找系统要，自己拿到一块画布自己画。系统只提供窗口和输入事件，从按钮到滚动列表全部由 Flutter 的引擎直接绘制。观感逐像素可控、性能上限接近原生，代价是安装包里要背一个渲染引擎（几 MB 起步），且"像不像原生"完全取决于框架自己的两套观感库（Material 与 Cupertino）做得像不像。
共享内核流派（KMP）共享逻辑、不共享 UI，适合原生团队只想消除业务逻辑重复的场景。它与 Flutter 不是非此即彼——不少团队用 KMP 共享数据层、用各端原生写界面，或者反过来。
图 1 跨平台方案对比矩阵：从界面来源到落地代价
Flutter 交出的答卷与账单
答卷方面，Flutter 的关键决定是连渲染都不委托。它自带排版（文本布局自己算）、合成与光栅化（Skia，新版换成 Impeller），因此同一份界面代码在 Android 与 iOS 上输出逐像素一致的结果——轻记账的统计图表在两个平台连抗锯齿的表现都相同，这对要"所见即所得"的产品是实打实的减负。性能上，发布包里的 Dart 代码被 AOT 编译成本机机器码，没有解释器开销，也没有桥；热重载则走另一条路（JIT），第 2 章会展开。
账单同样要念清楚。其一，包体积：空工程打包后也比原生空壳大出一段，引擎和 Dart 运行时是固定开销。其二，平台新特性有时差：系统发布新 API，要等 Flutter 生态提供插件，或者自己走平台通道封装（第 7 章的内容）。其三，动态化受限：Apple 与 Google 的政策下，Flutter 应用不能像某些 Hybrid 方案那样下发脚本热更新业务代码，发版节奏要跟着应用商店走。其四，团队要学 Dart——好在它对 Java、Kotlin、TypeScript 背景的人非常友好，下一节会专门讲。
选型判断：什么项目适合，什么项目慎重
结合轻记账这类中小型产品的经验，给一份可操作的判断清单：
适合上 Flutter：界面形式多、迭代快、两端要求体验一致的业务应用（工具、电商、内容、轻社交）；移动团队人手不足以维护两套代码；后续可能要延伸到桌面或 Web 的产品——同一套代码的边际成本很低。
慎重：重度依赖系统最新特性（如当天上线的系统级新 API）、需要应用内动态下发业务代码、或已有庞大原生存量且只想去重的项目。最后这类，Add-to-App（第 7 章）或 KMP 可能更合身。
还有一个常被忽略的维度：招聘与团队形状。Flutter 把 Android 与 iOS 工程师从"平台专家"变成"业务工程师 + 平台接口人"，多数业务逻辑不再需要平台知识，平台知识集中收敛到少数封装插件的人手里。这对小团队是解放，对大团队则要求重新划分职责。
本节要点回顾
- 跨平台的真实成本在人力结构、功能对齐、体验分叉三处，代码翻倍只是表象；
- 按"界面从哪来"分类：桥接映射观感随系统漂移，自绘引擎逐像素一致，共享内核不共享 UI；
- Flutter 用自带引擎换一致性，代价是包体积、平台新特性时差与动态化受限；
- 选型看三点：界面迭代密度、两端一致性要求、对系统新 API 的依赖程度；
- 业务应用是 Flutter 的主场，重度系统集成的项目要慎重或配合 Add-to-App。
下一节把"自绘"这个词拆开：同一份 Dart 代码，在各端到底变成了什么，又是谁把它画到屏幕上的。