相信我们都现已听说过，明年的 Harmony Next 版别将正式剥离 AOSP 支撑 ，基于这个话题我现已做过一期问题汇总 ，其时在现有 App 怎么兼容 Harmony Next 问题上提到过：

华为内部也主导适配现在的主流跨渠道计划，主动供给反向适配支撑，估计后边就会有相似 Flutter for harmony 的社区支撑。

没想到 HDC 大会才刚过去一个多月，就有网友提醒，针对 OpenHarmony 的 Flutter 版别现已开源：gitee.com/openharmony… ，这既让人惊喜又是「情理之中」，由于在很多结构里，Harmony 和 Flutter 之间的联系能够说是最密不可分。

关系

为什么说 Harmony 和 Flutter 之间的联系很密切？由于不管是 ArkUI 还是 ArkUI-X ，它们的底层支撑里都或多或少存在 Flutter 的身影。

例如 ArkUI 的 framework arkui_ace_engine ，里面就能够看到很多熟悉的 Flutter 代码，不过这儿面有点特别在于，这些代码都是用 C++ 完成的，例如下图中的 Stack 的控件。

别的，除了 ArkUI 华为还开源了 ArkUI-X ，ArkUI-X 扩展了 ArkUI 结构让其支撑跨渠道开发，而这部分跨渠道的底层逻辑，同样来自 Flutter 和 Skia 的支撑。

与 Flutter 不同的是，OpenHarmony 上层开发用的是 ArkTS 和 ArkUI，调用走的是 NAPI（Native API），NAPI 是一套基于 Node.js 规范开发的原生模块扩展开发结构。

NAPI 能够完成 JS 与 C/C++ 代码之间彼此拜访，也便是 ArkTS 能够直接和 C/C++ 无缝调用，相似 dart ffi 作用。

举个例子，例如经过 ArkUI-X 里的 getDefaultDisplaySync 获取设备屏幕信息， 关于 Android 系统而言， ets 下的代码经过 napi 会调用到 C++ 层的 DisplayInfo 目标，从而再经过 jni 调用 java 下的 DisplayInfo 目标。

 var dsp = display.getDefaultDisplaySync();

其实这一点关于 Flutter 来说很重要，由于关于 Flutter 兼容 Harmony OS 的支撑上， napi 是必不可少的一部分。

由于在 Flutter 里，Dart 除了能够直接和 C/C++ 调用之外，还支撑和 Objective-C/Swift 与 Java/Kotlin 直接调用而不需求经过 Channel 。

• 其间 Objective-C / Swift interop 是经过 package:ffigen :

ffigen:
  name: AVFAudio
  description: Bindings for AVFAudio.
  language: objc
  output: 'avf_audio_bindings.dart'
  headers:
    entry-points:
      - '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/AVFAudio.framework/Headers/AVAudioPlayer.h'

• Java / kotlin 是经过 jnigen 支撑调用，不过现在还属于 experimental 的状态：

output:
  c:
    library_name: example
    path: src/example/
  dart:
    path: lib/example.dart
    structure: single_file
source_path:
  - 'java/'
classes:
  - 'dev.dart.Example'

所以，后续在 Harmony OS 上，就会有多一个相似 napi gen 支撑的需求。

兼容

本次开源支撑 OpenHarmony 的 flutter 社区版别来自 openharmony-sig ，该安排首要用于孵化 OpenHarmony 相关开源生态项目。

别的，在 openharmony 安排下 sig_crossplatformui 也有 Taro 主导的一些跨渠道支撑计划。

OpenHarmony 的 flutter （简称 OP Flutter ）版别现在所用的分支应该是 3.7 版别，由于是刚开源，现在 flutter tools 指令仅支撑 linux 下使用 ，可是相信后续跟上节奏应该不成问题。

以下分析基于 2023-09-18 的部分内容，后续肯定会有新的改变，这儿首要供给一些思路和方向。

SIG 社区适配的首要有 OP flutter 和 OP flutter engine 两个项目，依据现在的提交，OP flutter 现在首要是增加了 flutter tools 关于构建 hap 的支撑，例如：

• 增加环境检测

  

• 完成 tools 下的自定义的 build_hap.dart ，还有识别鸿蒙设备的支撑等。

  

  

• 供给 create 时对应的 ets 模版

  

而关于运转支撑，首要是经过 OP flutter engine 来完成，首要代码新增在对应的 ohos/ 目录下：

从 OP flutter engine 变更的内容上看，首要是从原有 shell/platform/android 下的代码拷贝一份进行调整，例如 GL Context 代码部分现在简直太大差异。

别的，我们比较关心的应该便是 Impeller 在 OP 上是否支撑，现在看来 OP Flutter Engine 里关于 Impeller 有一定预设，可是并没有启用，由于 Flutter 官方现在关于 Android 上的 Impeller 也没有正式发布，所以这个现在看来也不需求着急。

关于字体部分， 现在看来 OP 上 Flutter 默许会使用 sans-serif ，这个应该是和 鸿蒙上的 HarmonyOS Sans 保持一致。

关于刷新率部分，现在暂时能够看到是默许写死了 60hz ，后续应该能够经过 napi 等支撑获取实际刷新率，支撑动态刷新率这个我们不必忧虑。

别的，由于版别问题，现在 OP Flutter Engine 里还保留了 partial repaint 操作，可是其实 Flutter 官方现已在 Android 上 Disable 了 partial repaint ，由于 Android 上的部分重绘存在太多问题，所以该功能被直接屏蔽。

Flutter 官方之后计划与 Vulkan Impeller 独自适配后再从头开放 partial repaint，这对 OP Flutter Engine 来说或许也是一个前史包袱，猜测 OP Flutter 后续会跟从 Impeller 同步。

当然，由于不同渠道，所以 OP Flutter Engine 也有自己需求独自完成的逻辑，例如数据的类型转化处理，在 Android 上对应的是 shell/platform/android/platform_view_android_jni_impl.cc ， 而在 OP 上对应的便是 shell/platform/ohos/napi/platform_view_ohos_napi.cpp :

最终，Flutter 适配不只是 embedding 和 tools 的适配，还有新的 channel 和 plugin 的支撑，现在看来 SIG 也在努力与这点，一些常用或者知名的 plugin 社区都会逐渐增加支撑，这看起来是一个苦力活，可是关于 Harmony 脱离 AOSP 构建自己的生态来说，无疑会是前史性的一步。

最终

经过本篇，相信你应该能简略了解到 Flutter 和 Harmony 之间的「因果关系」，关于 Flutter 开发来说，Harmony Next 会是一个相对较好的新渠道。

当然，这不代表这你能够不学 ArkTS 和 ArkUI ，由于不管是打包构建或者 napi 都离不开 Harmony 渠道本身的支撑，并且在于这样一个「百废待兴」的社区环境下，完全靠社区支撑显着不现实，关键时刻还得是「自己着手」才能「锦衣玉食」。