为了开始学一个东西前，我习惯性的会先问自己为什么？到底为什么我要开始学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阶段

NativeApp阶段.png

这个阶段是最初战场，基本上iOS、Android、网页需要3端共同开发，维护自己的原生部分。很自然的暴露出来的问题就是效率问题，虽然保证了各端的稳定性，但是时间成本又是一个问题。

2.WebApp阶段

webApp.png

这个阶段大家尝试了让APP做壳Web做核的方式，一时间各种说法都出来了，说Web要统一3端了，不过是理论分析罢了，都低估了性能的瓶颈问题，大量用户体验的问题反馈了出来，大家又回到了第一战场。

3.RN、weex阶段

RN&WEEX.png

当开发者认识到Web 的绘制问题是性能的瓶颈问题时，果断的采取了通过原声绘制的方式来实现。这样大大的解决了性能问题。FaceBook的RN和阿里的Weex都应运而生，它们的原理都相似，只是上层采用的语言不通，中间采用的桥有差异。这类方式在两三年之间，从最初的看似美好已经变成了各家公司已经开始放弃RN退回原生了，原因就在于桥的成本太高，当涉及到复杂跨桥的调用的时候，就会出现性能问题，更严重的问题是我最初没有想到的，那就是即使忽略性能问题的情况下开发成本降低了，但是维护成本缺提高了很多。RN的整体思想是一处学习到处使用，所以在Android和iOS的使用方式上还是有差异的，而且在开发插件的时候，还是需要开发android iOS两套插件，能达到像H5一样，一处编写，到处运行还是有很大的差异的，所以除了android和ios团队外还需要一个团队维护RN，RN架构的维护成本要比android和iOS的开发的难度高多了。所以成本比原来还高，还有很多Rn架构本身没有办法结局的问题，对于小团队来说简直就是噩梦

4.Flutter阶段

Flutter.png

和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一定是往前走了一步，而这一步让我们都可能更接近了答案。