前言

鴻蒙系統(tǒng)（HarmonyOS）是華為推出的一款面向未來、面向全場景的分布式操作系統(tǒng)。在傳統(tǒng)單設(shè)備系統(tǒng)能力的基礎(chǔ)上，鴻蒙提出了基于同一套系統(tǒng)能力、適配多種終端形態(tài)的分布式理念。自 2020 年 9 月 HarmonyOS 2.0 發(fā)布以來，華為加快了鴻蒙系統(tǒng)大規(guī)模落地的步伐，預(yù)計 2021 年底，鴻蒙系統(tǒng)會覆蓋包括手機、平板、智能穿戴、智慧屏、車機在內(nèi)數(shù)億臺終端設(shè)備。對移動應(yīng)用而言， 新的系統(tǒng)理念、新的交互形式，也意味著新的機遇 。如果能夠利用好鴻蒙的開發(fā)生態(tài)及其特性能力，可以讓應(yīng)用覆蓋更多的交互場景和設(shè)備類型，從而帶來新的增長點。

與面臨的機遇相比，適配鴻蒙系統(tǒng)帶來的挑戰(zhàn)同樣巨大。當(dāng)前手機端，盡管鴻蒙系統(tǒng)仍然支持安卓 APK 安裝及運行，但長期來看，華為勢必會拋棄 AOSP，逐步發(fā)展出自己的生態(tài)，這意味著現(xiàn)有安卓應(yīng)用在鴻蒙設(shè)備上將會逐漸變成“二等公民”。然而，如果在 iOS 及 Android 之外再重新開發(fā)和維護一套鴻蒙應(yīng)用，在如今業(yè)界越來越注重開發(fā)迭代效率的環(huán)境下，所帶來的開發(fā)成本也是難以估量的。因此，通過打造一套合適的跨端框架，以相對低的成本移植應(yīng)用到鴻蒙平臺，并利用好該系統(tǒng)的特性能力，就成為了一個非常重要的選項。

在現(xiàn)有的眾多跨端框架當(dāng)中，F(xiàn)lutter 以其自渲染能力帶來的多端高度一致性，在新系統(tǒng)的適配上有著突出的優(yōu)勢。雖然Flutter 官方 并沒有適配鴻蒙的計劃 ，但經(jīng)過一段時間的探索和實踐，美團外賣 MTFlutter 團隊成功實現(xiàn)了 Flutter 對于鴻蒙系統(tǒng)的原生支持。

這里也要提前說明一下，因為鴻蒙系統(tǒng)目前還處于Beta版本，所以這套適配方案還沒有在實際業(yè)務(wù)中上線，屬于技術(shù)層面比較前期的探索。接下來本文會通過原理和部分實現(xiàn)細節(jié)的介紹，分享我們在移植和開發(fā)過程中的一些經(jīng)驗。希望能對大家有所啟發(fā)或者幫助。

背景知識和基礎(chǔ)概念介紹

在適配開始之前，我們要明確好先做哪些事情。先來回顧一下 Flutter 的三層結(jié)構(gòu)：

在 Flutter 的架構(gòu)設(shè)計中，最上層為 框架層 ，使用 Dart 語言開發(fā)，面向 Flutter 業(yè)務(wù)的開發(fā)者；中間層為 引擎層 ，使用 C/C++ 開發(fā)，實現(xiàn)了 Flutter 的渲染管線和 Dart 運行時等基礎(chǔ)能力；最下層為 嵌入層 ，負責(zé)與平臺相關(guān)的能力實現(xiàn)。顯然我們要做的是將嵌入層移植到鴻蒙上，確切地說，我們要 通過鴻蒙原生提供的平臺能力，重新實現(xiàn)一遍 Flutter 嵌入層 。

對于 Flutter 嵌入層的適配，F(xiàn)lutter 官方有一份不算詳細的 指南 ，實際操作起來成本很高。由于鴻蒙的業(yè)務(wù)開發(fā)語言仍然可用 Java，在很多基礎(chǔ)概念上與 Android 也有相似之處（如下表所示），我們可以從 Android 的實現(xiàn)入手，完成對鴻蒙的移植。

Flutter 在鴻蒙上的適配

如前文所述，要完成 Flutter 在新系統(tǒng)上的移植，我們需要完整實現(xiàn) Flutter 嵌入層要求的所有子模塊，而從能力支持角度， 渲染 、 交互 以及 其他必要的原生平臺能力 是保證 Flutter 應(yīng)用能夠運行起來的最基本的要素，需要優(yōu)先支持。接下來會依次進行介紹。

1. 渲染流程打通

我們再來回顧一下 Flutter 的圖像渲染流程。如圖所示，設(shè)備發(fā)起 垂直同步 （VSync）信號之后，先經(jīng)過 UI 線程的渲染管線（Animate/Build/Layout/Paint），再經(jīng)過 Raster 線程的組合和柵格化，最終通過 OpenGL 或 Vulkan 將圖像 上屏 。這個流程的大部分工作都由框架層和引擎層完成，對于鴻蒙的適配，我們主要關(guān)注的是與設(shè)備自身能力相關(guān)的問題，即：

