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

作者：hello world
链接：https://www.zhihu.com/question/50156415/answer/280947564

我在过去做过若干年的动态化技术的开发，也写过类似于 RN 的应用框架（但要早于 RN）。简单从几个角度对比下 Flutter & RN/Weex，顺便聊聊动态化技术：

当前几大动态化技术对比

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

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 有一个定律（本质：无处不在、网络效应）很难被其他语言打败：

最后

都说三年是程序员的一个坎，能否晋升或者提高自己的核心竞争力，这几年就十分关键。

技术发展的这么快，从哪些方面开始学习，才能达到高级工程师水平，最后进阶到Android架构师/技术专家？我总结了这 5大块；

我搜集整理过这几年阿里，以及腾讯，字节跳动，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 PDF（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。

Java语言与原理；
大厂，小厂。Android面试先看你熟不熟悉Java语言

高级UI与自定义view；
自定义view，Android开发的基本功。

性能调优；
数据结构算法，设计模式。都是这里面的关键基础和重点需要熟练的。

NDK开发；
未来的方向，高薪必会。

前沿技术；
组件化，热升级，热修复，框架设计

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

我在搭建这些技术框架的时候，还整理了系统的高级进阶教程，会比自己碎片化学习效果强太多，GitHub可见；《Android架构视频+学习笔记》

当然，想要深入学习并掌握这些能力，并不简单。关于如何学习，做程序员这一行什么工作强度大家都懂，但是不管工作多忙，每周也要雷打不动的抽出 2 小时用来学习。

不出半年，你就能看出变化！

.md)**

当然，想要深入学习并掌握这些能力，并不简单。关于如何学习，做程序员这一行什么工作强度大家都懂，但是不管工作多忙，每周也要雷打不动的抽出 2 小时用来学习。

不出半年，你就能看出变化！

标签：Google,Fuchsia,dart,跨平台,Android,RN,Flutter,动态化,native
来源： https://blog.csdn.net/m0_65322636/article/details/122771624