如何评价-Google-的-Fuchsia、Android、iOS-跨平台应用框架-Flutter

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 的线上实践，可以参看：

GMTC-闲鱼Flutter实践效果访谈​mp.weixin.qq.com

目前闲鱼的实践中是拿到了 flutter 在性能、开发效率方面的好处，但是降低包体积、动态化还没有实现。

畅想 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 语言的生态小，精通成本比较高
   dart vs javascript，javascript 有一个定律（本质：无处不在、网络效应）很难被其他语言打败：

如果某个软件能用 javascript 实现，那么最终它一定会用 javascript 实现。

说到 dart 这个舶来品，在国内更是难以推动，typescript 之于 javascript 算是同门师兄弟，相对迁移难度不高，但 dart 之于 javascript 语法和概念上差异巨大，再加上英文
文档、社区、样例代码的缺乏，在国内基本上没有流行的希望。

结论：要想在国内速成蔚然成风的环境下流行的技术，必须是像 thinkphp 这样全中文文档，样例代码丰富，论坛 24h oncall 的技术，简言之要像柳永的词：“人人皆能歌柳词”。

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

3. 平台 API

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

注： flutter 被 google 定位于跨平台、跨环境的应用开发框架，单一从动态化框架的角度去评价和衡量也有点牵强。

4. 兼容性 & 完备性

使用 Surface 这种平台级重量资源，[Android平台]其申请释放都是异步的，很可能有很多的兼容性问题。同时粒度上无法让已有 native view 作为 host（比如 ListView），一个小的 flutter 放进去做个 cell，并且彼此之间复用。此处完备性定义为：普适各种使用场景

未来的动态化技术

不论是 RN 还是 Flutter、Weex 都只能解决一部分问题，世界上成熟的产业级标准只有 Web 和 Native，所以站在 RN Flutter Weex 不能通吃所有场景所有需求的这个前提下，讨论下什么样的动态化技术能走得更远，生命力更长久：

1. 设计和实现简单轻量
   设计和实现简单、轻量的东西才经得起迭代和扩展，才有生命力
   平台原生的一定是最好的，不要拒绝它，要拥抱它

核心两件事：
1.1 轻量级桥接 JS，实现跨端复用代码，开发队伍上让前端同学能介入，同时也是应用能动态性（分发）的基础
1.2 跨平台统一抽象应用框架、组件、模块、扩展机制…，抹平平台差异

2. 定位于补充 web，而不是取代 web
   定位大了，搞不赢浏览器，同时会把自己拖死
   定位大了，每个点上都没有超常的亮点，靠覆盖面取胜的东西最终胜不了

3. 定位于补充 web，而不是取代 web
   定位大了，搞不赢浏览器，同时会把自己拖死
   定位大了，每个点上都没有超常的亮点，靠覆盖面取胜的东西最终胜不了