谁在把 Flutter 搬到鸿蒙？——CPF-Flutter 2026 Q2 社区报告与 3.41.9-ohos 解读

sdp安歌

1100人浏览 · 2026-09-22 23:10:51

sdp安歌 · 2026-09-22 23:10:51 发布

本文基于两份公开材料交叉分析：

CPF-Flutter 2026 年第二季度社区贡献报告 —— 统计周期 2026-04-01 ~ 2026-06-30，披露社区贡献者的全量名单与里程碑
CPF-Flutter/flutter_flutter 的 oh-3.41.9-release 分支 —— 当前最新的 OpenHarmony 适配发布分支（基于上游 Flutter 3.41.9）

一份是"人"的数据，一份是"代码"的状态。"谁在把 Flutter 搬到鸿蒙"这个问题，答案就藏在这两份材料里：一份列出了 278 个贡献者 ID，一份记录了他们产出的代码。把两者放在一起看，能回答一个开发者真正关心的问题——Flutter 鸿蒙化这件事，是靠什么机制持续产出可用版本的？

一、先看两组数字

1.1 社区侧：一个季度的产出

2026 年第二季度，CPF-Flutter 社区交出的数据是：

指标	数值
本季度合并 PR 数量	1891
本季度有效 Issue 数量	2695
本季度新增贡献者人数	88
本季度 PR Review 参与人数	50
本季度社区帮扶参与人数	36
累计贡献者总人数	278
本季度活跃贡献者人数	207

三个月的合并 PR 数接近 1900，按季度约 65 个工作日折算，平均每个工作日约 29 个 PR 被合入；有效 Issue 2695 个，平均每个工作日约 42 个问题被确认。同时，278 位累计贡献者中有 207 位在本季度保持活跃，活跃率约 74%——这不是一个"少数人扛着走"的项目结构。

1.2 版本侧：3.41.9-ohos 的当前状态

截至本文撰写时，oh-3.41.9-release 分支的最新提交为：

项目	值
分支 HEAD	`5e4dc66b7cbd`（`!2119 merge version/3.41 into oh-3.41.9-release`）
最后更新	2026-09-22
上游基线	Flutter 3.41.9（commit `00b0c91f`）
引擎版本标记	`4cbeea6a36f7`（`engine.ohos.version` 与 `engine.ohos.har.version` 一致）
仓库分支总数	52
仓库 Tag 总数	72
首个 Release Tag	`3.41.10-ohos-1.0.0`（2026-07-29）
当前最新 Tag	`3.41.10-ohos-1.0.1`（2026-08-17）
下一版本开发分支	`oh-3.44.9-dev`（3.44 适配已在推进）

值得注意的是仓库结构的变化：Flutter 3.41.9 版本起，Engine 源码已合并进仓库的 engine/ 目录，不再需要单独克隆 Engine 仓库。这个调整直接降低了开发者的环境搭建成本。

二、社区是怎么组织生产的

贡献报告里最有价值的不是总量，而是分层结构。报告把贡献明确拆成四种类型，并给出了各自的人数和口径：

贡献类型	人数	口径说明
本季度合并 PR 贡献者	71	本季度内 merged 的 PR 作者（按 merged_at 判定，剔除机器人）
本季度有效 Issue 贡献者	163	本季度创建、非机器人、非 PR 引用、未打 invalid 类标签的 Issue 作者
本季度 PR Review 参与者	50	本季度在他人 PR 下发表过评论的用户
本季度答疑贡献者	36	本季度在他人 Issue 下评论数 ≥ 3 的用户

这个分类本身就是一种治理态度：它承认"提 Issue"和"答疑"是贡献，而不仅仅是"写代码"。 163 位 Issue 贡献者是代码贡献者（71 位）的两倍多，36 位答疑贡献者在社区里持续消化新人问题——这正是 278 人规模社区能维持 74% 活跃率的原因：入口足够多，参与门槛足够低。

