让 Flutter 在鸿蒙系统上跑起来_鸿蒙 canvas surfaceprovider

Flutter 框架注册 VSync 回调之后，通过 C++ 侧的 VsyncWaiter 类等待 VSync 信号，后者通过 JNI 等一系列调用，最终 Java 侧的 VsyncWaiter 类调用 Android SDK 的 Choreographer.postFrameCallback 方法，再通过 JNI 一层层传回 Flutter 引擎消费掉此回调。Java 侧的 VsyncWaiter 核心代码如下：

@Override
public void asyncWaitForVsync(long cookie) {
  Choreographer.getInstance()
      .postFrameCallback(
        new Choreographer.FrameCallback() {
          @Override
          public void doFrame(long frameTimeNanos) {
            float fps = windowManager.getDefaultDisplay().getRefreshRate();
            long refreshPeriodNanos = (long) (1000000000.0 / fps);
            FlutterJNI.nativeOnVsync(
              frameTimeNanos, frameTimeNanos + refreshPeriodNanos, cookie);
          }
        });
}

在整个流程中，除了来自 Android SDK 的 Choreographer 以外，大多数逻辑几乎都由 C++ 和 Java 的基础 SDK 实现，可以直接在鸿蒙上复用，问题是鸿蒙目前的 API 文档中尚没有开放类似 Choreographer 的能力。所以现阶段我们可以借用鸿蒙提供的类似 iOS Grand Central Dispatch 的线程 API，模拟出 VSync 的信号触发与回调：

@Override
public void asyncWaitForVsync(long cookie) {
  // 模拟每秒 60 帧的屏幕刷新间隔：向主线程发送一个异步任务, 16ms 后调用
  applicationContext.getUITaskDispatcher().delayDispatch(() -> {
    float fps = 60; // 设备刷新帧率，HarmonyOS 未暴露获取帧率 API，先写死 60 帧
    long refreshPeriodNanos = (long) (1000000000.0 / fps);
    long frameTimeNanos = System.nanoTime();
    FlutterJNI.nativeOnVsync(frameTimeNanos, frameTimeNanos + refreshPeriodNanos, cookie);
  }, 16);
};

渲染窗口的构建及传递

在这一部分，我们需要在鸿蒙系统上构建平台容器，为 Flutter 引擎的图形渲染提供用于上屏的窗口对象。同样，我们参考 Flutter for Android 的实现，看一下 Android 系统是怎么做的：

Flutter 在 Android 上支持 Vulkan 和 OpenGL 两种渲染引擎，篇幅原因我们只关注 OpenGL。抛开复杂的注册及调用细节，本质上整个流程主要做了三件事：

1. 创建了一个视图对象，提供可用于直接绘制的 Surface，将它通过 JNI 传递给原生侧；

2. 在原生侧获取 Surface 关联的本地窗口对象，并交给 Flutter 的平台容器；

3. 将本地窗口对象转换为 OpenGL ES 可识别的绘图表面（EGLSurface），用于 Flutter 引擎的渲染上屏。

接下来我们用鸿蒙提供的平台能力来实现这三点。

a. 可用于直接绘制的视图对象

鸿蒙系统的 UI 框架提供了很多常用视图组件（Component），比如按钮、文字、图片、列表等，但我们需要抛开这些上层组件，获得直接绘制的能力。借助官方媒体播放器开发指导文档，可以发现鸿蒙提供了 SurfaceProvider 类，它管理的 Surface 对象可以用于视频解码后的展示。而 Flutter 渲染与视频上屏从原理上是类似的，因此我们可以借用 SurfaceProvider 实现 Surface 的管理和创建：

// 创建一个用于管理 Surface 的容器组件
SurfaceProvider surfaceProvider = new SurfaceProvider(context);
// 注册视图创建回调
surfaceProvider.getSurfaceOps().get().addCallback(surfaceCallback);
 
// ... 在 surfaceCallback 中
@Override
public void surfaceCreated(SurfaceOps surfaceOps) {
  Surface surface = surfaceOps.getSurface();
  // ...将 surface 通过 JNI 交给 Native 侧
  FlutterJNI.onSurfaceCreated(surface);
}

b. 与 Surface 关联的本地窗口对象

鸿蒙目前开放的 Native API 并不多，在官方文档中，我们可以比较容易地找到 Native_layer API。根据文档的说明，Native API 中的 NativeLayer 对象刚好对应了 Java 侧的 Surface 类，借助 GetNativeLayer 方法，我们实现了两者之间的转化：

// platform_view_android_jni_impl.cc
static void SurfaceCreated(JNIEnv* env, jobject jcaller, jlong shell_holder, jobject jsurface) {
  fml::jni::ScopedJavaLocalFrame scoped_local_reference_frame(env);
  // 通过鸿蒙 Native API 获取本地窗口对象 NativeLayer
  auto window = fml::MakeRefCounted<AndroidNativeWindow>(
      GetNativeLayer(env, jsurface));
  ANDROID_SHELL_HOLDER->GetPlatformView()->NotifyCreated(std::move(window));
}

c. 与本地窗口对象关联的 EGLSurface

