Harmony 开始支持 Flutter ，聊聊 Harmony 和 Flutter 之间的因果-编程知识

原创作者：恋猫de小郭

相信大家都已经听说过，明年的 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: AVFAudiodescription: Bindings for AVFAudio.language: objcoutput: '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: examplepath: src/example/dart:path: lib/example.dartstructure: 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 构建自己的生态来说，无疑会是历史性的一步。