Skip to content

Latest commit

 

History

History
156 lines (89 loc) · 9.3 KB

Flutter-HF.md

File metadata and controls

156 lines (89 loc) · 9.3 KB

Harmony 开始支持 Flutter ,聊聊 Harmony 和 Flutter 之间的因果

相信大家都已经听说过,明年的 Harmony Next 版本将正式剥离 AOSP 支持 ,基于这个话题我已经做过一期问题汇总 ,当时在现有 App 如何兼容 Harmony Next 问题上提到过:

华为内部也主导适配目前的主流跨平台方案,主动提供反向适配支持,估计后面就会有类似 Flutter for harmony 的社区支持。

没想到 HDC 大会才刚过去一个多月,就有网友提醒,针对 OpenHarmony 的 Flutter 版本已经开源:https://gitee.com/openharmony-sig/flutter_flutter ,这既让人惊喜又是「情理之中」,因为在众多框架里,Harmony 和 Flutter 之间的联系可以说是最密不可分

关系

为什么说 Harmony 和 Flutter 之间的联系很密切?因为不管是 ArkUI 还是 ArkUI-X ,它们的底层支持里都或多或少存在 Flutter 的身影

例如 ArkUI 的 framework arkui_ace_engine ,里面就可以看到很多熟悉的 Flutter 代码,不过这里面有点特殊在于,这些代码都是用 C++ 实现的,例如下图中的 Stack 的控件。

另外,除了 ArkUI 华为还开源了 ArkUI-XArkUI-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();
image-20230918165856863

其实这一点对于 Flutter 来说很重要,因为对于 Flutter 兼容 Harmony OS 的支持上, napi 是必不可少的一部分。

因为在 Flutter 里,Dart 除了可以直接和 C/C++ 调用之外,还支持和 Objective-C/Swift 与 Java/Kotlin 直接调用而不需要通过 Channel 。

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 flutterOP 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 平台本身的支持,而且在于这样一个「百废待兴」的社区环境下,完全靠社区支撑明显不现实,关键时刻还得是「自己动手」才能「丰衣足食」。