京東:將Flutter擴展到微信小程序端的探索

ARES作爲京東技術中臺的多端融合技術團隊,聚焦於跨端開發技術框架和平臺搭建,包括但不限於RN、Flutter、小程序等技術棧。目前已經廣泛應用於京東商城、京東金融、京東到家、京東拼購等京東La系核心APP內,幫助業務團隊低成本、快速開發自己的業務,以應對市場的瞬息萬變之勢。

Google Flutter是一個非常優秀的跨端框架,不僅可以運行在Android、 iOS平臺,而且可以支持Web和桌面應用。在國內小程序是非常重要的技術平臺,我們也一直思考能否把Flutter擴展到小程序端?我們團隊之前已經開源了Alita項目,Alita可以把React Native的代碼轉換並運行在微信小程序平臺。受此啓發,我們認爲同樣是聲明式UI框架的Flutter同樣可以運行在小程序平臺。

所以,我們發起了flutter_mp開源項目。以微信小程序爲例,不過現階段,flutter_mp項目還處於早期的實驗階段,很多功能還在探索規劃中,歡迎大家在Github上隨時關注我們的最新進展,或者參與項目共同探索。

原理簡介

雖然還有諸多功能未完成,我們先來談談整個flutter_mp的實現原理。篇幅原因,下面我們將只對flutter_mp幾個重要的部分進行簡單說明。

先看下flutter_mp的實際效果:

Flutter版官方layout樣例

通過flutter_mp轉換並運行在小程序端效果

聲明式UI的處理

Flutter是聲明式UI框架,聲明式UI只需要向框架描述UI長什麼樣子而不用關心框架具體的實現細節,具體到Flutter,上層的UI描述使用底層的skia圖形引擎處理就是原生Flutter,而把底層處理換成html/css/canvas就是flutter_webflutter_mp則是探索在類小程序上對這些UI描述的處理。

我們看一個最簡單例子

var x = 'Hello World'

Center(
     child: Text(x)
);

對於上面的UI結構,我們只需要在小程序的wxml文件裏,用如下的結構對應就OK了。

// wxml部分
<Center>
   <Text>{{x}}</Text>
</Center>

// js 部分
Component({
   data: {
       x: 'Hello World'
   }
}) 

雖然實際的結構要比上面的情況複雜的多,不過通過上面簡單的例子,我們知道起碼要做兩個事情:

  1. 我們需要根據Flutter代碼生成相關小程序wxml模版文件
  2. 收集wxml渲染需要的數據,放置到小程序組件的data字段。

wxml結構生成

我們知道小程序是無法動態操作節點的,wxml結構需要預先生成,所以Flutter運行在小程序之前,會存在一個編譯打包階段,這個階段會遍歷Dart代碼,根據一定規則生成wxml文件(編譯階段還會做下文將要提到的另外一個重要事情 — 把Dart編譯爲js)。

具體的,我們首先會將Dart源碼處理爲可分析的AST結構,AST是源代碼的樹型表示結構。然後我們深度遍歷這份AST語法樹結構,生成目標wxml,整個過程如下:

構建wxml結構的難點在於: Flutter不僅是聲明式UI還是“值UI”,什麼叫“值UI”?簡單來說,Flutter把UI看成是一個普通的值,類似於字符串,數字一樣的值,既然是一個普通的值,就可以參與所有的控制流程,可以是函數的返回值也可以是函數參數等等。而小程序的wxml雖然也是聲明式UI,卻不是“值UI”,wxml更加像模版,更加的靜態。怎麼用靜態的wxml表達動態的“值UI”是構建wxml結構的關鍵所在。

看個例子:

Widget getX() {
    if (condition1) {
        return Text('Hello');
    } else if (condition2) {
        return Container(
            child: ...
        );
    } else if (condition3) {
        return Center(
            child: ...
        );
    }
    ...
}

Widget x = getX();

Center(
   child: x      // < --- 如何處理這裏的 x??
);

這裏的 child: x ,x是一個動態值,它的具體值需要在運行階段才能確定,它可能是任意的Widget,如何在靜態的wxml上處理這裏動態的x?受Alita框架的啓發,這裏主要是藉助於小程序template的動態性(template的is屬性可以接受變量值)。有如下幾步:

  1. 首先在遍歷Dart源碼AST結構的時候,會把每一個獨立完整的“UI值”片段,對應到wxml的template, 比如上文 getX 裏面的UI
