如何分析网站竞争对手,zenme用ps做网站图,四川建设网官网登录入口,江苏建设工程网背景
Google在最新的Google I/O上推出了Flutter for Web#xff0c;旨在进一步解决一次代码#xff0c;多端运行的问题。Flutter for Web还处于早期试验版#xff0c;官方不建议在生产环境上使用。那么到底它的实际情况怎么样呢#xff1f; 我们做了一次预研。期望这次预研…背景
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大力出奇迹的情况但是不管怎样相同素质的开发人员相同的界面性能上也不可能优于htmlcssjs另外一点如果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.htmljs可以通过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运行在浏览器中的表现并不完全相同。比如对于如下代码 MapString, String query null;
val b query[abc]; 在DartVM中该代码可以执行结果是bnull但是编译成Js以后运行时因为query为null会报空指针。
用户体验
使用了chrome、uc、小米自带浏览器分别试了一下订单列表和官方的sample-gallery界面体验如下
加载速度差不多因为是局域网环境感知不到差异。非常重要打出的唯一的main.dart.js和部分资源文件比如MaterialIcons没有加载出来的时候界面不会展示。帧率或者流畅度上chrome uc 小米自带浏览器其中chrome算是最流畅的体验但是sample中的一些动画和页面转场也可以看到明显的卡顿。文字展示上看flutter for web的界面chrome对大部分文字处理的很清晰小米自带浏览器看文字明显模糊。对比下面两张图点开放大之后查看FFW页面的文字模糊的很明显。iOS的safari和chrome访问demo页TextField整个不可用包括以下问题所有浏览器都不能选中文字复制粘贴。flutter for web应该是以canvas处理展示文字的这样才能解释为啥有的字体size会模糊并且不能选中文字。 软键盘弹出逻辑诡异大部分时候弹出自动缩回小部分时候正常弹出Android这部分表现正常但焦点转移的时候不会自动收回safari不能输入文字chrome可以输入Android这部分表现正常可以选中文字复制和粘贴不生效Android问题相同焦点到TextField的时候界面会自动放大这个时候很难缩放回去Android这部分表现正常
总结
按照上面的整体总结一下Flutter for Web有几个比较严重的问题不解决的话估计是无法应用到生产环境上的 包大小问题这会带来几个问题 FFW的包远大于正常h5的包对流量和页面加载速度都是很大的挑战FFW打成一个JS包多个FFW页面无法对公共组件进行复用进一步造成浪费。FFW的js包不加载完页面无法展示用户体验极差而H5可以渐进加载js可以后入场。 SDK分离的问题这也会带来几个问题 工程上很难优雅的解决两个SDK并存的问题能力上依赖Flutter SDK的官方库比如多语言库不支持FFW SDK。只能自研一套多语言方案。表单场景不要用FFW上述说到的TextField的问题不知能否在应用层去解。一些重交互的组件比如下拉刷新等存在问题几乎无法使用。不确定整体组件的质量情况如何挨个去看成本太大。
结论
没有非常强的业务诉求或者技术推动不要在目前尝试在生产环境使用Flutter for Web。如果有填坑的决心并且舍得投入并且对包大小不关心对帧率等用户体验也不看重可以考虑现阶段进行尝试。我个人判断填坑成本在100人日以上上限未知并且有些坑包大小可能根本填不了。什么时候可以再次跟进我认为在FFW合并进Flutter SDK的时候至于他们具体的规划需要问下Google的人了。
填坑指北
本节的主要目的是列出假设要做FFW我们需要做的技术项和对应方案。 原文链接 本文为云栖社区原创内容未经允许不得转载。