2.1 里程碑体系：把"持续贡献"变成可累积的荣誉

报告设了四级里程碑，按三通道达标（任一通道达到阈值即可）：

里程碑	达成条件	人数
💎 传奇（Platinum）	累计合并 PR ≥ 300 或累计 Review PR ≥ 300 或累计有效 Issue ≥ 300	2
🥇 卓越（Gold）	累计合并 PR ≥ 100 或累计 Review PR ≥ 100 或累计有效 Issue ≥ 100	23
🥈 笃行（Silver）	累计合并 PR ≥ 50 或累计 Review PR ≥ 50 或累计有效 Issue ≥ 50	18
🥉 初心（Bronze）	累计合并 PR ≥ 10 或累计 Review PR ≥ 10 或累计有效 Issue ≥ 20	80
合计		123

几个设计细节值得注意：

"三通道"意味着不逼迫所有人写代码。 @ohci1 累计合并 PR 为 0，但 Review PR 达 125 次，直接达到卓越级；@harmonydev 合并 PR 仅 25，Review 却有 129 次，同样进入卓越。@wu_leilei 合并 PR 8 个、Review 238 次——社区明确认可"审查他人的代码也是一种重要贡献"。

门槛设计覆盖了长尾。 初心里程碑只需累计 10 个 PR 或 20 个 Issue，80 人达成。对刚参与共建的开发者来说，这个门槛是够得着的，而不是"要么卓越要么隐身"。

里程碑跨季度累积、永久保留。 报告明确"达到更高里程碑时，低级别里程碑自动保留"，这让贡献成为一项长期资产，而不是季度考核。

2.2 贡献者 ID 与公司解绑

报告里有一句话写得很清楚：

贡献者 ID 与个人绑定，不与公司绑定（参照 ASF Hats 原则）

这是 Apache 软件基金会的经典原则——功劳归于个人，而非雇主。报告还补充说明"公示贡献者 ID 不影响 CLA/DCO 层面的知识产权归属"，并提供了以公司或组织名义公示的申请通道。对一个大厂工程师与个人开发者混合参与的社区而言，这条规则保证了两种身份在榜单上被同等对待。

2.3 数据可纠错

报告末尾给了纠错通道和具体邮箱，并主动承认局限：

我们会尽最大努力保证数据的准确性，但难免会出现数据统计出错、分类错误（比如 Issue 被误判无效）的情况。

一个把统计口径（含"剔除机器人""未打 invalid 类标签"这类细节）和纠错方式都公开的社区，其数据的可信度是可验证的——这比只公布一个漂亮的总数更有说服力。

三、谁在写 3.41.9

把 Q2 贡献名单与 oh-3.41.9-release 分支的实际提交交叉比对，可以看到榜单与代码之间是对得上的。

oh-3.41.9-release 近期的提交者中，多位都是 Q2 榜单上的活跃贡献者：

贡献者	Q2 表现	在 3.41.9 分支的工作
`@liujiake`	合并 PR 12（累计 265），💎 传奇	`feat(flex_overflow): dynamic DPI overflow strategy with testing API and unit tests`
`@Kemin123`	合并 PR 25（累计 119），🥇 卓越	修复 TextFrame 共享渲染数据问题（同步上游 PR 182886）
`@zhong_ning`	合并 PR 134、有效 Issue 246，双榜 🥇 卓越	OHOS 模板 targetSdkVersion 升级至 26.0.0、更新 oh flutter 图标、Impeller 文本 UT 迁移修复
`@huhaodong`	合并 PR 22，🥉 初心	`fix(ohos): restore plugin state after ability recreation`
`@lx123546879`	合并 PR 8、有效 Issue 38，🥇 卓越	修复滑动丢帧时的总帧数统计问题、新增 ArkTS 代码门禁检测脚本
`@luqi_tan`	合并 PR 22、答疑 296 条（榜首），🥉 初心	更新 PR 描述模板，适配 OHOS 仓库规范

