Flutter框架可以跨Fuchsia、Android、iOS平台应用
动态化响应特征的技术即动态化技术。 GDI(GraphicsDeviceInterface)是图形设备接口,GDI主要任务是负责系统与绘图程序间的信息交换,处理所有Windows程序或系统方面的图形输出。Flutter增量包的内部本身内嵌有GDI提供的众多函数，通过这些本身内嵌的众多GDI函数，Flutter体系自身可以实现元组件器皿的绘制(Flutter体系不需要依赖于平台/跨平台的本质来源)。
几大动态化技术初涉：
性能体验 由于在Flutter体系下元组件的绘制渲染基础核心即众多GDI函数是直接内嵌在本身内部的SDK底层，所以对于平台的依赖性极低，可以轻易的实现跨平台、性能优化，可以轻易的摆脱平台的约束。在众多的跨平台方案中，Flutter方案的性能比 RN方案的性能要高。Flutter框架体系采用运行时语言：从前端思维来看，Flutter涉及的jsx风格语言或dart风格语言都是声明式语法。jsx语法需要转译（工程上看起来(越发接近自然语言的习惯)舒坦的语言肯定需要在别的资源或性能方面消耗更多），dart语言是直接在语言编写层面上支持nodeTree模式的书写且创建对象消耗成本低，dart语言源码可直接编译而后在各种平台产生对应的native源代码效果(AOT)，转换后VM效率更高。在跨平台方案中，运行方面应该是Flutter方案的 dart语言效率高于RN很多。 渲染机制：RN体系下SDK包是依据前端逻辑方式搭建的框架，RN体系在表达复杂的UI视觉效果时需要依赖前端元组件集成体的深层次叠加嵌套。基于RN背景，RN体系中的每个RN元组件都等效于平台native源码的view集成组件，相比单纯的 平台native原生开发来说需要重新构建很多新的view对象，造成性能降低。对于越复杂的UI渲染需求，通过RN来对UI进行表达运行渲染的效率越低于平台native原生开发的效率性能低下。Flutter体系是基于gdi层面直接进行，每个node布局是否需要一个layer及rendertree怎么划分和实现都有更多灵活性和性能优化空间，所以能做到性能更优化。组件的兼容性：Flutter体系提供的widget元组件都是基于skia/gdi实现和精心定制，与具体平台没关，所以能保持很高的跨os跨os version 的兼容性。跨平台 RN本质是一套概念/设计理念跨越两个平台，但要想具体到实际平台上渲染奏效还要去 适配和桥接 差异性（存在巨大的工程成本和性能牺牲，如做动画，js绝对不能用，用js做动画性能就差）。Flutter框架至少做到一套代码自动部署多平台（不涉及平台api层面的UI及纯事件响应可以完全一样）。Flutter框架相对来说是做到了跨平台一套代码自动部署多平台。RN 适合称为：将一种设计理念延展到两个平台，但还要去 适配和桥接 差异性，做不到一套代码多平台自动部署。对未来的适应性 由于Flutter框架从更基础的GDI渲染绘制层抹平平台差异，Flutter框架站在更宽广、更可控的基础平台上去演变和发展，受到的限制更少。RN框架需要相对于各种平台做差异性桥接适配，受到native原生平台开发的约束，桥接和抹平差异乃至应用层适配的成本、面对具体场景去优化性能所需要的成本都居高不下。动态化作为首要考虑条件时，RN属于“大公司扛大旗，赚吆喝，小公司跟着复用现有资源”。动态化技术未来 RN/weex设计理念短期内行不远。动态化技术领域内最成熟的是H5/Web，真正产业化技术栈是H5/Web。业界（软件公司、开发团队）对于动态化技术最大的期待是H5，H5开发要由浏览器来支撑的，RN源码的运行能力不到H5源码浏览器运行能力5%(RN/Weex体系需要产品/业务将就“技术”很多功能无法实现 )。研发模式 Dart语言相关的vm/debug/hot reload都是Google官方开发和支持的，Flutter框架也定位于未来的跨平台应用框架，更是 FuchsiaOS的正统AppFramework框架。结论：Flutter框架从设计、体验、跨平台方面都有亮点。目前成熟度有限，不适合商用；不做改造的前提下，不具备动态化能力。