这次发布鸿蒙适配版的不是 CPF-Flutter，而是 AtomGit 上一群社区开发者：他们 fork 代码后自建 oh-3.47-dev 分支、自己同步上游、自己打 tag。两个主体并行适配同一上游，正是生态成熟的信号。本文讲清这条线的性质与配套要求。

这一次的发布者，不是 CPF-Flutter。

这是 AtomGit 平台社区开发者 在 fork 了 CPF-Flutter 代码之后，自主建立 3.47-dev 分支、同步上游 3.47.5 并完成适配的独立发布。

版本：Flutter 3.47.5-ohos-1.0.0 ｜ 分支：oh-3.47-dev ｜ Tag：3.47.5-ohos-1.0.0

一、先说清楚：这是谁发布的版本

这一点必须放在最前面，因为它决定了这个版本的性质。

核心差异是“适配运营主体”不同。

• CPF-Flutter 是 Flutter 鸿蒙适配的官方运营主体，由华为侧维护者主导，是产业链认可的适配基线；
• oh-flutter 是 AtomGit 平台上的社区开发者自发组织，通过 Fork 获取适配成果，然后独立维护自己的版本线。

这带来两个直接结果：

第一，它不是“另一个下载站”，而是独立的适配发布线。 oh-flutter 在自己的 fork 上建了 oh-3.47-dev 分支，自己同步上游、自己重建工件、自己发 tag。3.47.5-ohos-1.0.0 这个 tag 指向 39481acc，是 oh-flutter 仓库自己的提交。

第二，两条线可以互为参考、相互印证。 同一个上游 Flutter 版本，由两个主体各自适配，谁先跑通、谁的问题更少，社区一对比就看得出来。这种“多主体并行适配”本身就是生态健康的标志——它说明鸿蒙适配不再依赖单一团队，而是具备了可复制、可竞争、可持续的社区基础。

换句话说：CPF-Flutter 证明了这条路能走通；oh-flutter 在证明这条路谁都能走。

image-20260924065800711

二、3.47.5-ohos-1.0.0 带来了什么

版本配套

主要变更

上游同步 3.47.5：bin/internal/engine.version 由 06a2e2a1 升至 af7e796e，DEPS 的 dart_revision 由 1d1a730e 升至 b530c21f——Dart 3.13.3 → 3.13.4，kernel 仍为 138。

修复 flutter test 完全不可用（issue #3）。这个问题值得展开说，因为它是一个典型的“版本配套”故障：

1.0.4 上，宿主工件取自 OBS 的 engine.ohos 树（3.44.9 时代、Dart 3.12.2 / kernel 130），而分支 Dart 是 3.13.3（kernel 138）。两者的内核格式不兼容，因此任何工程的 flutter test 都必然报错：

Can’t load Kernel binary: Invalid kernel binary format version (expected 130, found 138)

修复方式是让 FlutterSdkOhos 改走标准引擎源（engine.version），使宿主工件与分支 Dart 自动配套。

一个有意为之的权衡：改走标准源之后，国内用户需要配置 FLUTTER_STORAGE_BASE_URL（例如 https://storage.flutter-io.cn）才能顺畅下载。这与上游行为一致，是**”配套正确性优先于开箱即用”**的取舍——宁可多一步配置，也不要一个内核版本对不上的工具链。

Dart 3.13.4 定制 SDK 重建：上游 3.13.3→3.13.4 只有 3 个提交、8 个文件（dart2js 体积估算、dartdev 修复、tools/VERSION），9 个 OHOS 补丁文件均未变动。本版本按 3.13.4 + OHOS 移植 + attachment/patches 两个补丁全量重建。

三档引擎全量重建：本批次 debug / profile / release 三档引擎均在当前 HEAD 全量重建（含 arm64_v8a_<mode>.har 内自带的那份 libflutter.so），不再出现”只重编 flutter.har、附件里混着旧档”的情况。7 项引擎工件 + 2 项 dart-sdk 共 9 行覆盖配置统一指向 3.47.5-ohos-1.0.0 同一 Release tag。

三、0day 适配：从 4 个月到 1 天

现在说这次发布最值得关注的一点。

先看 CPF-Flutter 公开的版本规划表，它给出的适配周期是：

而 oh-flutter 在自己的 README 里，把实际达成的节奏更新成了：

从 4 个月，压缩到 1 天。

这就是“0day 适配”的真实含义：上游发版，鸿蒙侧几乎同步可用。

而且注意一个细节：3.47.4 和 3.47.5 连续两个版本都做到了 1 天。这说明它不是一次运气好的冲刺，而是流程已经稳定下来了。