这里有两点值得展开：

第一，Issue 贡献者在解决自己提的问题。 @zhong_ning 本季度提了 246 个有效 Issue，同时合入 134 个 PR。在 Flutter 鸿蒙化这类"边用边发现问题"的场景里，最了解问题的人往往就是提出问题的人，而社区的机制让这条路径是通的——提 Issue 和提 PR 都会被公示。

第二，答疑榜首也是代码贡献者。 @luqi_tan 以 296 条答疑评论位居帮扶榜第一，同时保持 22 个合并 PR。社区没有把"答疑"和"开发"分成两拨人。

四、3.41.9-ohos 的技术现状

4.1 版本规划：4 个月的适配周期

flutter_flutter 仓库 README 给出了明确的版本规划表：

Flutter 版本	源社区发布时间	Flutter OH 版本发布时间	间隔时间
Flutter 3.35	2025/08	2026/03	7 个月
Flutter 3.41	2026/02	2026/06	4 个月
Flutter 3.44	2026/05	2026/09	4 个月
Flutter 3.47	2026/08	2026/12	4 个月

从 3.35 的 7 个月缩短到 3.41 之后的稳定 4 个月，适配周期已经收敛。这意味着选择 Flutter OH 的团队可以据此做技术规划：上游发版后约一个季度，鸿蒙适配版就会跟上。

4.2 稳定版获取方式

推荐基于版本 tag 获取稳定版，tag 命名规则为 <上游版本+1>-ohos-X.X.X：

源社区版本	OpenHarmony 适配稳定版本	版本 tag
3.41.9	3.41.9-ohos-x.x.x	`3.41.10-ohos-x.x.x`
3.35.7	3.35.8-ohos-x.x.x	`3.35.8-ohos-X.X.X`
3.27.4	3.27.4-ohos-x.x.x	`3.27.5-ohos-X.X.X`
3.22.0 / 3.22.3	3.22.0-ohos-x.x.x / 3.22.3-ohos-1.1.3	`3.22.1-ohos-X.X.X` / `3.22.4-ohos-x.x.x`
3.7.12	3.7.12-ohos-x.x.x	`3.7.12-ohos-X.X.X`

注意 tag 号与版本号差 1（3.41.9 → 3.41.10-ohos-*），这是该仓库的既定规则，选版本时不要看错。

4.3 已适配的指令集

3.41.9 版本已适配的 OpenHarmony 相关指令：

指令	描述	使用说明
`doctor`	环境检测	`flutter doctor`
`config`	环境配置	`flutter config --<key> <value>`
`create`	创建新项目	`flutter create --platforms [ohos,android,ios] --org <org> <appName>`
`create`	创建 module 模板	`flutter create -t module <module_name>`
`create`	创建 plugin 模板	`flutter create -t plugin --platforms [ohos,android,ios] <plugin_name>`
`create`	创建 plugin_ffi 模板	`flutter create -t plugin_ffi --platforms [ohos,android,ios] <plugin_name>`
`devices`	已连接设备查找	`flutter devices`
`install`	应用安装	`flutter install -t <deviceId> <hap文件路径>`
`assemble`	资源打包	`flutter assemble`
`build`	测试应用构建	`flutter build hap --debug [--target-platform ohos-arm64] [--local-engine=<...>]`
`build`	正式应用构建	`flutter build hap --release [--target-platform ohos-arm64] [--local-engine=<...>]`
`run`	应用运行	`flutter run [--local-engine=<...>]`
`attach`	调试模式	`flutter attach`
`screenshot`	截屏	`flutter screenshot`
`pub`	获取依赖	`flutter pub get`
`clean`	清除项目依赖	`flutter clean`
`cache`	清除全局缓存数据	`flutter pub cache clean`

一个重要的变化：构建 Hap 现在直接执行 flutter build hap 即可，不再需要 --local-engine 参数，产物从云端获取。这大幅简化了 CI 配置。

