韩大贫不想出名我最早接触 OpenHarmony 设备是因为一个车间排产看板项目。产线上的平板要实时展示每个工位的任务排期，横屏显示、按周滚动、支持双指缩放——说白了就是个甘特图。当时团队里没有人写过 ArkUI，但 Flutter 用了好几年，听说 Flutter for OpenHarmony 的社区版本已经能跑起来了，就咬咬牙定了这个技术方案。过程比预想的曲折，中间踩了不少坑，最后整体效果还算满意。这篇就把从环境准备到组件落地的完整链路整理出来，包括数据模型设计、时间轴算法、绘制层实现、手势交互和真机调试中的注意事项。
内容适合三类人看：要在 OpenHarmony 设备上做管理类/看板类应用的开发者，想了解 Flutter 跨端到 OpenHarmony 生态落地细节的移动端工程师，以及需要从零手写甘特图组件的 Flutter 开发者。我会把选型逻辑、核心算法、绘制细节和实测中遇到的问题尽量摊开说，不写太多虚的东西。
1. 项目背景：为什么要在 OpenHarmony 上做甘特图
1.1 业务需求是怎么来的
车间排产看板这类场景，数据形态天然适合甘特图：横轴是时间，纵轴是工位或任务，每个任务条在时间轴上的位置和长度直接代表排期区间，进度条展示完成比例。我们最初也考虑过用表格加日历的折中方案，但生产调度人员反馈说直观性不够——他们要看的是“一眼就知道某个时间段哪个工位在做什么”，以及“拖动时间轴看后续几周的排期”，这正好是甘特图最擅长的。
所以需求其实很简单：横屏平板设备上，左侧显示任务名称列表，右侧显示按时间展开的甘特图主体，支持双指缩放时间轴、左右拖拽平移、点击任务条查看详情、任务分组折叠。同时数据量不算小，单日排产任务可能在数百条量级，滚动和缩放要足够流畅。
1.2 技术选型对比：Flutter 并不是唯一选项
在 OpenHarmony 上做这个功能，摆在我面前的主要有三条路：用 ArkUI 原生开发、用 Flutter for OpenHarmony、用 React Native for OpenHarmony。三条路我都简单评估过。
| 方案 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| ArkUI 原生 | 系统级支持、性能最好、无跨层开销 | 团队学习成本高、生态组件少 | 对性能极致敏感、团队熟悉 ArkTS |
| Flutter for OpenHarmony | UI 一致性好、跨端复用能力极强、渲染自绘可控 | 社区维护版本滞后于上游、个别平台能力需走平台通道 | 已有 Flutter 技术栈、需要多端复用 |
| React Native for OpenHarmony | JS 生态丰富、热更新方便 | 复杂自绘场景性能不如 Flutter 可控 | 偏业务逻辑、不依赖高频自绘 |
我当时选 Flutter 的核心原因有三个。第一，团队有现成的 Flutter 经验和一套通用的图表/排期类组件，直接复用能把工期压缩很多。第二，甘特图的绘制本质上是一块自定义画布，Flutter 的 CustomPaint 在自绘复杂图形时非常顺手。第三，OpenHarmony 官方对 Flutter 的移植一直在推进，从最初的 Demo 阶段到现在已经具备工程化落地的条件。
1.3 Flutter for OpenHarmony 的社区进展
这里要先说清楚一个事实：Flutter for OpenHarmony 不是 Flutter 官方直接支持的平台，而是 OpenHarmony 社区（主要是 sig_flutter 组）基于 Flutter 引擎做的 OpenHarmony 平台适配。其核心思路是把 Flutter 的渲染层接入 OpenHarmony 的图形栈，同时通过 Platform Channel 机制让 Flutter 能调用 OpenHarmony 的底层能力。
在我做这个项目的阶段，社区版本已经支持了包括文本输入、网络请求、平台通道在内的大部分常用能力。虽然还不是“开箱即用”的官方状态，但做甘特图这种自定义绘制类组件，反而受平台插件生态影响较小，因为主要逻辑都在 Dart 层和 Canvas 绘制层，不太依赖第三方插件。这也算是一种“歪打正着”的适配选择。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境搭建：Flutter for OpenHarmony 的开发链路准备
2.1 工具链版本组合
搭建 Flutter for OpenHarmony 的开发环境，比普通 Flutter 开发要多一个环节：你不仅要装 Flutter SDK，还要装 OpenHarmony 的 SDK 和 DevEco Studio 用于打包、签名、真机调试。版本组合非常关键，我最初就是用错了版本组合导致编译反复失败。
我最终稳定使用的组合是：
- DevEco Studio 4.0 及以上版本（必须包含 OpenHarmony SDK）
- OpenHarmony SDK API 10 或更高版本
- Flutter SDK 使用社区维护的 OpenHarmony 分支（从 gitee 仓库拉取，不是官方 flutter 仓库）
- Java JDK 17（DevEco Studio 自带的 JBR 也行，但命令行编译时建议单独配置）
- hdc 工具（OpenHarmony 的命令行调试工具，对应 adb 的角色）
这里有个容易踩的坑：Flutter for OpenHarmony 的 SDK 分支更新很快，有些功能只有特定 commit 才有。建议固定到社区 release 版本，不要追最新 commit，除非你愿意每天面对编译错误。
2.2 创建工程与集成方式
Flutter 在 OpenHarmony 上的工程组织方式有两种，体验差别很大。
第一种是纯 Flutter 工程，类似 Android/iOS 的 Flutter 工程结构，入口是 Dart 代码，OpenHarmony 只是承载壳。这种方式跑通最快，适合验证原型和纯 Flutter 功能的开发。如果你只是做甘特图组件本身，用这种方式最省事。
第二种是在 OpenHarmony 工程中集成 Flutter Module，把 Flutter 页面作为 OpenHarmony 应用的一部分。这种方式更贴近真实项目，因为一个完整的 OpenHarmony 应用肯定有 ArkUI 页面、系统能力调用等，甘特图只是其中一屏。缺点是需要同时理解 ArkTS 工程和 Flutter 工程的构建流程，配置复杂度高不少。
我当时因为要快速验证渲染效果，先用了纯 Flutter 工程把组件跑通，后来又抽了一个下午把 Flutter Module 集成进正式的 OpenHarmony 工程。如果你们项目从零开始，我建议直接用第二种方式，省得后面还要迁移。
2.3 真机连接、运行与调试
连真机调试的时候，最大的问题是设备识别。OpenHarmony 设备通过 hdc 连接，和 adb 的使用习惯类似，但命令不完全一样。
常用命令：
bash复制# 查看已连接的设备列表，能看到 devudid 和 serial
hdc list targets
# 安装 hap 包
hdc install entry-default-signed.hap
# 查看设备日志（类似 adb logcat）
hdc hilog
# 截图，排查布局问题时很好用
hdc shell snapshot_display -f /data/local/tmp/screen.png
hdc file recv /data/local/tmp/screen.png ./screen.png
我在 RK3568 开