Flutter可能真的要亖了？

哈喽，我是老刘

前几天刚发了一篇文章
有人说Flutter马上就要亖了 - 知乎 (zhihu.com)

结果又出了个新闻
突发！谷歌 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 解决了最后的顾虑 - 知乎 (zhihu.com)

这种方案并不理想，会造成用户体验下降
所以主要是作为Flutter突然无法正常使用这种极端场景下的快速应对

中长期方案
前面也说了，Flutter突然无法使用其实是一种极低概率的极端场景
因为即使Flutter被谷歌放弃了，也不会说马上就不能用了
我们使用现有版本的Flutter开发App并发布是不受影响的

所以如果出现Flutter被谷歌放弃，并且没有社区接手这种情况
那么Flutter虽然短期可用，但是长期看会出现bug没法解决，无法适配新版本的操作系统等问题
这种情况下就需要考虑在一个相对比较长的时间窗口内把Flutter替换掉
因为这种情况Flutter开发的App还能正常使用一段时间，所以可以采用逐步替换的方案

我们以替换为原生页面为例：

第一，如果你是纯Flutter开发的App，需要转换为混合开发
混合开发的问题，我在这篇文章里也有提到
Flutter 2 解决了最后的顾虑 - 知乎 (zhihu.com)

第二，把少量核心页面（比如主页）替换为原生页面
为什么先替换主页？
一方面从路由管理来说，大多数页面都是从主页跳转的
主页切换到原生后大部分Flutter页面就相对比较独立了
另一方面主页还承载了很多额外的功能
比如用户打开App后的活动弹窗
那么把这些功能切换回原生后就相当于把很多核心功能也切换到原生了

核心页面切换到原生后可以先发布一个版本看看用户使用有没有问题
因为有些问题仅仅靠测试团队是发现不了的

第三，各个独立页面的切换规划
如果第二步的功能上线后没有太多的问题
就可以安排其它Flutter页面的逐步切换计划了
这时候其实绝大部分Flutter页面都是相对比较独立的
可以一个模块一个模块的排期，同时也不太影响其它项目需求的开发

大家可能觉得这个工作会花费大量的时间和人力
其实如果配合AI，这个时间可以节省很多
通过AI帮助将dart代码转换为原生代码，然后程序员进行细节的微调
当然，测试的工作不能省

好了，前面就是我们为App设计的两套容错方案
这两套方案都是为了应对低概率的事件做的预案
但是衷心希望这些预案都没有被用到的那一天

总结

前面我们分析了Flutter团队裁员带来的可能影响以及不同项目程序员需要做出的应对
我们判断短时间内Flutter仍然是可靠的，并且是客户端开发的最优选择
但是如果真的有黑天鹅事件发生，我们也准备好了应对的预案
我觉得有了这些准备，现阶段是可以放心大胆的继续使用Flutter的

最后，Flutter是我做客户端开发这么多年来用过的最好的框架了，特别是对TDD的支持
衷心的希望Flutter能发展的越来越好

如果看到这里的同学有学习Flutter的兴趣，欢迎联系老刘，我们互相学习。
点击免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。
可以作为Flutter学习的知识地图。
覆盖90%开发场景的《Flutter开发手册》