Flutter大概真的要亖了？

哈喽，我是老刘
前几天刚发了一篇文章
有人说Flutter立刻就要亖了 - 知乎 ()

结果又出了个消息
突发！谷歌 Python 团队全体被裁，Flutter 团队也“在灾难逃” (qq.com)

如果你问我，看了消息后前一篇文章内里的观点是不是有厘革
我以为有一点，但不多
消息说了啥？

1、谷歌母公司Alphabet第一季度营收同比增长15%，但是公司的重心转移到AI上面了
2、Python团队裁掉
不外似乎在德国重新组建团队了
我以为这个比Flutter裁人影响大，Python以后会怎么样不确定啊
3、Flutter团队也受裁人影响

文中的意思是Flutter团队裁掉了很多开辟，不是整个团队裁掉
但纵然云云，Flutter的未来仍旧会受到很大的影响
对Flutter的影响有哪些？

1、官方后续的投入力度不确定

我们知道Flutter相对于别的跨平台开辟框架，一个很大的上风就是官方的投入力度
从下一代渲染引擎Impeller云云快的进入可用状态就能看出来
那么后续官方的投入力度大概会有所淘汰
这种影响大概率是先影响到PC、web端的，Android和iOS大概会少一点
但是详细对手机端有多大影响，还须要继续观望
可以看一下5月14号的Google I/O大会，应该会有所端倪
2、谷歌放弃Flutter的大概性并没有增长

Flutter是谷歌投入大量资源打造的项目
如今已经取得了很大的希望，是跨平台范畴的老大
以是不消担心会像很多谷歌的实验项目一样对待
如今Google内部已经在移动、Web和桌面平台上摆设了Flutter应用，包罗“Nearby Share”、Play管理中心应用、Google Cloud移动应用和Google讲堂训练集
而本次谷歌裁人着实从另一个侧面也证实了放弃Flutter的大概性不大
如果是不紧张的实验项目，大概就直接团文体掉了
大概像Python团队那样，在低本钱的地方重新搭建
但是Flutter的核心团队并没有大的变动
分析至少在中短期内Flutter的定位还没有厘革
谷歌应该不会放弃Flutter
对开辟者有哪些影响？

各人大概最关心的还是这件事对我们开辟者的影响
我的观点有两个：
1、Flutter仍旧是跨平台的最优选择
2、长周期、大用户量项目做好容错规划
1、Flutter仍旧是跨平台的最优选择

如果你的项目正在思量跨平台开辟
那么不要受这些无关信息的干扰
可以优先选择Flutter作为项目的核心技能栈
由于如今在跨平台范畴，没有比Flutter更好的选择
起首，性能方面的领先
这方面就不睁开讨论了
简单来说Flutter性能黑白常靠近原生的
而RN、Uniapp这种基于JS中心层的跨平台方案在性能上都有较大的丧失
其次，在开辟体验方面的领先
Flutter由于其自带渲染引擎的架构筹划
如今已经发展成一个完备且美满的开辟框架
就开辟框架本身的美满程度来说，很多地方乃至比原生要有上风
比如单元测试、热重载
在这方面RN、Uniapp着实都有较大差距
之前一个朋侪就遇到很实际的题目

而性能方面没有短板的Qt，开辟体验大概要更差一点
2、长周期、大用户量项目做好容错规划

