IT巫师1. 先聊清楚：Flutter在OpenHarmony上到底能跑成什么样
做跨端开发这几年，我一直有个执念：一套UI代码能不能在尽可能多的系统上跑出接近原生的效果。Android、iOS、Web、Windows、macOS、Linux都试过了，Flutter的跨端能力确实没得挑。但当OpenHarmony的设备越来越多出现在我面前时，我意识到一个新的问题：Flutter能跑在OpenHarmony上吗？怎么跑？
先说结论：能跑，而且跑得比大多数人想象中要稳。OpenHarmony社区维护了一个专门的Flutter分支，从代码仓库到编译工具链都做了适配。我在RK3568开发板和鸿蒙模拟器上都实际跑过Flutter应用，基础布局组件、手势交互、动画、平台通道这些核心能力都能正常工作。拿待办清单这种典型的CRUD应用来练手，UI层面几乎没有遇到跨端迁移的障碍。
但这里有个关键认知要纠正：Flutter for OpenHarmony不是把官方Flutter直接拿过来用，而是OpenHarmony SIG组在Flutter官方代码基础上维护的一套分支。版本迭代节奏、依赖管理方式、原生插件的接入方式都和官方版有差异。你在pub.dev上随便拉一个插件，并不能保证它在OpenHarmony上能编译通过，因为很多插件底层依赖的是Android或iOS的原生API，OpenHarmony并没有这些接口。
所以我的建议是：别把Flutter for OpenHarmony想象成"什么都能跑的万能钥匙"，它更像一套正在快速成熟的工具链。适合你用它来做业务界面、状态管理、布局渲染、基础交互，遇到需要调用系统能力的地方，再通过平台通道（Platform Channel）去适配OpenHarmony侧的接口。比如你要调用鸿蒙的图库、拉起鸿蒙的IAP支付，就得走双层适配：Flutter层写Dart逻辑，OpenHarmony侧用ArkTS或C++实现原生接口，两边通过MethodChannel通信。
从我个人的实践看，用Flutter做OpenHarmony应用的UI层和业务逻辑，开发效率比直接用ArkUI写要高不少。尤其是如果你已经有一份Flutter代码库，迁移到OpenHarmony的成本主要在于适配原生依赖和测试验证，界面代码基本可以原封不动地保留。这对于团队里同时维护Android、iOS、鸿蒙多端应用的人来说，价值非常大。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 开工前的硬功夫：SDK、设备树与开发环境搭建
纸上谈兵没用，先把手上的开发环境理顺。我用的是Flutter for OpenHarmony的开源分支，仓库地址在Gitee上的OpenHarmony SIG组织下，搜索flutter_flutter就能找到。注意别从pub.dev或者flutter官网拉SDK，那个是官方分支，不支持OpenHarmony的编译目标。
2.1 拉取SDK分支与版本选择
我使用的是OpenHarmony-3.2-Release对应的Flutter分支，这个版本相对稳定，社区示例多，遇到问题也容易搜到解决方案。拉代码没什么特殊之处：
bash复制git clone https://gitee.com/openharmony-sig/flutter_flutter.git -b OpenHarmony-3.2-Release
拉下来之后，把bin目录配置到PATH环境变量里，然后运行flutter doctor检查环境。这里会看到一个细节：Flutter for OpenHarmony的doctor输出里，Android工具链那栏可能显示不正常，这是正常的，因为这套分支的编译目标不是APK，而是OpenHarmony的应用包。真正的检查项是看OpenHarmony SDK路径和编译工具是否识别到了。
2.2 设备树到底怎么选：不看文档看硬件
热搜里那句"openharmony的rk3568有许多设备树到底咋选"我太有感触了。RK3568这颗芯片被大量OpenHarmony开发板采用，但不同板子的外设配置千差万别，同一个芯片对应好几套设备树文件。选错了，轻则某些外设驱动加载失败，重则系统根本起不来。
我的经验是：别只看板子供货商的文档，直接看设备树文件里的硬件配置。把rk3568开头的.dts文件逐个打开，对照你手里板子的实际硬件去匹配。比如你的开发板用的是哪个型号的屏幕触摸IC、哪个WiFi模组、哪个音频编解码器，设备树里都有明确节点。匹配上了再编译烧录，成功率能提高一大截。纯小白的话，优先选DAYU200这种社区支持最充分的开发板，它的设备树配置被验证过太多次了，出问题的概率最低。
2.3 模拟器、x86电脑与真机的取舍
热搜里还有"鸿蒙模拟器电脑版""开源鸿蒙x86iso下载""电脑版x86 openharmony"这些词，说明很多人想先在电脑上把环境跑通，再上真机。这个思路没毛病，我一开始也是这么干的。
用模拟器或x86版本的OpenHarmony跑Flutter应用，优势在于调试迭代快，不用反复烧录开发板。但要注意架构差异带来的坑：x86模拟器上编译的Flutter运行时，搬到一个ARM架构的RK3568真机上，是没法直接跑的，必须分别编译出对应架构的产物。
所以我现在的流程是：先在模拟器上把UI和业务逻辑调通，再用RK3568真机做最终验证，重点测试性能、屏幕适配、字体渲染这些模拟器上不容易暴露的问题。
2.4 创建工程与HAP打包
工程创建上，Flutter for OpenHarmony的流程和官方Flutter基本一致：
bash复制flutter create todo_app
cd todo_app
但你在工程目录里会发现多了ohos目录，这就是OpenHarmony的壳工程。编译构建的时候，Flutter代码会被编译成so库，打包进OpenHarmony的应用安装包里。说到热词里的"可以打包成hap、hsp、har的鸿蒙demo"，要理清三者的区别：hap是应用安装包，hsp是动态共享包（类似Android的split APK），har是静态共享包（类似Android的AAR库）。Flutter for OpenHarmony编译出来的主应用会打成hap格式，如果你的业务里有模块需要动态加载，可以考虑把Flutter产物拆到har或hsp里。
这一步最容易出问题的是工程配置里的包名、签名信息和模块依赖。OpenHarmony对应用签名有严格校验，调试阶段需要在工程的build-profile.json5里配置签名信息，否则安装不到真机上。模拟器上还能放松一些，真机部署就绕不过去。
3. 动手之前先把界面切成块：待办清单的信息架构
正式开始写布局之前，我先讲讲为什么我把大量时间花在"画图"而非"写代码"上。Flutter的布局组件选择非常灵活，同一个界面可以有七八种实现方式，但如果一开始没想清楚界面结构，代码写到一半就会开始失控：这里嵌套太深、那里约束冲突、列表滑动和悬浮按钮互相遮挡，越往后改越痛苦。
3.1 待办清单的功能分区
这个系列文章的待办清单项目，我规划了四个核心区域：
- 顶部输入区：一个TextField输入框加一个添加按钮，用来录入新的待办事项。
- 主列表区：展示待办事项列表，每条待办就是一个卡片，包含完成状态勾选框、事项描述文本、删除按钮。
- 底部统计区：显示当前待办总数、已完成数量，以及一个清空已完成事项的按钮。
- 悬浮添加按钮：固定在右下角，点击以后聚焦到输入框，方便单手操作。
这四个区域分别对应Flutter里不同类型的布局容器：输入区适合用Row横向排列，列表区用ListView纵向滚动，底部统计区用Row