打通前後端邏輯，客戶端Flutter程式碼一天上線

背景

隨著閒魚的業務快速增長，運營類的需求也越來越多，其中不乏有很多介面修改或運營坑位的需求。閒魚的版本現在是每2週一個版本，如何快速迭代產品，跳過視窗期來滿足這些需求？另外，閒魚客戶端的包體也變的很大，Android的包體大小，相比2016年，已經增長了近1倍，怎麼能將包體大小降下來？首先想到的是動態化的解決此類問題。

對於原生的能力的動態化，Android平臺各公司都有很完善的動態化方案，甚至Google還提供了Android App Bundles讓開發者們更好地支援動態化。由於Apple官方擔憂動態化的風險，因此並不太支援動態化。因此動態化能力就會考慮跟Web結合，從一開始基於 WebView 的 Hybrid 方案，到現在與原生相結合的 React Native 、Weex。

與此同時，隨著閒魚Flutter技術的推廣，已經有10多個頁面用Flutter實現，上面提到的幾種方式都不適合Flutter場景，如何解決這個問題Flutter的動態化的問題？

動態方案

我們最初調研了Google的動態化方案CodePush。

01

Code Push

CodePush是谷歌官方的動態化方案，Dart VM在執行的時候，載入 isolate_snapshot_data 和 isolate_snapshot_instr 2個檔案，透過動態更改這些檔案，就達到動態更新的目的。官方的Flutter原始碼當中，已經有相關的提交來做動態更新的內容，具體可以參考 ResourceExtractor.java。目前，此功能還在開發中，期待ing。

02

動態模版

動態模板，就是透過定義一套DSL，在端側解析動態的建立View來實現動態化，比如LuaViewSDK、Tangram-iOS和Tangram-Android。這些方案都是建立的Native的View，如果想在Flutter裡面實現，需要建立Texture來橋接；Native端渲染完成之後，再將紋理貼在Flutter的容器裡面，實現成本很高，效能也有待商榷，不適合閒魚的場景。

所以我們提出了閒魚自己的Flutter動態化方案，前面已經有同事介紹過方案的原理：《做了2個多月的設計和編碼，我梳理了Flutter動態化的方案對比及最佳實現》，下面看下具體的實現細節。

模版編譯

自定義一套DSL，維護成本較高，怎麼能不自定義DSL來實現模板下發？閒魚的方案就是直接將Dart檔案轉化成模板，這樣模板檔案也可以快速沉澱到端側。

01

模版規範

先來看下一個完整的模板檔案，以新版我的頁面為例，這個是一個列表結構，每個區塊都是一個獨立的Widget，現在我們期望將“賣在閒魚”這個區塊動態渲染，對這個區塊拆分之後，需要3個子控制元件：頭部、選單欄、提示欄；因為這3部分介面有些邏輯處理，所以先把他們的邏輯內建。

內建的子控制元件分別是 MenuTitleWidget、 MenuItemWidget和 HintItemWidget，編寫的模板如下：

@override
Widget build(BuildContext context) {
    return new Container(
        child: new Column(
            children: <Widget>[
                new MenuTitleWidget(data),    // 頭部
                new Column(    // 選單欄
                    children: <Widget>[
                        new Row(
                            children: <Widget>[
                                new MenuItemWidget(data.menus[0]),
                                new MenuItemWidget(data.menus[1]),
                                new MenuItemWidget(data.menus[2]),
                            ],
                        )
                    ],
                ),
                new Container(    // 提示欄
                    child: new HintItemWidget(data.hints[0])),
            ],
        ),
    );
}

中間省略了樣式描述，可以看到寫模板檔案就跟普通的widget寫法一樣，但是有幾點要注意：

1. 每個Widget都需要用 new或 const來修飾

2. 資料訪問以 data開頭，陣列形式以 []訪問，字典形式以 .訪問

模板寫好之後，就要考慮怎麼在端上渲染，早期版本是直接在端側解析檔案，但是考慮到效能和穩定性，還是放在前期先編譯好，然後下發到端側。

02

編譯流程

編譯模板就要用到Dart的 Analyzer庫，透過 parseCompilationUnit函式直接將Dart原始碼解析成為以 CompilationUnit為Root節點的AST樹中，它包含了Dart原始檔的語法和語義資訊。接下來的目標就是將 CompilationUnit轉換成為一個JSON格式。

上面的模板解析出來build函式孩子節點是 ReturnStatementImpl，它又包含了一個子節點 InstanceCreationExpressionImpl，對應模板裡面的 newContainer(…)，它的孩子節點中，我們最關心的就是 ConstructorNameImpl和 ArgumentListImpl節點。 ConstructorNameImpl標識建立節點的名稱， ArgumentListImpl標識建立引數，引數包含了引數列表和變數引數。

定義如下結構體，來儲存這些資訊：

class ConstructorNode {
    // 建立節點的名稱
    String constructorName;
    // 引數列表
    List<dynamic> argumentsList = <dynamic>[];
    // 變數引數
    Map<String, dynamic> arguments = <String, dynamic>{};
}

遞迴遍歷整棵樹，就可以得到一個 ConstructorNode樹，以下程式碼是解析單個Node的引數：

ArgumentList argumentList = astNode;

for (Expression exp in argumentList.arguments) {
    if (exp is NamedExpression) {
        NamedExpression namedExp = exp;
        final String name = ASTUtils.getNodeString(namedExp.name);
        if (name == 'children') {
            continue;
        }

        /// 是函式
        if (namedExp.expression is FunctionExpression) {
            currentNode.arguments[name] =
                FunctionExpressionParser.parse(namedExp.expression);
        } else {
            /// 不是函式
            currentNode.arguments[name] =
                ASTUtils.getNodeString(namedExp.expression);
        }
    } else if (exp is PropertyAccess) {
        PropertyAccess propertyAccess = exp;
        final String name = ASTUtils.getNodeString(propertyAccess);
        currentNode.argumentsList.add(name);
    } else if (exp is StringInterpolation) {
        StringInterpolation stringInterpolation = exp;
        final String name = ASTUtils.getNodeString(stringInterpolation);
        currentNode.argumentsList.add(name);
    } else if (exp is IntegerLiteral) {
        final IntegerLiteral integerLiteral = exp;
        currentNode.argumentsList.add(integerLiteral.value);
    } else {
        final String name = ASTUtils.getNodeString(exp);
        currentNode.argumentsList.add(name);
    }
}

端側拿到這個 ConstructorNode節點樹之後，就可以根據Widget的名稱和引數，來生成一棵Widget樹。

渲染引擎

端側拿到編譯好的模板JSON後，就是解析模板並建立Widget。先看下，整個工程的框架和工作流：

工作流程：

1. 開發人員編寫dart檔案，編譯上傳到CDN

2. 端側拿到模板列表，並在端側存庫

3. 業務方直接下發對應的模板id和模板資料

4. Flutter側再透過橋接獲取到模板，並建立Widget樹

對於Native測，主要負責模板的管理，透過橋接輸出到Flutter側。

01

模版獲取

模板獲取分為2部分，Native部分和Flutter部分；Native主要負責模板的管理，包括下載、降級、快取等。

程式啟動的時候，會先獲取模板列表，業務方需要自己實現，Native層獲取到模板列表會先儲存在本地資料庫中。Flutter側業務程式碼用到模板的時候，再透過橋接獲取模板資訊，就是我們前面提到的JSON格式的資訊，Flutter也會有快取，已減少Flutter和Native的互動。

02

widget建立

Flutter側當拿到JSON格式的，先解析出 ConstructorNode樹，然後遞迴建立Widget。

建立每個Widget的過程，就是解析節點中的 argumentsList和 arguments 並做資料繫結。例如，建立 HintItemWidget需要傳入提示的資料內容， newHintItemWidget(data.hints[0])，在解析 argumentsList時，會透過key-path的方式從原始資料中解析出特定的值。

解析出來的值都會儲存在 WidgetCreateParam裡面，當遞迴遍歷每個建立節點，每個widget都可以從 WidgetCreateParam裡面解析出需要的引數。

ArgumentList argumentList = astNode;