为什么能压缩到 1 天

这次能这么快，有一个非常具体的技术原因，值得记录下来：

engine/src 在 3.47.4 → 3.47.5 之间逐字节相同。

也就是说，上游这次只动了 Dart 运行时（3.13.3 → 3.13.4），引擎的 C++ 侧一行没改，embedded 层无需重新适配。

于是整个适配工作被简化成一条清晰的流水线：

上游发版

↓

对比 engine/src 是否变更  ← 这次：逐字节相同，跳过 C++ 适配

↓

Dart 版本变了 → 三类工件全量重建

（引擎 har / patched_sdk / 定制 Dart SDK）

↓

9 个工件统一指向同一 Release tag

↓

发 tag → 传附件 → 推分支（零 404 窗口）

关键洞察是：并非每次上游发版都需要“重新适配”。 只要准确识别出“这次到底变了什么”，就能把工作量精确缩小到必要范围内。这次 Dart 变了、C++ 没变，那就只重建、不重适配——1 天就是这么省出来的。

这也解释了为什么 3.47.4 和 3.47.5 都能做到 1 天：当版本基线的架构已经对齐，后续小版本跟进就退化成了一次“工件重建 + 校验”的机械流程。

四、但 1 天 ≠ 稳定，这需要大家一起验证

上面讲了速度，接下来必须讲一个更重要的事：快，不等于稳。

一个版本“构建通过”和“在真机上跑得好”，中间隔着的距离，比很多人想象的要大。这也是为什么这次发布要分两层来看：

第一层：构建与静态校验

构建层面的校验，oh-flutter 已经做得很细——符号表、ABI、架构逐项都留了可复核的口径：

• 字体端口三档全在位：OH_Drawing_ 未定义符号 8、FT_ 符号 debug 185 / profile 103 / release 103、SkFontMgr_New_OHOS 1、fontconfig 串 5
• 三档 9 个 har 的 package/oh-package.json5 版本戳统一为 1.0.0-e034e7a293（引擎树 HEAD）
• FFI ABI 校验通过（debug/release 两档 platform kernel 均 arm64=23/64-bit）
• 宿主 gen_snapshot 三档均为 Mach-O 64-bit arm64

但这些都是静态校验。静态校验能保证“工件是自洽的”，却无法保证“在你那台设备上显示正常”——字体端口尤其如此，它丢了编译期不报错。

第二层：真机验证（已完成）

好消息是，这一层也已经跑通了。本版本已在真机上完成设备侧验证：

实际跑通的链路：

• 构建 → 用本版本 SDK 构建成功，产出 entry-default-signed.hap
• 安装 → hdc install 成功
• 启动 → aa start 成功，进程正常存活、无崩溃
• 渲染 → 界面正常渲染，hilog 中无GPU does not support the format(0)、无SurfaceFrame::Submit failed
• 文字与图标 → 字体端口表现正常，无缺字、无图标错位

GPU does not support the format(0) 这个错误值得单独说一句：它正是此前导致 flutter create 默认应用在鸿蒙真机上黑屏的根因（offscreen native window 缺 SET_USAGE / SET_FORMAT）。这次真机上没有再出现，说明该修复在 3.47.5 上依然生效。

但一台设备 ≠ 所有设备

真机验证完成，不等于万事大吉。必须说清楚两点边界：

1. 只覆盖了 debug 档。profile / release 两档已通过构建期的符号与 ABI 校验，但设备侧渲染仍建议在实际应用发布时再确认一遍。
2. 只覆盖了一台机型。ALN-AL00 跑通了，不代表其他芯片、其他 ROM 版本、其他屏幕规格的设备都跑通。鸿蒙设备矩阵远比一台手机复杂——不同 SoC 的 GPU 驱动差异、不同 ROM 的渲染合成路径差异，都可能让某个机型出现别人没遇到的问题。

这正是社区适配与官方适配最大的不同：官方团队有完整的设备矩阵，社区没有。

社区有的是——你手上的设备。

所以这次的请求依然具体，只是从“从零开始验证”变成了“帮我们把覆盖范围扩开”：

• 你有一台鸿蒙设备 → 拉下 3.47.5-ohos-1.0.0，跑一个 flutter create 默认应用，看看文字和图标渲染是否正常
• 你发现显示异常 → 提一个 Issue，附上设备型号、ROM 版本、截图。这比任何静态校验都有价值
• 你跑通了 → 也请说一声。**”我这边没问题”同样是宝贵的信息**，它帮生态确认一台机型的可用性
• 你用的是不同机型 → 你的验证就是在帮生态扩展覆盖范围