(1) 如何監(jiān)聽設(shè)備的 VSync 信號并通知 Flutter 引擎？ (2) OpenGL/Vulkan 用于上屏的窗口對象從何而來？

VSync 信號的監(jiān)聽及傳遞

在 Flutter 引擎的 Android 實現(xiàn)中，設(shè)備的 VSync 信號通過 Choreographer 觸發(fā)，它產(chǎn)生及消費流程如下圖所示：

Flutter 框架注冊 VSync 回調(diào)之后，通過 C++ 側(cè)的 VsyncWaiter 類等待 VSync 信號，后者通過 JNI 等一系列調(diào)用，最終 Java 側(cè)的 VsyncWaiter 類調(diào)用 Android SDK 的 Choreographer.postFrameCallback 方法，再通過 JNI 一層層傳回 Flutter 引擎消費掉此回調(diào)。Java 側(cè)的 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 以外，大多數(shù)邏輯幾乎都由 C++ 和 Java 的基礎(chǔ) SDK 實現(xiàn)，可以直接在鴻蒙上復(fù)用，問題是鴻蒙目前的 API 文檔中尚沒有開放類似 Choreographer 的能力。所以現(xiàn)階段我們可以借用鴻蒙提供的類似 iOS Grand Central Dispatch 的線程 API，模擬出 VSync 的信號觸發(fā)與回調(diào)：

@Override 
public void asyncWaitForVsync(long cookie) { 
  // 模擬每秒 60 幀的屏幕刷新間隔：向主線程發(fā)送一個異步任務(wù), 16ms 后調(diào)用 
  applicationContext.getUITaskDispatcher().delayDispatch(() -> { 
    float fps = 60; // 設(shè)備刷新幀率，HarmonyOS 未暴露獲取幀率 API，先寫死 60 幀 
    long refreshPeriodNanos = (long) (1000000000.0 / fps); 
    long frameTimeNanos = System.nanoTime(); 
    FlutterJNI.nativeOnVsync(frameTimeNanos, frameTimeNanos + refreshPeriodNanos, cookie); 
  }, 16); 
}; 

渲染窗口的構(gòu)建及傳遞

在這一部分，我們需要在鴻蒙系統(tǒng)上構(gòu)建平臺容器，為 Flutter 引擎的圖形渲染提供用于上屏的窗口對象。同樣，我們參考 Flutter for Android 的實現(xiàn)，看一下 Android 系統(tǒng)是怎么做的：

Flutter 在 Android 上支持 Vulkan 和 OpenGL 兩種渲染引擎，篇幅原因我們只關(guān)注 OpenGL。拋開復(fù)雜的注冊及調(diào)用細節(jié)，本質(zhì)上整個流程主要做了三件事：

1. 創(chuàng)建了一個 視圖對象 ，提供可用于直接繪制的 Surface，將它通過 JNI 傳遞給原生側(cè)；
2. 在原生側(cè)獲取 Surface 關(guān)聯(lián)的 本地窗口對象 ，并交給 Flutter 的平臺容器；
3. 將本地窗口對象轉(zhuǎn)換為 OpenGL ES 可識別的 繪圖表面（EGLSurface） ，用于 Flutter 引擎的渲染上屏。

接下來我們用鴻蒙提供的平臺能力實現(xiàn)這三點。

a. 可用于直接繪制的視圖對象

鴻蒙系統(tǒng)的 UI 框架 提供了很多常用視圖組件（Component） ，比如按鈕、文字、圖片、列表等，但我們需要拋開這些上層組件，獲得直接繪制的能力。借助官方 媒體播放器開發(fā)指導(dǎo) 文檔，可以發(fā)現(xiàn)鴻蒙提供了 SurfaceProvider 類，它管理的 Surface 對象可以用于視頻解碼后的展示。而 Flutter 渲染與視頻上屏從原理上是類似的，因此我們可以借用 SurfaceProvider 實現(xiàn) Surface 的管理和創(chuàng)建：

// 創(chuàng)建一個用于管理 Surface 的容器組件 
SurfaceProvider surfaceProvider = new SurfaceProvider(context); 
// 注冊視圖創(chuàng)建回調(diào) 
surfaceProvider.getSurfaceOps().get().addCallback(surfaceCallback); 
 
// ... 在 surfaceCallback 中 
@Override 
public void surfaceCreated(SurfaceOps surfaceOps) { 
  Surface surface = surfaceOps.getSurface(); 
  // ...將 surface 通過 JNI 交給 Native 側(cè) 
  FlutterJNI.onSurfaceCreated(surface); 
} 

b. 與 Surface 關(guān)聯(lián)的本地窗口對象

鴻蒙目前開放的 Native API 并不多，在官方文檔中我們可以比較容易地找到 Native_layer API 。根據(jù)文檔的說明，Native API 中的 NativeLayer 對象剛好對應(yīng)了 Java 側(cè)的 Surface 類，借助 GetNativeLayer 方法，我們實現(xiàn)了兩者之間的轉(zhuǎn)化：

