Flutter 作为革命性的跨终端解决方案 ， 于 2018 年 12 月正式发布 ， 仅用了不到一年的时间就在 GitHub 和 StackOverflow 上获得了比 React Native 更高的知名度 。那么所有项目都应该使用 Flutter 吗？并非如此 。没有最好的框架 ， 只有最适合的框架 。是什么原因让闲鱼选择了 Flutter？闲鱼在架构 Flutter 化这方面有着怎样的经验与挑战呢？带着这些问题 ， InfoQ 采访人员采访了 GMTC 专题出品人于佳（宗心） ， 以下为采访实录 。迎接大前端时代手淘客户端架构升级我从 14 年开始参与手机淘宝的研发体系的升级 ， 彼时正值淘宝 all in 无线的时期 ， 大量研发人员涌入客户端进行开发工作 。开发人员变多了 ， 也带来了一个问题：当一百名以上的同学开出对应数量的分支进行研发时 ， 在协同效率上出现了巨大的瓶颈 ， 代码冲突十分严重 ， 解决冲突的成本也着实难以承担 。
手淘架构组临危受命 ， 在没有任何业界先例的情况下 ， 通过对比服务端的解决方案找到了工程拆分的解决方法——模块化 。具体的方案是设计一个类似 Spring IoC 能力的轻量级容器 ， 以保证各模块间的通信机制及接口调用标准 。这样做的好处是：
各个模块通过接口的形式进行能力的对外暴露；
在集成阶段通过二进制包的方式保证了 App 整包的编译效率和各业务线的代码隔离 。
这个方案极大的减少了集成的成本 ， 也为后续手淘的快速迭代提供了保障 ， 正因如此 ， 这套基础架构的方案一直沿用至今 。在前端急速发展的今天 ， 端侧工程拆分也仍是大型客户端上常见的方法 ， 同时对行业也有明显的借鉴意义 。
天猫移动端架构合并而淘宝和天猫的移动端架构合并则是手淘架构升级之后的事情了 。有一天主管找到我并提出要基于手淘的新架构帮助手机天猫进行研发体系升级 ， 进行一些底层能力的整合 ， 诸如网关、H5 容器等一系列端侧中间件标准 。
如果说之前在手淘架构升级的过程中我的角色是执行者 ， 那么这次的角色就有了很大的变化 。一方面要修改代码 ， 另一方面还要进行技术布道 ， 同时还要说服一线开发和对方的主管 ， 不单单是对技术与代码的执行者 。外派的近一年时间中 ， 我作为横向推动两个大的 BU 做架构整合的人 ， 为了手机天猫的研发体系可以顺利升级 ， 经历了很多不为人知的艰辛 。虽然过程十分曲折 ， 但结果是好的 ， 最后我和同事一起完成了架构的合并 。自此 ， 手淘正式成为移动中台开始对集团输出能力 。
闲鱼是在什么时候决定采用 Flutter 的？在此之前闲鱼 App 的客户端技术选型是怎样的？2014 年 ， 集团内部孵化了闲鱼这个创业项目 ， 次年我加入了闲鱼团队 。当时的闲鱼人力非常有限 ， 很多基本的用户体验问题都没有解决 ， 因此闲鱼先推进了客户端基础设施全面拥抱淘宝的步伐 ， 完成了移动中台底层中间件的对接以及配套基础设施的迁移 。这样在极大降低了成本的同时也使闲鱼大幅度提升了性能和稳定性 。此后的两年中 ， 闲鱼团队的规模一直比较小 ， 正因如此 ， 我们一直在寻找提升研发效率的方案 ， 并进行很多不同的尝试 ， 后面会详细说明 。
再经历了不同的尝试后 ， 闲鱼选择了 Flutter 。而从“瞄”到 Flutter 到确定采用的这一过程 ， 大概可以归为三个阶段：
1、2017 年 ， 闲鱼开始进行对 Flutter 的技术调研 ， 思路是如何令小团队的研发效能大幅度提升 。之后闲鱼又进行了前期的验证及与 google 的合作；
2、2018 年 ， 开始进行实际的业务验证；
3、2019 年 ， 我们确认团队可以驾驭这项技术后 ， 开始大规模落地与推进 Flutter 在闲鱼的应用 。
目前闲鱼线上的主链路几乎已经完全拥抱 Flutter ， 仅剩的一些业务也会在后续逐步进行迁移 。
闲鱼的 Flutter 化架构演进之路闲鱼在确定 Flutter 之前做过哪些尝试呢？首先来看当时的背景 。
众所周知 ， 在阿里的前端搭建体系里 ， Weex 是主流方案 ， 但当时闲鱼的产品主链路需要一个高性能、不降级的方案 ， 该场景下这一类技术无法满足闲鱼客户端的需求 。因此是否适合闲鱼客户端主链路使用成为了我们对技术方案的选择的主要考虑方向 。
推荐阅读
- Java一些写法的最佳实践
- Android组件化开发思想与实践
- 自动化运维工具Ansible之LNMP实践环境部署
- 召回算法实践总结
- CentOS7分布式部署open-falcon0.3.0实践
- 初中学生假期社会实践报告范文 中学生社会实践报告
- 弹幕系统设计实践
- 分布式定时任务调度框架实践
- Java中异常处理的10个最佳实践
- 超实用的18个Java8日期处理的实践！建议收藏！