Flutter企业级应用开发在闲鱼的落地

2021年7月16日 376点热度 0人点赞 0条评论

本文回顾闲鱼引进应用Flutter的过程，并介绍在使用过程中，我们遇到的一系列问题与困难。

（文章很长，请耐心阅读，我们在文末给大家赠送闲鱼新书《Flutter企业级应用开发实战》）

闲鱼在 2017 年便引入了 Flutter，是国内第一个引进Flutter的团队。

当时的 Flutter 还远未成熟，行业内也没有把 Flutter 放入已有工程体系进行开发的先例。

这两年，Flutter 也逐渐在其他企业里落地，但同时也不断有质疑的声音发出。甚至有传言表示“闲鱼的新业务已经放弃 Flutter”、“相信闲鱼遇到了很大的难题”......

那么，作为 Flutter 先驱和探路者，闲鱼在过去几年的摸索过程中遇到过什么阻力？踩过什么“坑”？对于相关技术开源的态度是怎样的？对于以上的一些传言又是怎么看待的呢？

针对这些疑问，闲鱼代表团队分享了一些开发者背后不为人知的小故事。希望能让大家从背后人的维度去看闲鱼团队，理解他们的初心，以及这个过程中遇到的挑战、挣扎、付出的努力、得到的教训。

在新技术落地过程中，遇到过什么阻力，有什么避免”踩坑“的经验？

闲鱼从2017 年开始接触Flutter，最初是一个自上而下的尝试。

一方面，从创新团队的角度来看，需要以战养战，为团队储备更多的人才；

另一方面，希望切实解决当时团队人难招、产能低的问题。

▐ 调研过程

在前期的调研过程中，最初是希望将Flutter 作为闲鱼国际化版本的主要技术选型；由于后续业务上的决策，导致该项目夭折，因此希望将Flutter 引入主App 中进行探索。

在尝试之初，从组织、配套工具，到架构侧都没有准备得特别好，项目落地面临很多困难。在团队抽调的突击小组中，有大量的研发人员非常不看好这项技术，大部分研发人员并不认同Flutter，没人知道这件事情该怎么做。

当然，从2017 年开始，闲鱼在多个技术方向都进行了类似的尝试，实践证明，创新的确比想象难得多。

时间来到2020 年，回首过去尝试的多个方向，目前只有Flutter 得到了阶段性的胜利，并作为闲鱼的技术品牌为大家广泛熟知。这里面所经历的艰难险阻只有当时参与过从0 到1 过程的研发人员才能体会。

由于Flutter 落地过程的艰辛，其间也有不少同事离开了闲鱼，幸好后续有更多希望这件事情成功的研发人员加入，大家一起努力至今，才有了今天看到的成果。我们也非常感谢在此过程中付出过努力的每一位同事，不管今天他们是否还在闲鱼，是每一位同事的努力让美好终于发生。

从Flutter 落地的过程中总结出以下观点，供大家参考。

▐ 从布道者的角度来看

需解决以下两方面的问题：向上，需要得到更多决策者的支持；向下，需要减少开发者进入的成本。

▐ 关于决策者链路

Flutter 在闲鱼落地的过程中没有上层的阻力，因为开始是一个自上而下的决策，但在后续的推广和落地过程中，从更大的组织视角去看，比如构建AliFlutter 组织、构建Flutter China 组织，这些是一个自下而上的行为。

在这个过程中，闲鱼选择的是“农村包围城市”的理念。

先从社区出发，发现同路人，找到不同公司、不同业务的价值，再回归内部，影响决策者。前期不管是构建集团Flutter 的兴趣小组，还是正式有了AliFlutter 的虚拟组织，都是找到同路人，探讨和争论其技术价值的过程，这个过程可以请各团队的关键决策者躬身入局。通过讨论又能帮助团队进行更深入的思考，并为Flutter 提供一个阶段性的明确定位——面向研发效能提升，构建新的研发模式，快速支持小前台业务落地。将该目标与阿里巴巴集团大的研发效能目标进行连接和推动，即可顺利地推进该项目。

▐ 关于开发者成本

首先是自己团队的开发者成本。在任何新技术落地的前期，都有一定的成本，需要度过这个阶段才能得到收益。因此，在开始阶段，必须尽量降低落地成本。

在项目之初，最好以小规模团队的形式进行尝试，同时新技术在前期架构落地中需要重点考虑过渡阶段的效率问题，不要断崖式地迁移。闲鱼在初期没有充分考虑这个问题，导致工程侧开始的架构并不合理。后来，闲鱼重点围绕混合架构，以Flutter 开发小组与原生开发小组的协作模式进行设计和落地后，该问题得到了有效解决。

例如，前期闲鱼就重点解决了原生项目无法独立打包的问题，极大地解决了当时研发效率的阻塞问题。混合栈（Flutter Boost）的重新设计，也解决了当时由于Flutter和原生生命周期不一致带来的一系列复杂问题，保证了开发调试的稳定性。如果团队仍有余力，可以考虑对开源社区进行一些力所能及的输出。闲鱼先通过发布文章，再通过部分开源项目以及内部开源的形式，给Flutter 社区和阿里巴巴集团提供了一些帮助。闲鱼相信“日拱一卒，功不唐捐”，虽然依然还有很多问题需要解决，但是随着更多开发者的进入，大量的问题终究会被解决。

在闲鱼对开源项目的态度是什么？未来会把大量文章中提到的技术开源出来吗？

闲鱼在2018 年完成Flutter 主链路的部分改造后，发现在落地过程中有很多问题，而且Flutter 社区并没有给出很好的解决方案。

从帮助Flutter 社区其他开发者的角度出发，闲鱼内部开始讨论开源事宜，这是闲鱼第一次尝试开源，所有人都没有经验。大家开开心心地希望能将自己做的一些事情同社区进行交流。

当然，作为第一次开源，很多事情做得也非常糟糕，糟糕的文档、糟糕的Demo、没有测试用例、问题维护不及时、没有好的社区共建方式，于是引发了社区开发者的大量抱怨。

从自己真实的感受来说，要维护好社区项目，需要付出大量的精力和时间，这些甚至需要不少同事全职去做，这对一个业务团队来说有些勉为其难。

对开源的反思是要敬畏开源，敬畏社区，在反馈中不断地成长，完善自身项目。例如，Flutter Boost 前期的设计在兼容性上侵入性太强，导致后续的升级成本较高。在未来的3.0 版本中，闲鱼会主动解决这一问题，减少关键的几个类的继承和重写，简化概念，降低接入成本。

目前，这个阶段会重点关注已经开源的项目，尤其是Flutter Boost 这种在阿里巴巴集团内外都属于开发者刚需的项目，需要持续地维护，也非常欢迎更多的社区开发者参与进来。

关于文章中提到的其他Flutter 相关技术，闲鱼会尽量考虑使用Demo 等形式将部分原理输出，帮助开发者更好地理解文章及其背后的思想。

一方面保证了闲鱼对Flutter 社区的启发和帮助，另一方面也缓解了闲鱼目前面临的无法保证全职人员从事开源工作的问题。但不论如何，闲鱼希望通过文章及代码，持续地帮助Flutter 社区，尽我们的一份绵薄之力。

也许我们做得并不完美，甚至不够优秀，但随着闲鱼有更多优秀研发人员的加入，在创新和分享文化方面进行不断的自我革新，相信总有一天能伴随这项技术成为真正的国民级别应用的贡献者。

听说闲鱼放弃了Flutter，作为当事人，闲鱼的态度是什么？

在各类社交平台匿名区和公众号中，都有人阶段性地、煞有介事地散播闲鱼放弃了Flutter 以及未来不会再投入的消息，作为当事人，我先说结论——这些都是谣言！

《Flutter企业级开发应用实战：闲鱼技术演进与创新》一书的出版是对这些谣言最有力的反驳，也感谢出版社帮我们辟谣。

移动互联网发展的十年，对于跨平台技术来说，从最早的PhoneGap 到ReactNative、Weex，再到目前的Flutter，形形色色的技术不断迭代和演进。

从当前阶段来看，Flutter 具备跨平台技术的先驱——QT 的大部分优势，且配套了更现代的语言、更合理的分层架构，并有Google 公司支持，是新一代跨平台技术的集大成者。

在下一个十年，面向万物互联的新操作系统，如华为鸿蒙及Google Fuchsia 的出现，使得跨平台技术的价值进一步凸显。

因此，学习这项开源技术对未来的开发者来说是一个不错的选择。我们无法预测Flutter 是否一定为下一个十年的主流技术，但这套代码和其背后的思想一定能给未来的开发者以启发，就像我们的前辈用QT 开发了KDE，KDE 又提供了一个排版引擎KHTML，而苹果公司Fork 了这个项目，从而产生了WebKit，而Google 又Fork 了WebKit，从而产生了Blink。

这些令人尊敬的公司和开发者站在巨人的肩膀上不断地努力，最终打造了令人耳熟能详的技术，从而改变世界。

今天，Flutter 代码中有很多概念也存在浏览器内核的一些影子。作为客户端的从业者，希望开发者都能客观地评价这些技术，根据实际情况进行学习并将其落地。

对于外界传出的类似闲鱼放弃Flutter 的谣言，大部分时间我们选择付之一笑。

作为管理者，我不太希望团队过于关注外部的评价和过度回应不实传闻，希望闲鱼的开发者可以做正确的事情，并保持长期的耐心。

未来的三年，闲鱼更希望探索先进的研发模式，帮助整个阿里巴巴集团在商业竞争中保持技术的先进性和成本优势。当然，我们希望这种研发模式是基于我们现有的技术沉淀基础之上的，因此会依然持续地投入Flutter 之中。

同时，作为一个创新团队，闲鱼也一定会持续地关注行业的最新动态，未来也一定会像在Flutter 领域一样，在其他领域有所建树。