// 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. 與本地窗口對象關(guān)聯(lián)的 EGLSurface

在 Android 的 AOSP 實現(xiàn) 中，EGLSurface 可通過 EGL 庫的 eglCreateWindowSurface 方法從本地窗口對象 ANativeWindow 創(chuàng)建而來。對于鴻蒙而言，雖然我們沒有從公開文檔找到類似的說明，但是 鴻蒙標準庫 默認支持了 OpenGL ES，而且鴻蒙 SDK 中也附帶了 EGL 相關(guān)的庫及頭文件，我們有理由相信在鴻蒙系統(tǒng)上，EGLSurface 也可以通過此方法從前一步生成的 NativeLayer 轉(zhuǎn)化而來，在之后的驗證中我們也確認了這一點：

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

2. 交互能力實現(xiàn)

交互能力是支撐 Flutter 應(yīng)用能夠正常運行的另一個基本要求。在 Flutter 中，交互包含了各種觸摸事件、鼠標事件、鍵盤錄入事件的傳遞及消費。以觸摸事件為例，F(xiàn)lutter 事件傳遞的整個流程如下圖所示：

iOS/Android 的原生容器通過觸摸事件的回調(diào) API 接收到事件之后，會將其打包傳遞至引擎層，后者將事件傳發(fā)給 Flutter 框架層，并完成事件的消費、分發(fā)和邏輯處理。同樣，整個流程的大部分工作已經(jīng)由 Flutter 統(tǒng)一，我們要做的僅僅是在原生容器上 監(jiān)聽 用戶的輸入，并 封裝 成指定格式交給引擎層而已。

在鴻蒙系統(tǒng)上，我們可以借助平臺提供的 多模輸入 API ，實現(xiàn)多種類型事件的監(jiān)聽：

flutterComponent.setTouchEventListener(touchEventListener); // 觸摸及鼠標事件 
flutterComponent.setKeyEventListener(keyEventListener); // 鍵盤錄入事件 
flutterComponent.setSpeechEventListener(speechEventListener); // 語音錄入事件 

對于事件的封裝處理，可以復(fù)用 Android 已有邏輯，只需要關(guān)注鴻蒙與 Android 在事件處理上的對應(yīng)關(guān)系即可，比如觸摸事件的部分對應(yīng)關(guān)系：

3. 其他必要的平臺能力

為了保證 Flutter 應(yīng)用能夠正常運行，除了最基本的渲染和交互外，我們的嵌入層還要提供資源管理、事件循環(huán)、生命周期同步等平臺能力。對于這些能力 Flutter 大多都在嵌入層的公共部分有抽象類聲明，只需要使用鴻蒙 API 重新實現(xiàn)一遍即可。

比如資源管理，引擎提供了 AssetResolver 聲明，我們可以使用鴻蒙 Rawfile API 來實現(xiàn)：

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); 
}; 

對于事件循環(huán)，引擎提供了 MessageLoopImpl 抽象類，我們可以使用鴻蒙 Native_EventHandler API 實現(xiàn)：

// 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 提供了完整的生命周期回調(diào)（如下圖所示），我們只需要在對應(yīng)的時機將狀態(tài)上報給引擎即可。

當(dāng)以上這些能力都準備好之后，我們就可以成功把 Flutter 應(yīng)用跑起來了。以下是通過 DevEco Studio 運行官方 flutter gallery 應(yīng)用的截圖，截圖中 Flutter 引擎已經(jīng)使用鴻蒙系統(tǒng)的平臺能力進行了重寫：

借由鴻蒙的多設(shè)備支持能力，此應(yīng)用甚至可在 TV、車機、手表、平板等設(shè)備上運行：

總結(jié)和展望

通過上述的構(gòu)建和適配工作，我們以極小的開發(fā)成本實現(xiàn)了 Flutter 在鴻蒙系統(tǒng)上的移植，基于 Flutter 開發(fā)的上層業(yè)務(wù)幾乎不做任何修改就可以在鴻蒙系統(tǒng)上原生運行，為迎接鴻蒙系統(tǒng)后續(xù)的大規(guī)模推廣也提前做好了技術(shù)儲備。

當(dāng)然，故事到這里并沒有結(jié)束。在最基本的運行和交互能力之上，我們更需要關(guān)注 Flutter 與鴻蒙自身生態(tài)的結(jié)合：如何優(yōu)雅地適配鴻蒙的分布式技術(shù)？如何用 Flutter 實現(xiàn)設(shè)備之間的快速連接、資源共享？現(xiàn)有的眾多 Flutter 插件如何應(yīng)用到鴻蒙系統(tǒng)上？未來 MTFlutter 團隊將在這些方面做更深入的探索，因為解決好這些問題，才是真正能讓應(yīng)用覆蓋用戶生活的全場景的關(guān)鍵。