当前几大动态化技术对比

1. 性能和体验
   Flutter 由于渲染的基础（gdi）是自己实现的，所以实现跨平台、性能优化、摆脱平台约束方面的裕度更大。从实际体验来看， Flutter 的性能比 RN 要高不少。
   
   我尝试总结下性能差异的原因以及 Flutter 架构上为“未来”留下的裕度：
   
   运行时语言：从前端的思维来看，jsx 或 dart 都是一种声明式的写法，但 jsx 需要转译（工程上看起来美好的东西肯定是需要在别的方面消耗更多），dart 是直接语言层面支持了 node tree 的书写，且对象创建成本低，可直接编译成 native 代码（AOT），VM 效率更高。运行上应该是 dart 效率高很多。
   
   渲染机制：RN 是从前端思想出发的框架，其在表达复杂 UI 时需要依赖前端“盒子”的深层次叠加嵌套，在 RN 背景下，这每个“盒子”都是一个 native 的 view，这时候就相比 native 开发来说多了很多 view 对象，造成了性能降低。也就是说复杂 UI 需求下，RN 对 UI 的表达效率远低于 native 造成性能低下（Facebook 后来做了一个项目 litho 的亮点就在于打平布局层次，针对性优化我说的布局表达效率低下这一点）。Flutter 是基于 skia (gdi) 层面往上去做的，每个 node/布局是否一定需要是一个 layer 以及 render tree 怎么来划分和实现都有更多灵活性和性能优化的空间，所以能做到性能更优。
   
   组件的兼容性：
   Flutter 提供的 widget 都是基于 skia 来实现和精心定制的，与具体平台没关，所以能保持很高的跨 os 跨 os version 的兼容性。
2. 跨平台
   RN 是一套概念/设计理念跨越两个平台，具体到实际平台上去还要去适配和桥接差异性（这其中有巨大的工程成本和性能牺牲，比如做动画，js 就绝对不能用，用了性能就差了）。Flutter 至少做到了一套代码（不涉及平台 api 层面的 UI 及纯事件响应可以完全一样）。
   Flutter 相对来说是做到了跨平台。RN 更适合称为：将一种设计理念延展到两个平台，不能称其为“一套代码，自动部署多平台”的跨平台方案。
3. 对未来的适应性
   由于 Flutter 从更基础的层去抹平平台差异，Flutter 站在了更宽广、更可控的一个基础平台上去演变和发展。RN 永远需要 follow native 开发的这套约束，桥接和抹平差异乃至应用层去适配的成本、面对具体场景去优化性能所需要的成本都是居高不下的。RN （动态化当然是首要好处，这是这份回答的隐含前提）属于“大公司扛大旗，赚吆喝，小公司跟着复用下现有资源”。
4. 动态化技术的未来
   我个人认为 RN、weex 这类设计都是走不远的，为什么，动态化技术最成熟的就是 H5/Web，真正产业化（标准化、研发支撑、上下游软件开发商、开发者生态）的技术栈还是 H5/Web。所以业界（软件公司、开发团队）对于动态化技术的期待就是 H5，H5 是要由浏览器来支撑的，RN 的能力不到浏览器的 5%（举例 index = 1000，绝对布局，各种动画和复杂布局能力很难用 native 来实现，还有各种布局模型、浮动元素、css rule，不一而足。举例：本人曾经跨 Android、iOS 对等的实现全规范 css 中的渐变色，开发测试花了 2 天，可能还有未知的 bug），RN、Weex 是无法满足这个期望的（面对一个复杂点儿的需求，RN、Weex 都需要 case by case 去 review，还可能需要写 native 代码去扩展才能实现；而 H5 保证了 99% 概率下都是可以实现的。不需要产品/业务将就“技术”）。
   
   对于工程而言，RN、Weex 这类方案最大的价值就是提供了一套让传统前端开发上手 native 开发的途径，同时创建了一个社区用于存放可供复用的组件库，让小公司、小团队能共享这部分“生态”，且能切实实现“命题作文”类的需求。
5. 研发模式
   Dart 语言相关的 vm、debug 以及 hot reload 都是 Google 官方开发和支持的，是其老本行，Flutter 也定位于未来的跨平台的应用框架，更是 Fuchsia OS 的正统 app framework，以上是定位；其次本人跑过 Flutter app 的 demo，研发体验上还是很 “敏捷” 的，实现了现代化框架的 “所改即所得”。
6. 结论：Flutter 从设计、体验、跨平台上都有亮点。值得关注和寄予期望。但目前成熟度有限，不适合商用；不做改造的前提下，不具备动态化能力（release 版本 dart 被编译后再分发）。

畅想 Flutter 如何实现动态化

1. 将 AOT compiler 的能力放到客户端，就跟 android art runtime 下第一次安装 apk 时 aot 编译一次一样，这样 flutter 程序可以以 script 的形式动态分发，同时运行时又能得到 machine code 的性能优势。
   挑战：AOT compiler 很大很重，移植到移动端运行有可能不可行。

2. framework 部分用拥有巨大生态的 JavaScript 等动态语言重写（主要是 widget/layer/renderobject 相关的布局/动画/渲染/语义(aka. 可访问性)计算、任务调度），复用现有 flutter engine（c++ 实现） 部分

挑战：js 写渲染逻辑/动画性能低下，支持灵活的任务调度能力差

flutter 的核心黑科技有哪些

1. dart
   dart 语言对于 flutter 众多功能层面的特性做出了全方位、多角度的支撑，除了生态小不太容易推广外，dart 完美匹配移动端“轻”且“快”的技术要求。

2. 渲染机制
google 由于有 chromium 项目的积累，所以渲染这块是手到擒来。
代码一开篇就把 layer/renderObject/displayList/layout （源于 WebKit ）这一套渲染给熟练的弄过来了。对了，这一套渲染还在 Android 系统上用着。

flutter 的核心不足

1. dart 语言的生态小，精通成本比较高
2. 嵌入外部 platform view 成本高
   这块（基于官方代码）目前在 iOS 端有支持，android 上还没有，但相关开发者博客上有提到实现了 webview//mapview 等 platform view 的嵌入。
   从 iOS 端的实现来看，每嵌入一层 platform view 会额外多一层 surface，内存代价比较高。

3. 平台 API

flutter 目前提供的开箱即用的功能只有 UI framework + dart 语言的能力，平台能力需要通过 platform channel 来扩展。当然这一点也是除了 RN 等其他同类解决方案的通病。