为了开始学一个东西前,我习惯性的会先问自己为什么?到底为什么我要开始学Flutter呢?
不确定你是为什么开始学习Flutter,我的直接原因的话是因为我们的项目可能在后面会考虑用Flutter重构,作为目前最新的跨平台方案,它有着它的魅力所在,虽然目前正式版本还没出,但是它的beta版本的效果,让大家都眼前一亮。不过从另外一方面来看,我一直在尝试学习一个跨平台的技术方案,来帮我打通整个前端技术,之前一直考虑学习web或者RN、weex,现在来看感觉从Flutter开始也可能是一个好的开始,因为Flutter的dart语言跟java的一些语法相似,可以帮你对Android有一些了解,同时Android Studio可以作为Flutter的IDE,毕竟Google自家的,可以帮我了解很多安卓相关的知识,同时dart就是为了干掉JS而出生的,所以更有必要看看这个比JS效率更高的语言是怎么个样子了。
Fuchsia
有一个特别值得注意的点,今年也就是18年Google在纽约的开发者大会上,全部会议过程中都没有再提及Android,而是主要聊了ChromeOS和Fuchsia,而Fushsia的UI层就是由Flutter构建的,主要开发语言也是Flutter的开发语言Dart。所以能看到一种潜在的趋势。
Fuchsia 项目的知名参与者包括 Travis Geiselbrecht 和 Brian Swetland。
早在久远的上个世纪九十时代中期,当时的苹果公司因自家的操作系统无法及时推出,正寻找替代品。当时有两个理想的候选产品分别是 Be 公司的多媒体操作系统BeOS,以及被苹果公司扫地出门的乔布斯开办的 NeXT 公司的产品 NeXTSTEP。后来由于 Be 公司要价太高等原因,苹果公司收购了NeXT公司重新获得乔布斯继而研发出后来大放异彩的 OSX,而 Be 公司则由于经营不善在2001年黯然被Palm公司收购。
能被苹果公司列为收购目标的 BeOS 实力自然不弱,而上面这两位小哥,就曾在 Be 公司做操作系统开发。由于 BeOS 在当时来说设计非常先进,公司关门后很多工程师和爱好者觉得可惜,所以继承BeOS的设计重新实现了一个开源系统名字叫 Haiku,Haiku 使用的内核叫做 NewOS。自然地 —— NewOS 的发起人和主力开发就是这俩哥们。
可能俩人对极度精简的产品比较偏爱,又或者是觉得 NewOS 内核的设计还太过厚重,总之,2008 年俩人又针对嵌入式设备设计了一个极其轻巧的内核 littlekernel(简称:lk)。
一晃快20年过去,随着所供职公司的关停并转,他们又分别在Danger、Palm、Android、Apple、Google等巨头公司工作过。Brian Swetland 最近的一份工作是在谷歌任高级软件工程师,负责管理 Linux 内核开发相关事务。几天前,他在 github 上公布了 Fuchsia,用到的内核叫做 Magenta,正是基于他们的 lk 内核项目扩展功能而来。
可以看出来,项目负责人绝对是经验丰富的老司机了。
对比各个阶段的跨平台技术
从宏观上来看,移动互联网兴起也才10年不到的时间,很多人朋友开玩笑说iOS没人要了,Android没人要了,在我看来其实调侃更多一些,本质上这还是一个新兴的平台,从最早期的Native开发持续了1到2年之后,大家都在为了提高效率努力去尝试各种跨平台的方法。我刚开始接触Flutter的第一秒钟就问了我自己一个问题,Flutter到底和之前的方案有什么本质上的不一样?一个一个来看之前方案的原理,自然就会理解了。
1.NativeApp阶段
这个阶段是最初战场,基本上iOS、Android、网页需要3端共同开发,维护自己的原生部分。很自然的暴露出来的问题就是效率问题,虽然保证了各端的稳定性,但是时间成本又是一个问题。
2.WebApp阶段
这个阶段大家尝试了让APP做壳Web做核的方式,一时间各种说法都出来了,说Web要统一3端了,不过是理论分析罢了,都低估了性能的瓶颈问题,大量用户体验的问题反馈了出来,大家又回到了第一战场。
3.RN、weex阶段
当开发者认识到Web 的绘制问题是性能的瓶颈问题时,果断的采取了通过原声绘制的方式来实现。这样大大的解决了性能问题。FaceBook的RN和阿里的Weex都应运而生,它们的原理都相似,只是上层采用的语言不通,中间采用的桥有差异。这类方式在两三年之间,从最初的看似美好已经变成了各家公司已经开始放弃RN退回原生了,原因就在于桥的成本太高,当涉及到复杂跨桥的调用的时候,就会出现性能问题,更严重的问题是我最初没有想到的,那就是即使忽略性能问题的情况下开发成本降低了,但是维护成本缺提高了很多。RN的整体思想是一处学习到处使用,所以在Android和iOS的使用方式上还是有差异的,而且在开发插件的时候,还是需要开发android iOS两套插件,能达到像H5一样,一处编写,到处运行还是有很大的差异的,所以除了android和ios团队外还需要一个团队维护RN,RN架构的维护成本要比android和iOS的开发的难度高多了。所以成本比原来还高,还有很多Rn架构本身没有办法结局的问题,对于小团队来说简直就是噩梦
4.Flutter阶段
和React Native一样,Flutter也提供响应式的视图,Flutter采用不同的方法避免由JavaScript桥接器引起的性能问题,即用名为Dart的程序语言来编译。Dart是用预编译的方式编译多个平台的原生代码,这允许Flutter直接与平台通信,而不需要通过执行上下文切换的JavaScript桥接器。编译为原生代码也可以加快应用程序的启动时间。实际上,Flutter是唯一提供响应式视图而不需要JavaScript桥接器的移动SDK。
从4个阶段的区别已经大概有个基本的了解了,自然会发现从理论上Flutter是"最美"的.但是我自己也特别有疑问,几乎每个阶段大家都会有革命性的感觉,但是在时间的慢慢证明下,很多东西都是有存在的问题的。就我目前对Flutter的了解,我也看到了很多目前阶段要面临的问题。目前来看,大前端目前也还没有"银弹"。
从理论和实际上分析Flutter的优势和需要面对的问题
优势:
1.最大的优势直接与平台通信,从这点让Flutter的性能天花板变成了和Native一样
2.热重载调试功能,Flutter的开发阶段支持这个炫酷的功能,能特别方便的用IDE进行调试,可以不用每次都重新加载,这个是我这段时间写Demo的时候给我眼前一亮的功能,特别好用。修改了代码之后,可以直接热加载在上次调试的基础上,只变动你刚修改的地方。
3.彻底的UI统一一套。你不用再听设计师验收的时候说为什么两端不一样了。(这个不能说是绝对的好处,也影响不是特别大,因为也许很多安卓的用户也不喜欢iOS的界面呢,暂且放进来吧,从效率的角度来分析)
4.Google亲儿子,能保证平台的稳定和后续的质量。
5.RN的性能问题被越来越多的平台重视,也都开始进入重新选择阶段
一些需要面对的问题:
1.之前我看bestswifter提出来的问题是Flutter在git上的issue只增不减,当时看到的issue数量是3848,我目前来看已经到4122了。而反观RN的issue还是维持在600左右,这也能反映出来目前Flutter还非常年轻,还有很多问题需要解决。
2.Flutter目前还在beta,正式版本还没出,暂且把这个放到劣势里面,还有很多不确定性。不过也正因为不确定性,它也有更多的可能性。
3.无法热更新,从目前的beta版本来看,开发环境是JIT模式做动态化,但是release版本是AOT模式的,不支持动态化。不过在Flutter的issue里面有发现该团队已经注意到这个问题,并且分析了理论上热更新的可能性,也许会在正式版本发布这个功能也说不准。
4.包大小问题,因为需要把Flutter的库给放到项目里,所以一定是会增加包的大小了,只是多少的问题。因为安卓原生架构里面包含一些Flutter用到的库,所以相对小一些。iOS的包就会大一些。对于一些小厂来说可能影响不是很大,但是对于大厂来说,确实都有包大小限制。
5.因为Flutter用的是Dart语言,所以也是有学习梯度的,对于iOS开发来说可能相对安卓更陡峭一些,因为dart跟java有些地方很类似所以相对简单一些。不过在这一周来看,我作为一个iOS开发来看,其实还好,万变不离其宗,都是OOP,本质上都一样。这个劣势也能看成自己的一种挑战吧,劣势等级要看你的决心了。
6.生态问题。整个Flutter还是处于非常年轻的状态,虽然Flutter的中文文档非常多,非常详细,但是走和跑是两回事,确实你可以根据Google的官方文档把环境都给搞出来,但是真正到实际开发中你会面对大量问题,到时候是否有一个强大的生态让你去寻找答案,寻找可行的方案。所以这也是一个很重要的问题,毕竟你在快速的业务压力下,是很难容许你去造轮子的,也要看公司给你的资源和空间。当然很多人会说愿意用业余时间去做。这是看上去很美系列,很考验自律能力。
7.如果不是新项目呢?想中间集成一部分Flutter做功能该怎么办呢?这又是一个复杂的问题,后续的文章会讲解这个问题。
8.如果是新项目呢?是的,你可以从新搭建项目了,看上去很愉快。不过也有很长的过渡期,你同时可能还是需要原生iOS开发和安卓开发分散出来一部分精力去跟Flutter开发工程师做对接。当然这是一个始终都要面对的问题,也是不能忽视的问题。
最后
写到现在,我发现我好想写的弊端比优势多,好吧,这些都是我客观分析的点,也不能完全当作弊端,是我们对任何架构都可能需要面对的问题,只不过Flutter还太年轻,让没有接触的同学都害怕了,怕没有人帮你解决你遇到的问题,其实不要怕,没有体验过确实都没有资格完全否定和完全肯定一个东西,所以我也会深入Flutter之后再对它进行更深的评价,后续我会记录下来我的学习过程,给你做一个参考,希望能帮助到你,如果我遇到了难以解决的问题也希望你能给我提供帮助。当然也可能不够全面,后续还会补充,不过Flutter本身的原理就值得我们去探索尝试一下了,未来也许不是Flutter的,但Flutter一定是往前走了一步,而这一步让我们都可能更接近了答案。