做了2个多月的设计和编码，我梳理了Flutter动态化的方案对比及最佳实现

a.下载替换Flutter编译产物

下载新的Flutter编译产物，替换 App 安装目录下的编译产物，来实现动态化，这在Android 端是可行的，但在Ios 端不可行。我们需要双端一体的解决方案，所以这不是最好选择。

b.类似React Native 框架

我们先来看看React Native 的架构

React Native 要转为android（ios） 的原生组件，再进行渲染。 用React Native的设计思路，把XML DSL转为Flutter 的原子widget组件，让Flutter 来渲染。技术上说是可行的，但这个成本很大，这会是一个庞大的工程，从投入产出比看，不是很好的选择

c.页面动态组件框架

由粗粒度的Widget组件动态拼装出页面，Native端已经有很多成熟的框架，如天猫的Tangram，淘宝的DinamicX，它在性能、动态性，开发周期上取得较好平衡。关键它能满足大部分的动态性需求，能解决问题。

三种方案的比较图表如：

根据实际动态性需求，从两端一致性，和性能，成本，动态性考虑，我们选择一个折中方案，页面动态组件的设计思路是一个不错的选择。

 所以选择了Flutter 源码作为DSL，来实现动态化。

看下Flutter analyze 源码结构，它使用了dart sdk 里面的 package:analyzer

dart-sdk:  
     analysis_server: 
        analysis_server.dart
        handleRequest(Request request) 
     analyzer:
        parseCompilationUnit（）
        parseDartFile 
        parseDirectives 

Flutter analyze 解析源码得到ASTNode过程。

插件或者命令对analysis server发起请求，请求中带需要分析的文件path，和分析的类型，analysis_server经过使用 package:analyzer 获取 commilationUnit （ASTNode），再对astNode，经过computer分析，返回一个分析结果list。

同样我们也可以把使用 package:analyzer 把源文件转换为commilationUnit （ASTNode)，ASTNode是一个抽象语法树，抽象语法树（abstract syntax tree或者缩写为AST）是源代码的抽象语法结构的树状表现形式.

所以利用抽象语法树能很好的解析dart 源码。

下面重点介绍渲染模块

架构图：

1.源码解析过程

a.AST树的结构

如下面这段Flutter组件源码：

import 'package:flutter/material.dart';
class FollowedTopicCard extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return new Container(
      padding: const EdgeInsets.fromLTRB(12.0, 8.0, 12.0, 0.0),
      child: new InkWell(
        child: new Center(
          child: const Text('Plugin example app'),
        ),
        onTap: () {},
      ),
    );
  }
}

它的AST结构：

从AST结构看，他是有规律的.

b.AST 到widget Node

我们拿到了ASTNode，但ASTNode 和widget node tree 完全是两个不一样的概念， 需要递归ASTNode 转化为 widget node tree.

widget Node 需要的元素

用Name 来记录是什么类型的widget

widget的arguments放在 map里面

widget 的literals 放在list 里面

widget 的children 放在lsit里面

widget 的触发事件 函数map里面

widget node 加fromjson ，tojson 方法

可以在递归astNode tree 时候，识别InstanceCreationExpression来创建一个widget node。

2.组件数据渲染

框架sdk 中注册支持的组件，组件包括：

a.原子组件：Flutter sdk 中的 Flutter 的widget

b.本地组件：本地写好到一个大颗粒的组件，卡片widget组件

c.逻辑组件：本地包装了逻辑的widget组件

d.动态组件：通过源码dsl动态渲染的widget

具体代码如下：

 const Map<String, CreateDynamicApi> allWidget = <String,  
 CreateDynamicApi>{
  'Container': wrapContainer,
     ………….
}
 static Widget wrapContainer(Map<String, dynamic> pars) {
  return new Container(
    padding: pars['padding'],
    color: pars['color'],
    child: pars['child'],
    decoration: pars['decoration'],
    width: pars['width'],
    height: pars['height'],
    alignment: pars['alignment']
  );
}

一般我们通过网络请求拿到的数据是一个map。 比如源码中写了这么一个 '${data.urls[1]}' AST 解析时候，拿到这么一个string，或者AST 表达式，通过解析它 ，肯定能从map 中拿到对应的值。

3.逻辑和事件

a.支持逻辑

Flutter 概念万物都是widget ，可以把表达式，逻辑封装成一个自定义widget。如果在源码里面写了if else，变量等，会加重sdk解析的过程。所以把逻辑封装到widget中。这些逻辑widget，当作组件当成框架组件。

b.支持事件

把页面跳转，弹框，等服务，注册在sdk里面。约定使用者仅限sdk 的服务。

4.规则和检测工具

a.检测规则

需要对源码的格式制定规则。比如不支持 直接写if else ，需要使用逻辑wiget组件来代替if else 语句。如果不制定规则，那ast Node 到widget node 的解析过程会很复杂。理论上都可以解析，只要解析sdk 够强大。制定规则，可以减轻sdk的解析逻辑。

b.工具检测

用工具来检测源码是否符合制定的规则，以保证所有的源码都能解析出来。

class DataModel {
  Map<dynamic, dynamic>  data;
  String type;
}

每个page 都是由组件组成的，每个组件的数据都是 DataModel来渲染。 根据type 来找到对应的模版，模版+data，渲染出界面。

UI自动化 ，前面已经有文章介绍。UI自动化工具生成组件，再组件转为模版，动态下发，来快速解决运营需求。

b.国际化的支持

App在不同国家会有不同的功能，我们可以根据区域，来动态拼装我们的页面。

c.千人千面

根据不同的人群，来动态渲染不一样的界面。