为什么要限定长周期、大用户量项目？
由于3~5年以内生命周期的项目，着实不消思量太多
一方面Flutter大概率能活到谁人时间
另一方面，纵然Flutter被谷歌放弃了，也不是立刻就不能用了
你通过Flutter开辟的App仍旧可以正常的上架发布、更新
只不外谷歌后续不会继续更新而已
而且另有很大的大概谷歌放弃社区接办
但是对于长周期、大用户量的项目，确实要做好容错的规划
比如我们团队的项目
预计未来10年都还在
如今的月活是3000万以上（也不算大用户量哈）
而我们的代码50%以上都是Flutter开辟的
那么不但仅是对Flutter，对我们全部接纳的技能方案来说
都须要思量黑天鹅事故发生后的容错
怎样容错？
这里所说的容错不是说如果Flutter不能用了你的项目不受任何影响
这是无法做到的
纵然能做到，我以为为了小概率事故付出如许的本钱也是不划算的
这里说的容错紧张是指黑天鹅事故发生后的应对方案
针对Flutter来说，我们创建了两套应对方案
短期方案
短期方案是指如果Flutter忽然不可用了怎样应对
核心头脑是使用Flutter工具链支持将Flutter代码编译为JS代码的功能
当出现使用Flutter开辟的App无法正常发布、运行等场景时
我们可以使用Flutter工具链，将Flutter开辟的页面转换为web页面
然后使用App中内嵌webview的方式举行快速降级
固然另有一些条件，我们的App是肴杂开辟，而且已经有少量页面使用H5展示
详细的办理方案我在下面这篇文章内里有分析
Flutter 2 办理了末了的顾虑 - 知乎 ()

这种方案并不抱负，会造成用户体验降落
以是紧张是作为Flutter忽然无法正常使用这种极度场景下的快速应对
中长期方案
前面也说了，Flutter忽然无法使用着实是一种极低概率的极度场景
由于纵然Flutter被谷歌放弃了，也不会说立刻就不能用了
我们使用现有版本的Flutter开辟App并发布是不受影响的
以是如果出现Flutter被谷歌放弃，而且没有社区接办这种情况
那么Flutter固然短期可用，但是长期看会出现bug没法办理，无法适配新版本的操纵体系等题目
这种情况下就须要思量在一个相对比力长的时间窗口内把Flutter更换掉
由于这种情况Flutter开辟的App还能正常使用一段时间，以是可以接纳徐徐更换的方案
我们以更换为原生页面为例：
第一，如果你是纯Flutter开辟的App，须要转换为肴杂开辟
肴杂开辟的题目，我在这篇文章里也有提到
Flutter 2 办理了末了的顾虑 - 知乎 ()

第二，把少量核心页面（比如主页）更换为原生页面
为什么先更换主页？
一方面从路由管理来说，大多数页面都是从主页跳转的
主页切换到原生后大部分Flutter页面就相对比力独立了
另一方面主页还承载了很多额外的功能
比如用户打开App后的活动弹窗
那么把这些功能切换回原生后就相称于把很多核心功能也切换到原生了
核心页面切换到原生后可以先发布一个版本看看用户使用有没有题目
由于有些题目仅仅靠测试团队是发现不了的
第三，各个独立页面的切换规划
如果第二步的功能上线后没有太多的题目
就可以安排别的Flutter页面的徐徐切换筹划了
这时间着实绝大部分Flutter页面都是相对比力独立的
可以一个模块一个模块的排期，同时也不太影响别的项目需求的开辟
各人大概以为这个工作会泯灭大量的时间和人力
着实如果共同AI，这个时间可以节流很多
通过AI资助将dart代码转换为原生代码，然后步调员举行细节的微调
固然，测试的工作不能省
好了，前面就是我们为App筹划的两套容错方案
这两套方案都是为了应对低概率的事故做的预案
但是衷心盼望这些预案都没有被用到的那一天
总结

前面我们分析了Flutter团队裁人带来的大概影响以及差异项目步调员须要做出的应对
我们判断短时间内Flutter仍旧是可靠的，而且是客户端开辟的最优选择
但是如果真的有黑天鹅事故发生，我们也准备好了应对的预案
我以为有了这些准备，现阶段是可以放心大胆的继续使用Flutter的
末了，Flutter是我做客户端开辟这么多年来用过的最好的框架了，特殊是对TDD的支持
衷心的盼望Flutter能发展的越来越好
如果看到这里的同砚有学习Flutter的爱好，欢欢迎洽老刘，我们相互学习。
点击免费领老刘整理的《Flutter开辟手册》，覆盖90%应用开辟场景。
可以作为Flutter学习的知识舆图。
覆盖90%开辟场景的《Flutter开辟手册》