首先感谢@栖冰 @祖建国 一起对FFW的预研做的投入！
背景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呢，定性的从几个角度分析：
FFW在canvas上绘制的组件带有很多MD特色的视觉和动画，比如阴影、Z轴变化等，这部分对性能的消耗要大于普通html标签FFW是通过Dart的DSL转成的dom树结构，转化后的dom树十分复杂，不太可能比手写的dom树更简洁使用canvas的控件，其手势事件的捕获分发都是靠FFW框架自己实现的，emmmm虽然不排除Google大力出奇迹的情况，但是不管怎样，相同素质的开发人员，相同的界面，性能上也不可能优于html+css+js另外一点，如果FFW在原理上涉及大量HTML标签的转化，那就势必会涉及到碎片化的处理中，浏览器的碎片化程度可一点都不比Android系统的碎片化小。像Flutter本身之所以被那么多人看重，就是因为其通过绘图引擎这一层，完美的避开了碎片化，保证一致性。所以最好的平衡就是，只有有限的一部分标准的html标签可以被FFW复用，其必须有几点性质：
标签本身的功能简单又直观最好不要有直接图形化的展示，或者只负责简单的图形化展示（比如画方形）那几个比较典型的标签就是<p>、<div>这种了Flutter官方就是这么做的，所以我的结论是：一致性上大体不会存在问题，性能上，FFW应该不会优于纯手写html标签界面。
官方现状&建议根据官网和Github repo上的说法，我们整理了一下：
Flutter for Web和Flutter目前暂时是两个仓库，官方正在进行合并，没有给出结论。这一点在工程上非常重要，它说明了几个问题：
目前官方对FFW的成熟度没有信心，同时FFW的迭代速度也很快。目前FFW和Flutter最多保证API一样，实现原理差异可能非常大，同时不保证所有控件都已经在FFW上实现。官方不建议应用在生产环境目前插件能力十分有限，和系统交互的一些能力缺失，比如拍照等。性能无法保证，运行会慢，可能会有掉帧FFW中针对桌面的UI部分没有完成（跟我无线有什么关系？）开发中只能在Chrome中调试（又有什么关系？），release版是可以运行在任意浏览器中（除了IE，另支持的最低版本存疑）。实践对于这么新的东西，官网上的内容的确不多，而且简单来看这些问题好像也没什么，所以对于到底能不能用，我们还是需要抱着吃螃蟹的心态具体进去预研一下，为了尽快弄清，我计划找一个我们app已经做好的flutter页面，把它迁移成FFW，对整个迁移过程做个评估，再看下页面效果，基本上就能得出结论了。具体的迁移细节就不提了，官网也有迁移文档，大体上就是这么几个步骤
安装Flutter for Web的工具webdev改SDK依赖，新增Web文件夹(和之前存在的android、ios文件夹同级)，新增一些其他文件(index.html, main.dart等)。将所有flutter代码中依赖的flutter包，改成flutter_web包去掉所有不兼容的代码，比如多语言、路由、Platform.isAndroid等等编译运行实践的主要目的，有以下几个：
对整体坑的深度和广度有个认知，方便推算出填坑成本对FFW整体的性能和体验有个把握，尤其是我们自己的页面跑在FFW上是什么体验。对FFW和JS相互调用有具体的了解，如果可行，那复用集团已有能力（比如mtop）的坑就会小很多
删了一万行代码跑成功之后，最终在工程、开发体验、用户体验上得到一些结论，以下的结论中，体验部分是我在我的mix2s上的感受：
工程支持debug和release模式，后者比前者性能高（差异很明显）。
debug模式支持代码修改后自动重新编译，和其他的前端框架（我只用过Django）一致支持hotreload，暂时没有尝试支持webdev build命令编译出index.html+js，可以通过nginx做反向代理。非常重要 编译出来的代码，gzip压缩前，最简单的helloworld的main.dart.js大小约为500k左右，sample中的gallery大小约为2M，阉割版的纯展示用的订单列表大小约为1.3M。gzip对文本的压缩率一般是80%，压缩后也要动辄几百k的大小。而且main.dart.js不加载完，界面是不会展示的。开发体验非常重要flutter for web使用flutter_web库，且不支持其他许多插件，这会带来几个问题
工程上无法优雅的解决flutter和flutter_web共存的情况，最多搞个dart2的conditional import(这个特性可不在官方文档中哦)依赖flutter sdk的几个库，尤其是多语言库无法应用在flutter_web上，并且Google肯定不会再单独为flutter_web适配，而是在合并时做支持。这就意味着现阶段所有依赖flutter sdk的库不能被flutter_web使用。调试困难
错误日志可以打印到浏览器的console中，但是try catch部分的堆栈不好拿浏览器中的堆栈很复杂，但是基本上能找到出错的dart代码目前没有发现单步调试的能力Platform.isAndroid全部报错，针对Android和iOS做差异化展示目前还不知道有没有其他方法可以做到。目前没有发现控件的api不一致的地方，不过有些控件的行为十分异常，比如下拉刷新，在Android手机上经常卡死、失效。猜测重交互的一些控件都有可能存在类似的问题，但是测一遍的成本太高。图片控件NetworkImage可以直接用，但是现在来看有些糊，不确定是官方控件的问题，还是我们做的cdn url策略有问题。dart代码可以调用js，开发体验和反射类似，并且需要处理JS类型和Dart类型的转换。Dart和JS的交互速度未知。只能说哪怕FFW有很多浏览器的API不支持，也可以通过JS来扩展能力。Dart和Js语言本身的差异会带来测试和兼容成本的增加，虽然Dart可以编译成Js，但是跑在DartVM上的Dart的表现，和其编译成Js运行在浏览器中的表现并不完全相同。比如对于如下代码
Map<String, String> query = null;val b = query["abc"];在DartVM中该代码可以执行，结果是b=null；但是编译成Js以后运行时因为query为null，会报空指针。
用户体验使用了chrome、uc、小米自带浏览器分别试了一下订单列表和官方的sample-gallery界面，体验如下：
加载速度差不多，因为是局域网环境，感知不到差异。非常重要打出的唯一的main.dart.js和部分资源文件（比如MaterialIcons）没有加载出来的时候，界面不会展示。帧率或者流畅度上，chrome > uc >> 小米自带浏览器，其中chrome算是最流畅的体验，但是sample中的一些动画和页面转场也可以看到明显的卡顿。文字展示上，看flutter for web的界面，chrome对大部分文字处理的很清晰，小米自带浏览器看文字明显模糊。对比下面两张图，点开放大之后查看，FFW页面的文字模糊的很明显。
...