4.4 3.41 稳定性修复记录

社区维护的《3.41 稳定性历史修复汇总》记录了 3.41.9-ohos-0.0.1 阶段的修复，共 5 项，集中在窗口屏幕与 Plugin/Channel 两类：

窗口屏幕类

问题	影响模块	提交
设备旋转后界面黑屏	flutter_engine	`b2778ff9a6`
点击状态栏时滚动组件回顶失效	flutter_flutter	`d7f649f76d`

PluginChannel 类

问题	影响模块	提交
OHOS 平台插件注册失败	flutter_flutter	`ec32c187bb`
`setApplicationLocale` 原生侧接收失败	flutter_flutter	`01d6713d15`
OHOS 侧 `SetSemanticsTreeEnabled` 未生效	flutter_flutter	`2118f990b4`

文档同时说明：3.41 作为较新版本，修复内容较少，主要聚焦窗口屏幕和 Plugin/Channel 相关问题——这是符合预期的，新版本的问题密度会随版本成熟度下降，而积累的修复记录会像 3.22/3.27/3.35 那样逐版增多。

4.5 分支策略

仓库当前有 52 个分支，命名规则清晰：

oh-<上游版本>-release：发布分支（如 oh-3.41.9-release、oh-3.35.7-release）
oh-<上游版本>-dev：开发分支（如 oh-3.41.9-dev、oh-3.44.9-dev）
版本线并行维护：3.22 / 3.27 / 3.35 / 3.41 / 3.44 各有独立分支

多版本线并行对企业存量项目很关键：锁在 3.22 的项目仍能获得该版本线的修复，而不必被迫大版本升级。默认分支当前为 oh-3.35.7-release，而 3.41 已发布正式 tag、3.44 已在开发中。

五、两条线的交汇点

把社区数据和技术状态放在一起，能看到几个相互印证的结论。

5.1 贡献机制解释了版本节奏的稳定性

3.41 适配周期从 7 个月压缩到 4 个月，靠的不是加班，而是分工结构的成型：

71 位代码贡献者分摊了 1891 个 PR，单人平均约 27 个，头部 10 人合计贡献 1080 个 PR（占总量约 57%）
50 位 Review 参与者保证合入质量，@wu_leilei、@huangyouhua、@xiedrsz 三人 Review 评论数分别为 107、91、65
163 位 Issue 贡献者持续供给问题输入，避免适配工作"闭门造车"
36 位答疑贡献者消化新人问题，降低社区维护成本

一个健康的开源项目不是"核心团队很强"，而是"每个环节都有足够多的人"。 1891 个 PR 背后是 71 个作者，而不是 7 个。

5.2 版本交付反过来验证了社区机制

oh-3.41.9-release 分支的提交记录里，能看到社区机制在具体工程中的落地：

同步上游修复：pick-upstream-pr-182886-textframe 分支把上游 PR 182886 的修复移植到 OHOS 版本线（@Kemin123）
代码门禁：新增 ArkTS 代码门禁检测脚本（@lx123546879），把质量检查前移到 CI
模板规范化：更新 PR 描述模板以适配 OHOS 仓库规范（@luqi_tan）
测试补齐：为 Impeller 文本 UT 补上 TypographerContextSkia::Make 迁移（@zhong_ning）

这些工作没有一个能直接"演示"，但它们是版本可持续交付的基础设施。社区的贡献披露机制把这类"不显眼但必要"的工作也纳入了公示范围，这是机制与工程之间的正向循环。

5.3 生态覆盖情况

版本能否用起来，还取决于三方库覆盖。社区维护的《OpenHarmony 平台 Flutter 三方库适配情况》当前记录：

分类	条目数
OpenHarmony 平台已适配三方库	262
OpenHarmony 平台适配中的三方库	110

（该文档持续更新，条目数会随适配进展变化，此处为本文撰写时的快照。）

