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

0 1背景

在端上为了提升App的灵活性， 快速解决万变的业务需求，开发者们探索了多种解决方案，如PhoneGap ，React Native ,Weex等，但在Flutter生态还没有好的解决方案。未来闲鱼都会基于Flutter 来跨端开发，如果突破发版周期，在不发版的情况下，完成业务需求，同时能兼容性能体验，无疑是更快的响应了业务需求。因此我们需要探索在Flutter生态下的动态化。

0 2方案选择

借鉴Android 和Ios上的动态性方案，我们也思考了多种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，它在性能、动态性，开发周期上取得较好平衡。关键它能满足大部分的动态性需求，能解决问题。

三种方案的比较图表如：

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

0 3页面动态组件框架

在Flutter上使用粗粒度的组件动态拼装来构建页面，需要一整套的前后端服务和工具。本文我们重点介绍前端界面渲染引擎过程。

语法树的选择

Native端的Tangram ，DinamicX等框架他们有个共同点，都是Xml或者Html 做为DSL。但是Flutter 是React Style语法。他自己的语法已经能很好的表达页面。无需要自定义的Xml 语法，自定义的逻辑表达式。用Flutter 源码做为DSL 能大大减轻开发，测试过程，不需要额外的工具支持。

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

如何解析DSL

Flutter源码做为DSL，那我们需要对源码进行很好的解析和分析。Flutter analyzer给了我们一些思路，Flutter analyzer是一个代码风格检测工具。它使用package:analyzer来解析dart 源码，拿到ASTNode。