前端的形式越来越多，在大前端的时代中，既有基于传统web开发的Vue.js，React，Angular等框架，又有基于移动端跨平台的React Native，Flutter，Ionic，也有基于跨小程序的uniapp和taro等，还有使用前端写桌面应用的electron。那为什么会出现这么多框架呢？以及这么多众多的框架的出现是为了解决什么问题呢？不同的框架之中，又有什么异同点呢？
如何将web代码渲染成flutter
前端好多技术栈，对于移动端有Web，又有小程序，React Native，又有Weex，现在冒出来的flutter又是什么东西？
心中：学不完了
那么这么多不同的框架有着什么的特点呢？在下面的表中我们给出了一个横向的对比。
| 特性 | Webview | Native | Js+Native | 自绘 |
|---|---|---|---|---|
| 代表引擎、框架 | WebKit、Blink | IOS、Android | RN、Weex | Flutter |
| 性能 | ★ | ★★★ | ★★ | ★★★ |
| 渲染一致性 | ★★ | ★ | ★ | ★★★ |
| 开发成本 | 👴 | 👴👴 | 👴 | 👴 |
| 上手难度 | easy | hard | middle | middle |
什么是自绘
在上面的表格中有一个自绘，那么什么是自绘呢？
自绘也就是自带渲染引擎，客户端只需要提供一个画布就可以从业务逻辑到功能呈现的多端高度一致的渲染体验。例如在移动端有Flutter和QT mobile。但QT mobile远远没有Flutter人气高。
我们传统的web开发采用的WebView进行HTML5页面渲染，但是一个完整的HTML5页面的渲染需要经过浏览器控件的加载、解析、渲染三大过程，因此性能也要比原生开发低上不少。这不仅仅体现在移动端，也体现在PC端。最近大量的electron出现，但是他的实际体验上要远远落于C++的QT以及Java的swing。因为基于Html的开发虽然快，但是性能却成为了一个大问题。
由于传统的webview在手机上体验不佳，因此出现了React Native，Weex等框架，通过这些框架，我们可以采用类Web标准进行开发，但是在运行的时候把绘制和渲染交给原生系统接管的技术。这样既做到了跨平台的支持，又可以借助前端快速开发的能力。
那么自绘有什么的优势呢？首先，由于是采用的自绘引擎，所以无论是在IOS上还是Android上，都会有一个统一的渲染。然后，由于我们是基于flutter来开发，就不用像antd开发组件库一样需要为react，vue和angular来开发一套自己的组件库，只需要开发一套。最后，他可以为我们开发提效，相对于原生开发来说，我们可以使用类似于web开发的方式来快速的开发跨端应用，不用分别为两个平台进行开发。
什么是flutter
Flutter是谷歌的移动UI框架，可以快速在iOS和Android上构建高质量的原生用户界面。 Flutter可以与现有的代码一起工作。在全世界，Flutter正在被越来越多的开发者和组织使用，并且Flutter是完全免费、开源的。
Flutter是自绘引擎的代表，他从头到尾重新写了一套跨平台的UI框架，渲染引擎采用Skia图形库，开发语言采用Dart。由于采用的自绘引擎，因此比HTML5拥有更强大的性能，并且相对于移动原生开发拥有更快的开发速度。
为什么选择flutter
- 因为他使用Dart，既支持JIT，又支持AOT
- 基于SKIA，自绘引擎效率高
- 项目十分活跃，版本一直在迭代
- 社区活跃，有许多相关的文章
- 大量的大公司采用，有大公司先行踩坑
- 响应式开发，对命令式开发的挑战。
前端💗Flutter
那既然Flutter这么好，为什么提出web on flutter，不直接开发Flutter，而是要从web转成flutter呢？因为flutter和web的解析流程与渲染流程十分的相似，前端渲染中会生成cssom和dom树，然后一起构建渲染树。flutter也是widget树。所以既然这么相似，如果我们通过一个桥梁，让我们相互转移过去转移过来，我们岂不是只用写一份代码，就不用写另外一套代码了呢？
例如现在社区中有这些方案：MXflutter，WFlutter，Kraken，Unicom，大部分都是由Js转移向Dart。
web on flutter实现的原理：
CSS样式的映射：
为什么阿里会推行Flutter呢
阿里之所以会推行Flutter，是为了能更好的统一阿里前端的标准。阿里部门特别的多，所以如果每个部门都采用不同的方案，就会有千千万万种方案。所以为了推进阿里经济体的前端容器标准化，统一容器的标准，减轻开发者的统一三端的能力。
如何实现跨栈的标准化研发模式
为什么我们需要跨端方案
为什么我们需要跨端方案呢？就以小程序来说吧。自从微信小程序做成之后，各大平台纷纷开始制定自己的小程序方案，例如支付宝小程序，QQ小程序，以及各个手机厂家联合制定的快应用标准。包括最近IOS14的发布，也是支持了和google play一样的instant应用的体验。就算你没有尝试去使用小程序，实际上小程序还是在不断的侵入你。例如以前常用的QQ投票功能，淘宝的客服功能，也都独立了出来，改成了小程序的架构。例如你想把你自己的应用分别发布在各个小程序平台上，那必须按照相关的小程序的文档来重新写一遍自己的程序。但实际上容器不只是有小程序，还有HTML5原生，React Native/Weex，以及Flutter。渴望的，我们需要一次编写多端投放的能力，这个时候我们无异是需要一个方案来磨平各大小程序以及混合应用的差异。
阿里巴巴中Rax的出现
React + Weex = Rax
为什么要做Rax，而不是去使用Weex呢？
因为希望在现有的技术栈上继续开发，使用react；希望更小的包大小；希望有更大的性能以及开发难度。于是Rax便孕育而生了。在上面的要求下产生出来的Rax是跨端的，是轻量的，是开箱即用的。
他经过了淘宝的大量实践，产生于淘宝，并运用于淘宝。
Rax的设计思路：
整体的思路就是希望开发者不需要去过度关注Rax的下层容器是什么，而只需要在基于Jsx的Rax去编写程序逻辑。
为什么Rax使用VDOM呢，使用VDOM带来了什么收益？
因为使用VDOM，我们可以有一个统一的数据结构。我们只需要一个纯函数，就可以将我们的数据映射到我们的UI上。其次，使用VDOM可以于容器渲染解耦，达到了跨端的能力。
Karken
karken是淘系技术部前端架构团队开发的一个基于Flutter的动态化框架，可以直接对接前端的生态，并且有成熟的调试方案，可以进行实时的JS断点调试，支持sourceMap以及热重载的能力。
在浏览器中，光栅化是异步进行的，进行惯性滚动时，会出现白屏，这个是 WebView 始终无法避免的问题。而借助 Flutter 足够高效的同步光栅化实现，Kraken 可以做到长列表快速滚动不白屏。
karken with cloud
云是未来的趋势。例如现在的云服务，云函数，以及各大游戏公司在云上的探索，都说明了未来的世界是寄存在云端上的。
karken也在云渲染上做出了架构设计。将应用分离为客户端和服务端，通信使用WebSocket和WebRTC。简单来说在服务器上渲染之后，以视频流的形式传送给客户端。客户端捕获用户的操作，传送给服务端。如果网络达到了足够高的水平，就可以流畅的使用未来的新架构。这个和现在浏览器渲染是不一样的。浏览器渲染仍然是大量倚靠客户端的性能，而云渲染是将视频流发送给客户端，性能消耗就会很小。
云端一体化是未来渲染技术的新趋势。kraken不仅仅是为用户带来了一个新的渲染引擎，更是为用户带来了一个可控的内核，更彻底的自定义。可以将自己的UI写在自定义的渲染引擎中，极致的提升用户体验。
页尾
前端早早聊大会，目标成为用得上、听得懂、抄得走的技术大会，与掘金联合举办，每年 >= 16 期
2021 年票双十一预售，报名戳：huodongxing.com/go/2021
12 月 26 日/第十八届-前端搞性能优化，报名戳：huodongxing.com/go/tl18
全年所有场次（含未举办场次）联票上车，报名戳：www.huodongxing.com/go/zao-bonu…
