Flutter for Web 详细预研

背景

Google在最新的Google I/O上推出了Flutter for Web，旨在进一步解决一次代码，多端运行的问题。Flutter for Web还处于早期试验版，官方不建议在生产环境上使用。那么到底它的实际情况怎么样呢？ 我们做了一次预研。期望这次预研的结果可以帮你决定是用，还是不用FFW。

Flutter for Web原理

Flutter for Web和Flutter在上层都是Dart环境，两者不同的是，Flutter的Dart代码运行在Dart虚拟机中，界面由Flutter引擎处理，通过Skia绘图引擎经由GPU绘制到屏幕上。而Flutter for Web的Dart代码编译成JavaScript，界面上部分转换成标准的html标签，部分转换成通过Canvas绘制的自定义标签，最终构成一个dom树。
这个原理上的差异非常重要，这直接可以让我们通过原理得出下面的结论：

Flutter for Web的一致性和体验上存在矛盾

如果Flutter for Web追求（和Flutter）完美的一致性，势必需要大量使用Canvas去绘制，而Canvas去绘制组件的性能（尤其在移动端）至少不会比html标签好。如果FFW追求性能极限而使用大量标准的html标签，这就会带来和Weex、RN等一样的一致性问题：对于Flutter所有的控件都是一套代码在绘图引擎上绘制，对Flutter for Web如果要使用大量html标签，那如何保证一致性呢？只能靠大量精细的打磨工作了。所以FFW必须要处理好这个平衡。

为啥使用canvas绘制性能不优于手写html呢，定性的从几个角度分析：

1. FFW在canvas上绘制的组件带有很多MD特色的视觉和动画，比如阴影、Z轴变化等，这部分对性能的消耗要大于普通html标签
2. FFW是通过Dart的DSL转成的dom树结构，转化后的dom树十分复杂，不太可能比手写的dom树更简洁
3. 使用canvas的控件，其手势事件的捕获分发都是靠FFW框架自己实现的，emmmm
   虽然不排除Google大力出奇迹的情况，但是不管怎样，相同素质的开发人员，相同的界面，性能上也不可能优于html+css+js

另外一点，如果FFW在原理上涉及大量HTML标签的转化，那就势必会涉及到碎片化的处理中，浏览器的碎片化程度可一点都不比Android系统的碎片化小。像Flutter本身之所以被那么多人看重，就是因为其通过绘图引擎这一层，完美的避开了碎片化，保证一致性。
所以最好的平衡就是，只有有