三方库采用 TAG 做版本隔离，格式如 0.4.2-ohos-1.0.0-beta.1——表示原库版本 0.4.2 的鸿蒙化第一个版本，每个仓库都提供框架版本 TAG 对应表。

六、给开发者的实践建议

结合以上分析，给出几条可操作的建议。

6.1 选版本

新项目：直接用 3.41.10-ohos-1.0.1（当前最新稳定 tag）
存量项目：先确认所依赖三方库的适配版本，再决定是否升级。不要只看框架版本新不新
注意 tag 号差 1：3.41.9 的适配 tag 是 3.41.10-ohos-*

6.2 切换版本

务必不要使用 flutter upgrade。 社区文档明确警告：

Flutter OH 暂未适配 flutter upgrade 命令，直接执行该命令会因拉取官方 Channel 而破坏 OpenHarmony 适配环境并报错。

正确方式是 git clone / git checkout：

# 方式1：克隆指定分支
git clone -b oh-3.41.9-release https://atomgit.com/CPF-Flutter/flutter_flutter.git

# 方式2：切换到指定 Tag
git clone https://atomgit.com/CPF-Flutter/flutter_flutter.git
cd flutter_flutter
git checkout 3.41.10-ohos-1.0.1

6.3 构建

# 构建 Hap 不再需要 --local-engine
flutter build hap --release

若切换过 FLUTTER_STORAGE_BASE_URL，需删除 <flutter>/bin/cache 目录并在项目中执行 flutter clean 后重新运行。

6.4 参与共建

从社区机制看，参与路径不止一条：

路径	门槛	说明
提 Issue	最低	163 位贡献者验证了这条路的有效性；把使用中遇到的问题描述清楚即可
社区答疑	低	36 位贡献者，只需在他人 Issue 下评论 ≥ 3 条
提交 PR	中	71 位贡献者，从三方库适配或小修复入手
参与 Review	中	50 位贡献者，`@ohci1` 以纯 Review 达到卓越级
长期维护	高	123 人已达里程碑，传奇级需累计 300 次以上

报告的理念值得记住：

让每一份贡献都被看见，让每一个贡献者都被铭记。

七、小结

把 Q2 报告和 3.41.9 分支放在一起看，Flutter 鸿蒙化呈现出的图景是：

规模已经形成：单季度 1891 个 PR、2695 个有效 Issue、207 位活跃贡献者，278 人累计参与
机制已经成熟：四类贡献分类、四级里程碑、三通道达标、个人与公司解绑、数据可纠错
节奏已经稳定：适配周期从 7 个月收敛到 4 个月，多版本线并行维护
工程已经规范：上游修复同步、代码门禁、PR 模板、单元测试补齐，基础设施在持续完善
生态已经可用：262 个已适配三方库 + 110 个适配中，覆盖应用开发主流需求

对于正在评估 Flutter 鸿蒙化的团队，这份数据提供的判断依据是：这不是一个实验性项目，而是一个有稳定产出节奏、有明确治理规则、有可查贡献记录的生产级社区。

附：本文引用来源

CPF-Flutter 2026 年第二季度社区贡献报告
https://atomgit.com/CPF-Flutter/docs/blob/main/CPF-Flutter-Community/contributions/2026Q2_Quarterly_Contribution_Report.md
CPF-Flutter/flutter_flutter 仓库 oh-3.41.9-release 分支
https://atomgit.com/CPF-Flutter/flutter_flutter/tree/oh-3.41.9-release

相关补充材料：

三方库适配情况：https://atomgit.com/CPF-Flutter/docs/blob/main/ThirdpartyLibrarites.md
Flutter OH 升级指导：https://atomgit.com/CPF-Flutter/flutter_samples/blob/master/docs/ohos/version/flutter-oh-upgrade-guide.md
3.41 稳定性修复汇总：https://atomgit.com/CPF-Flutter/flutter_samples/tree/master/ohos/docs/13_stability_fixes/3.41稳定性修复汇总