1. Flutter工程化开发导论
Flutter 的核心价值不只是“写一套代码跑多个平台”,而是把界面、渲染、业务逻辑和平台能力组织成一套可复用、可测试、可交付的工程体系。理解这一点,才能从“会写页面”进入“能做项目”的阶段。本章先建立三个基础认知:Flutter 为什么能跨平台、工程化视角下项目由哪些层次构成、以及如何搭建一个可长期迭代的开发环境。
1. Flutter 跨平台原理:不是翻译代码,而是自带渲染引擎
很多跨平台方案的做法是:把 JavaScript 或 Dart 代码映射成原生控件,再由系统控件完成绘制。Flutter 走的是另一条路:它用 Dart 编写业务与界面,但界面并不直接依赖 Android 的 View 或 iOS 的 UIView,而是由 Flutter 自己的渲染管线完成布局、绘制和合成。可以把它理解为“应用自带一套渲染引擎”,平台只负责提供画布、输入事件和底层能力。
这条链路可以概括为:Dart 代码 → Widget 树 → Element 树 → RenderObject 树 → Layer 树 → GPU 合成。Widget 是配置描述,Element 是运行时实例,RenderObject 负责布局与绘制,Layer 负责合成。理解这条链路的意义在于:当页面出现性能问题、状态不更新或布局异常时,你能判断问题出在“配置层”“实例层”还是“渲染层”,而不是盲目改代码。
2. 工程化视角:从“能跑”到“可维护、可交付”
一个 Flutter 项目在演示阶段可能只有几个页面,但进入真实工程后,会迅速遇到多环境、多平台、多团队协作的问题。工程化视角要求我们把项目拆成清晰的层次,并约定好每层的职责边界。
表现层负责页面、组件、主题和路由,关注“怎么展示”;领域层负责状态管理、业务用例和数据模型,关注“业务规则是什么”;平台适配层负责调用相机、定位、文件、通知等原生能力,关注“不同平台怎么对接”;工程支撑层负责测试、构建、CI 和发布,关注“怎么稳定交付”。这四层不是必须严格隔离的目录结构,而是一种思考方式:当需求变化时,你知道应该改哪一层,而不是把逻辑散落在页面里。
以课程贯穿案例“任务清单 App”为例,它包含任务列表、新增任务、完成状态切换、本地持久化和多平台运行。这个案例足够小,能在一章内跑通;又足够完整,能覆盖状态管理、路由、本地存储、平台差异和构建发布等工程问题。后续章节会围绕它逐步扩展,而不是每章换一个新 Demo。
3. 开发环境搭建:把工具链一次装对
Flutter 开发环境的核心是 Flutter SDK、Dart SDK、平台工具链和编辑器插件。Flutter SDK 自带 Dart SDK,因此不需要单独安装 Dart。安装完成后,用 flutter doctor 检查环境,它会逐项报告 Android、iOS、Web、桌面和编辑器插件的状态。
# 1. 下载并解压 Flutter SDK 后,将 flutter/bin 加入 PATH
# 2. 检查环境
flutter doctor -v
# 3. 接受 Android 许可
flutter doctor --android-licenses
# 4. 创建课程项目
flutter create --org com.example --project-name task_app task_app
# 5. 查看可用设备并运行
flutter devices
flutter run -d chrome
flutter run -d windows
执行 flutter doctor -v 后,重点看三类信息:Android toolchain 是否显示 “Android SDK ... licenses accepted”;Chrome 和 Edge 是否被识别为 Web 设备;Visual Studio 或 Xcode 是否满足桌面/移动构建要求。如果 Android 许可未接受,运行 flutter doctor --android-licenses 并全部输入 y;如果 Web 设备未出现,检查 Chrome 是否安装、CHROME_EXECUTABLE 是否指向正确路径。
flutter create 时显式指定 --org 和 --project-name,避免后期修改包名带来的连锁问题。课程案例统一使用 com.example.task_app 作为示例包名。4. 项目结构与第一轮验证
创建完成后,项目根目录会出现 lib/、android/、ios/、web/、test/ 和 pubspec.yaml。lib/main.dart 是入口,pubspec.yaml 管理依赖和资源。第一轮验证不需要写复杂功能,先确认三件事:应用能在至少两个平台启动、热重载生效、flutter test 能跑通默认测试。
可以先把 main.dart 改成最小可运行版本,再逐步加入任务列表。判断环境是否真正可用,不看“是否安装成功”,而看“能否完成一次修改—热重载—观察结果”的闭环。如果热重载后界面没有变化,优先检查是否修改了 main() 入口或原生配置;如果多平台运行结果不一致,优先检查平台适配层是否使用了不支持的 API。
flutter doctor 直接写业务代码。环境问题越晚发现,排查成本越高;尤其是 Android 许可、Xcode 签名和 Web 渲染器配置,往往在构建阶段才暴露。