<template name="template001">
    <text>Hello</text>
</template>
<template name="template002">
    <Container>...</Container>
</template>
<template name="template003">
    <Center>...</Center>
</template>
  1. 在遇到 類似x 這種動態值的時候,固定地會生成一個template佔位。
<template name="template004">
    <Center>
        <template is="{{templateName}}" data="{{...templateData}}"/>
    </Center>
<template name="template003">
  1. 在運行階段,會根據getX 函數的運行結果來決定x映射的“UI值”,如果getX裏面condition1爲true,那麼這裏的templateName的值就是template001*。*具體的數據計算收集工作,參考下面要的 “渲染數據收集”過程。

可以看出flutter_mp處理“值UI”方式,完全參考了Alita。

渲染數據收集

wxml結構的生成是在編譯階段就完成了,與它不同渲染數據是運行時的信息,隨時會根據setState而改變。那麼我們怎麼收集出我們需要的渲染數據呢?

如果我們還是順着Flutter的架構圖,很難插入我們收集的鉤子函數,另外Flutter的這個架構對於小程序來說太重了,下圖紅框裏的這些過程對於小程序的渲染來說並不必要。最後由於最終的代碼會被轉化爲js,而Flutter本身依賴的庫裏面很多是不支持轉化js的,比如dart:ui等等。

所以我們實現了一個極簡極簡的Flutter小程序版本mini_flutter,在編譯期我們會把所有對Flutter庫的引用替換爲mini_flutter, mini_flutter只存在到上圖的Rendering階段,這個Rendering的實現也是爲小程序定製的, 在運行時期Rendering不斷收集Widgets的信息。最終生成一個UI描述的JSON結構,這個結構就包含了上文所說的templateNametemplateData,UI描述將會被下層小程序獲得,用來渲染小程序UI,架構圖如下:

Dart/JS:轉化與互操作

Flutter的開發語言是Dart,而小程序的運行環境是瀏覽器,所以我們還需要把Dart編譯爲JavaScript代碼。

在上文的編譯打包階段也提到這一點,這個過程主要是使用了Dart提供的dart2js工具,不過,針對小程序環境,生成的js代碼仍需要做一些適配,另外雖然都是JS代碼,dart2js生成的js和小程序原生js的運行環境卻是隔離的,也就是說它們是不能共享變量,方法等等,它們各自在本身的"域"裏執行。

這帶來兩個問題:

  1. Widget 初始化 或者setState更新,生成的UI描述JSON,如何傳遞給小程序"域"呢?
  2. 相關渲染回調,事件的都發生在小程序"域",這些信息如何傳遞給Dart?

總結一下:Dart(最終會編譯爲JS)與小程序原生JS如何互操作?

解決這個問題主要是藉助dart:js, package:js這兩個庫:

Dart操作JS:

import 'package:js/js.dart';

@JS("JSON.stringify")
external stringify(String str);

這樣當Dart代碼調用stringify方法的時候,實際上會執行window.JSON.stringify方法

JS操作Dart:

// dart註冊
void main() {
    context['dartHi'] = () {
        print('dart hi!');
    };
}
// js 調用
window.dartHi()

這裏只是簡單說明Dart與JS的互操作,另外由於小程序的運行環境是閹割以後的瀏覽器環境,flutter_mp的實現還稍有不同。

總之,Dart與JS是可以互操作的,這樣就打通了上層Flutter環境和下層小程序環境。

佈局系統

Flutter的佈局系統不同與css,但是和css頗相似。

在上文提到的Rendering階段,會根據Widget的佈局屬性,類別,約束條件生成一個等效的css樣式。注意這裏邊界約束是上下文相關的。比如一個沒有寬高的Container實際大小,不僅和子元素相關,還和父元素傳遞過來的邊界約束條件相關,這個其實是比較麻煩的,能不能把Flutter的Widget屬性,邊界約束完全用css表達,我們還在尋求有效的方案。

總結

flutter_web一樣,完全把Flutter所有特性渲染到小程序上是不可能的,一般我們覺得應該是部分頁面,部分功能需要運行在小程序上,這樣使用flutter_mp纔是有意義的。

正如前文所說,flutter_mp還在很早期的階段,社區的支持和反饋對我們來說特別寶貴。同時歡迎廣大開發者一起來維護flutter_mp

如果你需要在生產環境實現小程序跨端開發,推薦使用我們成熟的RN轉小程序項目Alita

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章