在 Android 的 AOSP 实现中，EGLSurface 可通过 EGL 库的 eglCreateWindowSurface 方法从本地窗口对象 ANativeWindow 创建而来。对于鸿蒙而言，虽然我们没有从公开文档找到类似的说明，但是鸿蒙标准库默认支持了 OpenGL ES，而且鸿蒙 SDK 中也附带了 EGL 相关的库及头文件，我们有理由相信在鸿蒙系统上，EGLSurface 也可以通过此方法从前一步生成的 NativeLayer 转化而来，在之后的验证中我们也确认了这一点：

// window->handle() 即为之前得到的 NativeLayer
EGLSurface surface = eglCreateWindowSurface(
      display, config_, reinterpret_cast<EGLNativeWindowType>(window->handle()),
      attribs);
//...交给 Flutter 渲染管线

2. 交互能力实现

交互能力是支撑 Flutter 应用能够正常运行的另一个基本要求。在 Flutter 中，交互包含了各种触摸事件、鼠标事件、键盘录入事件的传递及消费。以触摸事件为例，Flutter 事件传递的整个流程如下图所示：

iOS/Android 的原生容器通过触摸事件的回调 API 接收到事件之后，会将其打包传递至引擎层，后者将事件传发给 Flutter 框架层，并完成事件的消费、分发和逻辑处理。同样，整个流程的大部分工作已经由 Flutter 统一，我们要做的仅仅是在原生容器上监听用户的输入，并封装成指定格式交给引擎层而已。

在鸿蒙系统上，我们可以借助平台提供的多模输入 API，实现多种类型事件的监听：

flutterComponent.setTouchEventListener(touchEventListener); // 触摸及鼠标事件
flutterComponent.setKeyEventListener(keyEventListener); // 键盘录入事件
flutterComponent.setSpeechEventListener(speechEventListener); // 语音录入事件

对于事件的封装处理，可以复用 Android 已有的逻辑，只需要关注鸿蒙与 Android 在事件处理上的对应关系即可，比如触摸事件的部分对应关系：

3. 其他必要的平台能力

为了保证 Flutter 应用能够正常运行，除了最基本的渲染和交互外，我们的嵌入层还要提供资源管理、事件循环、生命周期同步等平台能力。对于这些能力 Flutter 大多都在嵌入层的公共部分有抽象类声明，只需要使用鸿蒙 API 重新实现一遍即可。

比如资源管理，引擎提供了 AssetResolver 声明，我们可以使用鸿蒙 Rawfile API 来实现：

class HAPAssetMapping : public fml::Mapping {
 public:
  HAPAssetMapping(RawFile* asset) : asset_(asset) {}
  ~HAPAssetMapping() override { CloseRawFile(asset_); }
 
  size_t GetSize() const override { return GetRawFileSize(asset_); }
 
  const uint8_t* GetMapping() const override {
    return reinterpret_cast<const uint8_t*>(GetRawFileBuffer(asset_));
  }
 
 private:
  RawFile* const asset_;
 
  FML_DISALLOW_COPY_AND_ASSIGN(HAPAssetMapping);
};

对于事件循环，引擎提供了 MessageLoopImpl 抽象类，我们可以使用鸿蒙 Native_EventHandler API 实现：

// runner_ 为鸿蒙 EventRunnerNativeImplement 的实例
void MessageLoopHarmony::Run() {
  FML_DCHECK(runner_ == GetEventRunnerNativeObjForThread());
  int result = ::EventRunnerRun(runner_);
  FML_DCHECK(result == 0);
}
 
void MessageLoopHarmony::Terminate() {
  int result = ::EventRunnerStop(runner_);
  FML_DCHECK(result == 0);
}

对于生命周期的同步，鸿蒙的 Page Ability 提供了完整的生命周期回调（如下图所示），我们只需要在对应的时机将状态上报给引擎即可。

当以上这些能力都准备好之后，我们就可以成功把 Flutter 应用跑起来了。以下是通过 DevEco Studio 运行官方 Flutter Gallery 应用的截图，截图中 Flutter 引擎已经使用鸿蒙系统的平台能力进行了重写：

借由鸿蒙的多设备支持能力，此应用甚至可在 TV、车机、手表、平板等设备上运行：

总结和展望

通过上述的构建和适配工作，我们以极小的开发成本实现了 Flutter 在鸿蒙系统上的移植，基于 Flutter 开发的上层业务几乎不做任何修改就可以在鸿蒙系统上原生运行，为迎接鸿蒙系统后续的大规模推广也提前做好了技术储备。

当然，故事到这里并没有结束。在最基本的运行和交互能力之上，我们更需要关注 Flutter 与鸿蒙自身生态的结合：如何优雅地适配鸿蒙的分布式技术？如何用 Flutter 实现设备之间的快速连接、资源共享？现有的众多 Flutter 插件如何应用到鸿蒙系统上？未来 MTFlutter 团队将在这些方面做更深入的探索，因为解决好这些问题，才是真正能让应用覆盖用户生活的全场景的关键。

参考文献

• https://developer.huawei.com/consumer/cn/events/hdc2020/

• https://developer.harmonyos.com/cn/documentation

• https://flutter.dev/docs/resources/architectural-overview

• https://github.com/flutter/flutter/wiki/Custom-Flutter-Engine-Embedders

作者简介

杨超，2016 年加入美团外卖技术团队，目前主要负责 MTFlutter 相关的基础建设工作。

----------  END  ----------

招聘信息

美团外卖长期招聘Android、iOS、FE 高级/资深工程师和技术专家。欢迎感兴趣的同学加入我们，可投递简历至：tech@meituan.com（邮件主题请注明：外卖前端）