Flutter 是什么：原理、场景与对比
Flutter 是 Google 开源的跨端 UI 框架，用一套 Dart 代码同时构建 Android、iOS、Web、Windows、macOS、Linux 应用。它和"把 JS 映射成原生控件"的思路不一样：Flutter 自带渲染引擎，界面由框架自己画到画布上，因此各平台的表现高度一致，也让"一套代码多端"从口号变成了可验收的工程事实。本章先把定位讲清楚，再拆开渲染原理，最后用对照表说明它和 React Native、原生开发、小程序方案的差别，以及哪些项目不该选它。
一句话定位
- 一套代码多端：业务逻辑与 UI 都写在 Dart 里，编译到六个平台，差异只留在少量插件层。
- 声明式 UI：写的是"界面应该长什么样"，而不是"先创建控件再一条条改属性"。
- 自带引擎：Skia（旧版默认）与 Impeller（Flutter 3.10 后在 iOS、3.27 后在 Android 逐步默认）直接调用 GPU。
# 查看当前版本与支持的设备，确认引擎与目标平台
flutter --version
flutter devices
自绘渲染：Flutter 为什么快
原生方案要跨语言边界调用平台控件，一帧里来回通信多次；Flutter 把整棵界面树在 Dart 侧算完，只把绘制指令交给 GPU，跨端一致性因此很强。
Widget（不可变配置）→ Element（实例与生命周期）→ RenderObject（布局/绘制）→ Layer → GPU
每次 build 重建 复用、按需更新 计算约束与尺寸 合成上屏
这条链路是后面所有章节的主线：你写的 Widget 只是一份"配置描述"，真正干活的是 RenderObject。
最小可运行示例
新建工程后把 lib/main.dart 换成下面内容，即可看到跨端一致的自绘界面：
import 'package:flutter/material.dart';
void main() => runApp(const MyApp());
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return MaterialApp(
title: 'Flutter 演示',
theme: ThemeData(colorScheme: ColorScheme.fromSeed(seedColor: Colors.teal)),
home: const HomePage(),
);
}
}
class HomePage extends StatelessWidget {
const HomePage({super.key});
@override
Widget build(BuildContext context) {
// 同一份 build 方法在六个平台上产出完全一致的界面
return Scaffold(
appBar: AppBar(title: const Text('一套代码，多端运行')),
body: const Center(child: Text('Hello Flutter 3.x')),
);
}
}
与主流方案对比
| 维度 | Flutter | React Native | 原生（Kotlin/Swift） | uni-app |
|---|---|---|---|---|
| 渲染方式 | 自绘引擎，直连 GPU | 映射到原生控件（新架构走 Fabric） | 系统原生控件 | 小程序/WebView + 部分原生 |
| 多端一致性 | 很高，像素级接近 | 中等，平台控件差异需适配 | 各端各写 | 一般，端差异较多 |
| 性能上限 | 高，接近原生；复杂动画稳 | 中等，桥接与列表是瓶颈 | 最高 | 中低，依赖 WebView |
| 生态成熟度 | 中等偏上，官方插件质量好 | 大，npm 复用方便 | 最大 | 国内小程序生态好 |
| 包体积 | 偏大，空包约 8~15 MB | 较小 | 最小 | 小 |
| 上手成本 | 需要学 Dart 与 Widget 体系 | 会 React 就能上手 | 需分别学两套技术栈 | 会 Vue 就能上手 |
| 适合场景 | 多端一致、动画与定制 UI 重 | 已有 React 团队、业务型 App | 极致性能、深度系统能力 | 小程序 + 简单 App |
先明确一句：没有"最好"的框架，只有匹配当前团队与目标的框架。
什么项目适合、什么项目不适合
| 项目特征 | 建议 | 理由 |
|---|---|---|
| 多端 UI 一致、定制主题多 | 适合 | 自绘引擎省掉大量平台适配 |
| 团队已有 React 或前端背景 | 谨慎 | Dart 是新语言，学习成本是真实成本 |
| 需要极致包体积（工具类小应用） | 不适合 | 引擎体积无法裁剪到很小 |
| 需要深度系统能力（蓝牙、后台常驻） | 谨慎 | 依赖插件，必要时仍需写平台代码 |
| 复杂动效、直播交互界面 | 适合 | 单帧内自绘，滚动与动画稳定 |
| 一次性 H5 活动页 | 不适合 | WebView 或普通 H5 更划算 |
常见误区
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 以为"一套代码"等于零适配 | 上线后各端细节崩 | 预留 10%~20% 的平台适配工作量 |
| 拿 Flutter 做 Web 站点的 SEO | 首屏与收录都吃亏 | 内容型站点用服务端渲染或静态站点 |
| 一开始就上重型状态管理 | 样板代码淹没业务 | 先用 setState，确有共享需求再引入 |
| 只在一台设备上验证 | 平板、折叠屏上布局溢出 | 用 LayoutBuilder 与多尺寸真机回归 |
小结：Flutter 的核心竞争力是自绘引擎带来的多端一致性与稳定动画性能，代价是包体积偏大、需要学 Dart、深度系统能力依赖插件；选型时先确认多端一致是否真的是主要矛盾，再决定用它还是用原生或 H5。