for (Expression exp in argumentList.arguments) {
    if (exp is NamedExpression) {
        NamedExpression namedExp = exp;
        final String name = ASTUtils.getNodeString(namedExp.name);
        if (name == 'children') {
            continue;
        }

        /// 是函式
        if (namedExp.expression is FunctionExpression) {
            currentNode.arguments[name] =
                FunctionExpressionParser.parse(namedExp.expression);
        } else {
            /// 不是函式
            currentNode.arguments[name] =
                ASTUtils.getNodeString(namedExp.expression);
        }
    } else if (exp is PropertyAccess) {
        PropertyAccess propertyAccess = exp;
        final String name = ASTUtils.getNodeString(propertyAccess);
        currentNode.argumentsList.add(name);
    } else if (exp is StringInterpolation) {
        StringInterpolation stringInterpolation = exp;
        final String name = ASTUtils.getNodeString(stringInterpolation);
        currentNode.argumentsList.add(name);
    } else if (exp is IntegerLiteral) {
        final IntegerLiteral integerLiteral = exp;
        currentNode.argumentsList.add(integerLiteral.value);
    } else {
        final String name = ASTUtils.getNodeString(exp);
        currentNode.argumentsList.add(name);
    }
}

透過以上的邏輯，就可以將 ConstructorNode樹轉換為一棵 Widget樹，再交給Flutter Framework去渲染。

至此，我們已經能將模板解析出來，並渲染到介面上，互動事件應該怎麼處理？

03

事件處理

在寫互動的時候，一般都會透過 GestureDector、 InkWell等來處理點選事件。互動事件怎麼做動態化？

以 InkWell元件為例，定義它的 onTap函式為 openURL(data.hints[0].href,data.hints[0].params)。在建立 InkWell時，會以 OpenURL作為事件ID，查詢對應的處理函式，當使用者點選的時候，會解析出對應的引數列表並傳遞過去，程式碼如下：

...
final List<dynamic> tList = <dynamic>[];
// 解析出引數列表
exp.argumentsList.forEach((dynamic arg) {
    if (arg is String) {
        final dynamic value = valueFromPath(arg, param.data);
        if (value != null) {
            tList.add(value);
        } else {
            tList.add(arg);
        }
    } else {
        tList.add(arg);
    }
});

// 找到對應的處理函式
final dynamic handler =
    TeslaEventManager.sharedInstance().eventHandler(exp.actionName);
if (handler != null) {
    handler(tList);
}
...

效果

新版我的頁面新增了動態化渲染能力之後，如果有需求新新增一種元件型別，就可以直接編譯釋出模板，服務端下發新的資料內容，就可以渲染出來了；動態化能力有了，大家會關心渲染效能怎麼樣。

01

幀率

在加了動態載入邏輯之後，已經開放了2個動態卡片，下圖是新版本我的頁面近半個月的的幀率資料：

從上圖可以看到，幀率並沒有降低，基本保持在55-60幀左右，後續可以多新增動態的卡片，觀察下效果。

注：因為我的頁面會有本地的一些業務判斷，從其他頁面回到我的tab，都會重新整理介面，所以幀率會有損耗。

從實現上分析，因為每個卡片，都需要遍歷 ConstructorNode樹來建立，而且每個構建都需要解析出裡面的引數，這塊可以做一些最佳化，比如快取相同的Widget，只需要對映出資料內容並做資料繫結。

02

失敗率

現在監控了渲染的邏輯，如果本地沒有對應的Widget建立函式，會主動拋Error。監控資料顯示，渲染的流程中，還沒有異常的情況，後續還需要對橋接層和native層加錯誤埋點。

後續計劃

基於Flutter動態模板，之前需要走發版的Flutter需求，都可以來動態化更改。而且以上邏輯都是基於Flutter原生的體系，學習和維護成本都很低，動態的程式碼也可以快速的沉澱到端側。

另外，閒魚正在研究UI2Code的黑科技，不瞭解的老鐵，可以參考閒魚大神的這篇文章《重磅系列文章！UI2CODE智慧生成Flutter程式碼——整體設計篇》。可以設想下，如果有個需求，需要動態的顯示一個元件，UED出了視覺稿，透過UI2Code轉換成Dart檔案，再透過這個系統轉換成動態模板，下發到端側就可以直接渲染出來，程式設計師都不需要寫程式碼了，做到自動化運營，看來以後程式設計師失業也不是沒有可能了。

基於Flutter的Widget，還可以擴充更多個性化的元件，比如內建動畫元件，就可以動態化下發動畫了，更多好玩的東西等待大家來一起探索。

參考文獻

3. https://mp.weixin.qq.com/s/4s6MaiuW4VoHr7f0SvuQ