Flutter由于可以跨平台，再加上出自Google，在移动端颇受关注，有点像当初J2EE之于企业应用。Flutter主要的优势是跨平台，采用自己的Dart虚拟机和Skia渲染引擎，从而不依赖Native语言和渲染，并且支持AOT和JIT编译机制，从而性能和效果也能得到保证。其中Flutter的语言Dart与JS十分接近，其Widgets与Web Components的理念也十分相似，所以很适合Web开发思路，即支持页面动态化更新和可视化搭建。

Flutter动态化基本思路

通过定义统一的描述语言DSL（Domain Special Language，这里采用JSON，用来表示组件的结构、样式和行为)，然后通过可视化平台来拖拽出JSON模板，最后将JSON模板下发到Flutter App，Flutter App内置了JS模板引擎以及DSL解析引擎，由它们将DSL解析映射为Flutter Widgets或者渲染对象。

Flutter动态化整体架构

总体架构上分为四大部分，第一部分是可视化搭建平台，负责开发DSL页面和配置数据。第二部分是低代码服务中台，提供组件保存、页面发布和数据加工能力。第三部分是面向端的接口服务，包括模板和数据接口。第四部分是端，这块是核心重点，端上需要支持一整套DSL的解析和渲染映射，并且要做好相应的优化，以保证渲染性能和效率。

通过以上分层我们了解到，核心是端的能力需要支持整个机制。后端需要配合提供开发和接口能力。

Flutter动态化机制

Flutter整体动态化方案如下图所示，开发者基于组件中心提前开发出组件和页面模板，使用者利用可视化搭建平台拖拽组件生成页面，再配置数据源，最后保存发布。页面中心会分别通知到页面模板和数据接口服务，当终端请求接口时，就可以获取到最新的页面模板以及对应的数据内容。当终端获取到DSL页面模板以及对应的数据内容时，利用预置的JS模板引擎和DSL解析引擎将DSL页面和数据合成并转换为Flutter渲染对象，从而实现页面的渲染。

页面模板接口端上可以实时获取，也可以提前下发。页面模板没有数据那么频繁更新，很适合做预加载和本地缓存，当然数据也可以适当预加载。当App启动时检测页面模板是否更新，如果更新则提前加载页面模板。同时App在运行过程中实时监听云端的消息，当页面模板有新版本时，App再拉取和更新本地的缓存。

Flutter动态化App组成

Flutter App是一个基础脚手架，包括通用工具、内置的SDK等，同时提供JS模板引擎和DSL解析引擎，可以用于将远程DSL模板映射为Flutter Widgets和Render Object。

Flutter App里面除了框架以及不经常运营的页面(如个人中心、帮助文档等）无需DSL动态下发，其他页面包括首页、频道页、信息流页面以及活动专题均采用动态下发的模式。这样用户看到的主要页面均是可以动态更新，类似Web网站一样。

Flutter动态化组件结构

组件结构根据DSL定义来生成，一般来讲主要就是布局、块、基本元素等。适合动态下发的内容是中间挖空的部分，而不是全部。这样我们主体App依然是Flutter原生开发，只有页面才需要动态化下发。

Flutter动态化DSL代码组成

DSL作为专门领域的描述语言，这里就采用JSON来描述组件的结构、样式以及行为。

这块需要细化到具体元素的详细定义，具体?规则?可以类比HTML与CSS以及DOM事件。一开始可以比较简单，满足基本的展现即可，以后根据实际需要再不断往上增强。

Flutter低代码搭建流程

由于DSL是一个复杂的JSON结构，可以本地写，也可以借助在线可视化工具来生成。用户在搭建页面时利用可视化工具拖拽组件到页面中，并局部调整元素(或元组)，再配置基本动作和数据源来完成页面的搭建。页面发布到页面中心，接口就会监听到消息，端上取到的数据将是动态的内容。

最后

通过这种方式，我们基本实现了一套Flutter动态化下发方案，从而解决App改动依赖发版的问题。这种模式对于页面改版、运营增强以及Bug修复等都将变得便利。但要注意的是，不能让App整体动态化，那样存在被应用商店封杀的危险。再有，动态化方案不是万能的，毕竟App模式属于软件模式，与Web模式本质上不同。

关于App动态化方案，国外国内也有很多的方案，从Hybird、ReactNative到小程序、PWA等，但都不完善，相对来讲这种DSL模式似乎更加合适一些。关于Flutter动态化方案，一些互联网大厂也都有类似的开源项目，但也都没有完美的方案，因此对于有能力的企业来说，摸索和搭建一套适合自己业务场景的动态化方案是值得做的。