一次真机验证 = 一个机型的可用性确认。 278 位贡献者能把 CPF-Flutter 的适配线撑起来，靠的就是这种“每人测一台”的累积。

五、共建：这个版本属于所有参与者

oh-flutter 这个组织是 2025 年 8 月 27 日创建的，到这次发布不过一年时间。它做的事情，用一句话概括就是：

把 CPF-Flutter 的适配成果，变成一条由社区自主维护、可持续迭代的版本线。

这件事的意义，不在于“多了一个下载源”，而在于验证了适配能力的可复制性：

• 如果只有 CPF-Flutter 能适配 → 适配能力是稀缺的，生态受制于单点
• 如果社区 fork 之后也能独立适配、独立发版 → 适配能力已经下沉为公共知识

后者才是健康的生态。因为它意味着：即便某天某个团队停更，社区里仍然有其他人能接上。

而这条线要继续走下去，需要的正是更多人的参与：

每一种参与都被看见。 这次发布的发布说明里，连“验证范围仅覆盖 debug 档、仅覆盖一台机型”这样的边界都写进了正式文档——一个愿意把不足摊开讲的社区，值得信任。

六、如何获取与验证

# 克隆 oh-flutter 的适配仓库

git clone -b oh-3.47-dev https://atomgit.com/oh-flutter/flutter_flutter.git

# 或直接切到发布 tag

cd flutter_flutter

git checkout 3.47.5-ohos-1.0.0

注意：Flutter OH 暂未适配 flutter upgrade 命令，直接执行会因拉取官方 Channel 而破坏适配环境。请使用 git clone / git checkout 切换版本。

验证后欢迎反馈：

• 仓库：https://atomgit.com/oh-flutter/flutter_flutter
• 发布说明：https://atomgit.com/oh-flutter/flutter_flutter/blob/oh-3.47-dev/release-notes/Flutter%203.47.5-ohos%201.0.0%20ReleaseNote.md
• 提 Issue / 提 PR / 测试反馈，都是对社区最好的支持

七、小结

把这次发布的关键信息收拢成几句话：

1. 发布主体：AtomGit 平台社区开发者（oh-flutter），Fork 自 CPF-Flutter，独立维护 oh-3.47-dev 分支
2. 核心差异：适配运营主体不同——这是社区自主适配线，而非官方适配线
3. 版本内容：同步上游 3.47.5，Dart 3.13.3 → 3.13.4，修复 flutter test 不可用，9 个工件全量重建
4. 0day 速度：适配周期从 4 个月压缩到 1 天，且 3.47.4 / 3.47.5 连续两版达成
5. 压缩原因：engine/src 逐字节相同，上游只改 Dart → 只需重建，无需重适配
6. 验证状态：已在真机（ALN-AL00 / OpenHarmony-7.0.0.105 / API 26 / arm64-v8a）完成 debug 档验证，渲染正常、无黑屏报错；profile / release 档待实际发布时确认
7. 下一步：需要广大开发者一起体验、一起共建，把机型覆盖范围扩开

0day 适配不是靠某个人做到的，而是靠一套流程、一群人的接力。

这一次，接力棒在社区手里。

也欢迎添加我的联系方式，咱们交个朋友！未来我也会持续分享各类前沿技术干货。

附：参考资料

• Flutter 3.47.5-ohos-1.0.0 Release Note[1]
• oh-flutter/flutter_flutter 仓库[2]
• CPF-Flutter/flutter_flutter 上游适配线[3]
• Flutter OH 环境搭建指导[4]
• Flutter OH 应用构建指导[5]

参考资料

[1]Flutter 3.47.5-ohos-1.0.0 Release Note: https://atomgit.com/oh-flutter/flutter_flutter/blob/oh-3.47-dev/release-notes/Flutter%203.47.5-ohos%201.0.0%20ReleaseNote.md

[2]oh-flutter/flutter_flutter 仓库: https://atomgit.com/oh-flutter/flutter_flutter

[3]CPF-Flutter/flutter_flutter 上游适配线: https://atomgit.com/CPF-Flutter/flutter_flutter

[4]Flutter OH 环境搭建指导: https://atomgit.com/cpf-flutter/flutter_samples/blob/master/ohos/docs/03_environment/OpenHarmony-flutter%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA%E6%8C%87%E5%AF%BC.md

[5]Flutter OH 应用构建指导: https://atomgit.com/cpf-flutter/flutter_samples/blob/master/ohos/docs/04_development/OpenHarmony-flutter%E5%BA%94%E7%94%A8%E6%9E%84%E5%BB%BA%E6%8C%87%E5%AF%BC.md