43

为什么说 Flutter 不一定是趋势?1544596213805146

 5 years ago
source link: https://mp.weixin.qq.com/s/32e-V9K2-VX97PAYVitUPQ?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

点击上方 开发者技术前线 ”, 选择“置顶或者星标”

你关注的就是我关心的

在 Flutter Live 2018 上,Google 宣布 Flutter 1.0 正式发布。这是一个基于 Dart 的移动开发平台,官方想帮助开发者在 iOS 和 Android 两个平台上开发高质量的原生应用界面。此外,Google 还宣布了 Flutter 运行时基于 Web 的实验性实现,旨在将 Flutter 应用引入标准 Web 浏览器。

V3iy2em.jpg!web

大家 首次看到 Flutter 的 Beta 到 1.0 正式版,总共经过了 9个月。

  • 2 月底在世界移动大会 (MWC) 上发布首个 Beta 版;

  • 5 月的 Google I/O 大会上发布 Beta 3 ;

  • 6 月的 GMTC 发布首个预览版;

  • 9 月的 GDD,发布 预览版 2

  • 12 月 Flutter Live 2018 ,发布1.0 稳定版。

Flutter 1.0 主要聚焦于稳定性和 bug 修复,同时还包含两项新功能的预览 ——  Add to App 和 platform views:

这里也带来了作者(固执的毛毛虫)对 Flutter 的理解:

Flutter 不一定是移动技术发展趋势, 但是大方向对的。

其实我也并不认为 Flutter 一定是移动技术未来的发展趋势,但是可以确定的说,Flutter 的方向是没有问题的。即使它不会是成为下一个跨平台技术,严格意义是UI框架,但也会有一个相似的技术来统治移动平台的发展.

下面来阐述为什么 Flutter 是下一个趋势:

我们回顾移动的发展历史,从11年我开始接触Android 和 iOS 开发的时候,大家用的最多的就是原生开发,

第一阶段技术:原生开发

iAVvMfa.jpg!web

当时的架构都是这种形式,在系统的framework上面不断的开发新的功能

那个年代,开源库也没有现在这么多,所以大家都是出于造轮子的过程。

但这样明显有一个痛点:

就是 Android iOS WP,网页端四分天下的格局,每个公司需要维护四个团队,这样成本很高,所以就有了一个迫切的需求,能否开发一套在多个平台上运行,这样可以大大降低开发成本。

第二阶段的技术:H5

IjENj2U.jpg!web

这个阶段h5兴起,甚至有一段时间大家觉得h5会替代Android原生开发,当时也出现了很多的开源框架来实现H5与底层的交互框架:PhoneGap,Cordova,Ionic,Xamarin

当然这种想法只持续了很短的一段时间,因为虽然在这种架构上有开发成本低,简单,跨平台等很多的优点,但有一个致命的缺点性能问题导致他只能在很少的应用上取得成功。(cordova官方统计,大概只有5%的使用cordove的应用能够取得成功)

这种现象持续了没有多久就有很多公司幻想能不能有一种既能跨平台,性能又高的架构解决这个问题呢?

第三阶段技术:跨平台

6JjIVbm.jpg!web

大家看到这个架构可能一下子就想到了 RN,对,当开发者认识到 H5 是性能的遇到瓶颈问题时,果断的采取了通过原生绘制的方式来实现。这样大大的解决了性能问题。

其实采用这种技术的不止 RN,还有Weex,Luaview ,Picasso(美团) 等等目前的跨平台方案,他们的原理大同小异,只是上层采用的语言不同,中间采用的桥有差异而已,但是整个架构思想是一样的。

当人们满足于这种开发带来的便利的同时,又有了新的问题产生了,就是桥的成本太高,当涉及到频繁的跨桥调用的时候,就会出现性能问题,还有个更严重的问题就是,维护成本也很高,

当人们认为 RN 能节省一半工程师的时候,其实 RN 的维护需要更多的工程师参与进来,

1.RN的整体思想是一处学习到处使用,所以在Android和Ios的使用方式上还是有差异的,而且在开发插件的时候,还是需要开发android ios两套插件,能达到像H5一样,一处编写,到处运行还是有很大的差异的,所以除了android和ios团队外还需要一个团队维护RN,RN架构的维护成本要比android和ios的开发的难度高多了。所以成本比原来还高,还有很多Rn架构本身没有办法结局的问题,对于小团队来说简直就是噩梦。

第四阶段技术方案Flutter

他的整体架构是这样的

ZNBjAvi.jpg!web

它在第三阶段的基础上,增加了一个dart虚拟机,所以减少了桥的交互,所以性能方面会更加优秀,还有一点就是维护上,flutter有Google维护,所以他的插件开发将会更加规范,所以理论上很容易实现跨平台代码复用的情况

UJrUVbb.jpg!web

综上所述:我更倾向于相信Flutter在未来会有一定的发展空间。

但是一个技术能否活下来有很多原因,技术好不一定会火,所以我并不觉得flutter一定会火,但我认为即使不是 flutter 也会有一个类似于 flutter的第四阶段的技术方式来解决目前移动开发的痛点。

Google为甚么会选择 Flutter?

在介绍Flutter之前一定要介绍一下Dart语言。

JBfmeav.jpg!web

Dart 语言我一直觉得是一个生不逢时的才子,从11年出生开始,他的目的就是干掉JS,但是一年过去了,JS各种框架产生,Dart一直在生死线上挣扎,后来没办法,Dart团队意识到取代是不可能的,先让自己活吧,我可以让你写Dart直接转换为Js,这样你可以用我啦吧,毕竟我比js更牛逼啊,但是还是没人用,后来出现了Fuchsia os,主要语言就是dart,没人用,我自己用总可以吧,Google对外宣布数据:

2016年谷歌的AdWords、AdSense和Fiber项目团队开始把Dart融入他们的前端应用开发。一项内部报告表明,Dart可以帮助他们提升25%到100%的前端开发效率。谷歌内部的Dart代码量比去年增长了3.5倍

Google从前端,到新开发的系统,到我们现在接触到的flutter都是使用dart,足以见得,Google对dart的重视。

但换句话来说,只要有一环能够成功,那么整个环路都能活起来。

Google内部有很多团队,这个任何一个都是内部团队互相竞争的一个小产物,未必是 Google 的意图,其实我不反对,但我仍然觉得Flutter 这种技术是移动发展这么多年之后的必然产物,无论 Google 是否做,都会有人来做。但是起的起不来另当别论.

Flutter的弊端

看似  Flutter 如火如荼在大肆宣扬战果,为了加快国内的普及,Flutter团队与闲鱼,头条,和腾讯开始了 推进 Flutter大生态的建设。

目前 Flutter 障碍在于:

  • 性能没有比原生改善

  • 无法支持热更

  • 在iOS普及上有极大的障碍

— — — END — — —

作者:固执的毛毛虫 

原文:https://blog.csdn.net/u010479969/article/details/8088936

开发者技术前线 ,汇集技术前线快讯和关注行业趋势,是开发者经历和成长的优秀指南。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK