闲鱼正在悄悄放弃 Flutter 吗？

采访嘉宾 | 于佳（宗心）

编辑 | Tina

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

以后这支不到 15 人的闲鱼团队从工程架构、混合栈调用、打包构建、协同模式上都作了一些创新，保证了 Flutter 能融入到闲鱼已有的客户端工程体系内。在 2017 年到 2019 年期间，闲鱼也不断的修正 Bug 提升 Flutter 的稳定性并同步给 Google，并在实践中沉淀出一套本身的混合技术方案，开源了 Flutter Boost 引擎。

2019 年，闲鱼开始大规模落地，推动 Flutter 在闲鱼的应用。2020 年，闲鱼线上的主链路几乎已经彻底拥抱 Flutter。这两年，Flutter 也逐渐在其余企业里落地，但同时也不断有质疑的声音发出。甚至有传言表示“闲鱼的新业务已经放弃 Flutter”、“相信闲鱼遇到了很大的难题”......

那么，做为 Flutter 先驱和探路者，闲鱼在过去几年的摸索过程当中是否有走弯路？闲鱼如今到底面临着什么样的挑战？是否会放弃 Flutter？新业务选择了什么技术？对应的技术选型原则是什么？针对这些疑问，闲鱼技术团队客户端负责人于佳（宗心）逐一给了咱们解答。

国内第一个引进 Flutter 的团队

InfoQ：闲鱼当时引进 Flutter 时主要是为了解决什么问题？

于佳（宗心）：闲鱼在 17 年调研的时候，客户端团队只有不到 15 人，而闲鱼的业务场景能够称得上是一个 “小淘宝”，相对比较复杂。这种场景下咱们首先须要解决的是多端人力共享的问题。多端人力带来的好处不仅是能够一人开发双端，也表明着更好的研发资源调配灵活性（这意味着团队的 iOS：Android 的比例再也不须要 1:1，而市面上 Android 的工程师基数远大于 iOS）。

另外咱们但愿这个技术是贴合移动端研发技术栈的，而非前端技术栈，自己对于 RN 和 Weex 来讲，工具链和研发习惯仍是有比较大的差别的。最后咱们但愿这个技术的体验能够作到接近原生，AOT 下的 Flutter 基本知足咱们当时的要求，在实际测试过程当中，一样未深度优化的详情页面，Flutter 在低端机的表现比 Native 更好。所以当时基于这三个条件选择了 Flutter。

2018 年的尝试投入过程当中，整个基建和探索带来了必定的成本。2019 年，团队开始正式大量使用 Flutter 进行研发，目前整个团队 70% 的 commit 来自 Dart，能够说基本完成了咱们当初的指望。在实际的研发过程当中，基本能够完成一个需求一个客户端投入的目标。

InfoQ：不少人质疑 Dart 语言，认为这个语言独特小众，还存在好比说多层嵌套的问题，您们怎么看待新语言的应用？

于佳（宗心）：语言是咱们选择技术方案的其中一个因素，可是相对比较弱的因素。

咱们会从几个角度去看：

• 语言的背景，从咱们的角度来看 Dart 是大厂研发的，也有比较久的历史。

• 语言的学习成本，从语法糖和学习曲线上来看，Dart 成本都比较低，首先 Android 同窗的上手率很快。另外熟悉 swift 的 iOS 同窗，上手也很快。现代语言的特性有不少是相通的。这部分是它的优点。

• 语言带来的其余优点，如编译产物支持 AOT 和 JIT，比较灵活。AOT 有明显的性能优点。

• 语言的将来的趋势。Dart 在 2020 年第四季度 Github Pull Request 的排名已经到了全网第 13 位，超过了 Kotlin（15 位），Swift（16 位），Objective-C（18 位）。做为移动技术领域的新语言成长性仍是很是不错的。

对于像多层嵌套的问题，能够经过进一步抽象一些控件类或方法解决，并非特别大的问题。

InfoQ：闲鱼引入 Flutter 以后作了哪些关键创新？在使用 Flutter 上有哪些收益？

于佳（宗心）：闲鱼在这部分创新很是多，并在内部申请了很是多专利。

• 咱们的开源项目 Flutter Boost 完全改变了 Flutter 官方的一些 RoadMap。目前 Add2ExistApp 是行业最主流的研发方式。混合开发一方面帮助了业务更平滑的迁移到了新的技术栈，另外一方面能够更好的利用已有的 Native 能力，大幅减小了重复开发的工做。

• 针对音视频的外接纹理方案，也是目前行业大厂常见的解决方案，在外接纹理方案下，Native 和 Flutter 侧的缓存管理获得了统一，在性能上也有必定的提高。

• Flutter APM，基于 Flutter 技术栈的性能稳定性数据采集和加工方案，目前在集团内部也是跟多个 BU 一块儿共建，为大的 AliFlutter 组织提供服务。

• Flutter 相关的动态模版方案，Flutter DX，兼容集团的已有的 Native 模版，保证了业务的平滑迁移，并为 Flutter 提供了部分业务动态性。

• 其余还有不少，包括内部的高性能长列表容器 PowerScrollView，动画框架 Fish-Lottie，游戏引擎 Candy，咱们如今还有一些新的方向在沉淀，在基于 Flutter 的研发流程和研发工具上也有投入，将来你们若是感兴趣能够去 InfoQ 组织的行业大会与咱们交流。

闲鱼有想过放弃 Flutter 吗？

InfoQ：最近一两年，您们在 Flutter 开发上，遇到的最大挑战是什么？跟最初使用 Flutter 时的挑战同样吗？

于佳（宗心）：早先几年闲鱼做为整个行业的先驱，主要的挑战是整个技术生态太差，都须要本身作。另外就是前期引擎的稳定性有比较大的问题。

最近几年随着整个技术的深度使用，以及闲鱼这两年业务快速发展背后，愈来愈多的体验问题被你们说起，所以咱们从去年开始进行了整个产品的大改版，同时客户端的目标就是全面优化，打造更好的用户端产品体验。

所以在生态逐渐完善后，咱们的挑战是，怎么经过 Flutter 来实现更加精细化的用户体验。去年，这部分确实花了咱们比较多的精力。基于这个命题，咱们在内存和卡顿上内部也开发了较多的基于 Flutter 的检测工具，在内存优化和卡顿优化上也有一些比较具体的方法，但不得不说，全部的细节优化都是比较耗人力的，无论是 Native 仍是 Flutter 都要投入至关的精力，因此咱们目前也面向全行业进行客户端的招聘，但愿有志在 Flutter 领域进行探索的同窗联系我。

InfoQ：在混合研发体系下，闲鱼还进行了引擎定制，那么官方提供的方案主要问题是什么？对于通常小企业来讲，混合开发复杂度会不会过高？

于佳（宗心）：闲鱼在前期有很多修改引擎的动做，我针对当时有一些 本身的反思，一方面是确实由于 Flutter 不太完善，另外一方面在 18 年左右，咱们本身引擎的理解也不够深入，不少时候能够经过更上层的方案解决，这也间接致使了咱们的不少引擎定制修改难以合入主干。

因此这部分我想说的是，目前官方的方案能够解决 90% 的问题，若是必定要说定制，目前在性能侧仍是有一些问题的。好比闲鱼目前首页仍是 native 没有使用 Flutter，就是由于替换之后启动加载体验不佳，另外在长列表侧你们一直诟病的卡顿问题，咱们有尝试经过上层框架解决了一部分，接下来可能还须要底层引擎帮忙优化。另一些包括双端字体不一致的问题，还有输入框体验不一致的问题，都须要官方进行长期的优化。

目前咱们主要仍是但愿跟随主干分支，尽可能不修改 Flutter 的代码，闲鱼团队会储备一些引擎侧的专家，同时也会依靠集团 AliFlutter 的生态作事情。在整个 AliFlutter 的组织里不一样的 BU 擅长的也不一样，如 UC 同窗更擅长引擎定制，闲鱼团队有大量的上层应用框架，淘宝团队提供基于构建相关的基础设施。这样在大型公司中经过内部开源社区的方式就能够解决大部分的问题，放心开发了。

对于中小企业来讲，要明确下你们面临的场景，若是前期快速迭代跑起来，对细节问题能够有一部分妥协，选择 Flutter 是一个比较明确的路径。今天你们所处的环境比闲鱼当年所处的环境要完善的多。推荐使用 Flutter Boost 进行混合开发，在部分场景下遇到问题没法快速响应时，也能够经过混合工程使用 native 进行兜底。复杂度方面，单纯引入混合栈能力，总体复杂度通常。

InfoQ：有传言，闲鱼有新业务没采用 Flutter，这给不少人形成了闲鱼放弃 Flutter 的观念，那么您们在新业务的技术选型上，考虑了哪些因素？

于佳（宗心）：做为技术决策者，是应该避免本身被某一个技术绑架而在落地过程当中产生谬误的。Flutter 和其余技术同样，最终是为了帮助团队实现业务价值，同时它也只是移动端的一种技术，捧杀和谩骂都是不合适的。这也是我特别不想在公众面前回应这个事情的缘由，由于 技术自己要看适用场景。

从目前闲鱼的人员规模和业务规模来看。对于架构设计，个人理念是尽可能追求一致性和架构的简洁。

整个客户端组织将来从语言的方向来看是 Dart First，尽可能减小双端的研发投入。而对其余容器的选择，主要以 H5 为主，在将来的路径上尽可能减小其余容器的接入，让前端开发也回归到标准路线来。

这里有两个好处：

1. 组织成本最低，组织成本包括了同窗们的学习成本、协同成本等等，多技术栈和容器多会带来额外的成本，这是我不肯意看到的。

2. 架构的一致性对研发效能和质量都有帮助。举个例子，随着业务复杂性加大，多容器带来的内存飙升和包大小的问题是很是致命的，并且几乎是无解的，这就须要架构师做出决策，干掉什么留下什么。回到研发效能上，配套的工具，流程必定是围绕一类容器和语言来扩展的，若是方案特别多，每一个方向都须要作额外的配套设施，成本收益很低，研发的幸福感也很低。

从这个设计的角度出发，咱们会有几个明确的选择：

• 在默认场景下使用 Flutter 做为首选的方案；

• 在投放活动、前台导购、很是不肯定的新业务、以及管理后台等使用 H5 做为首选实现方案；

• 在极少场景下，好比已有完整的 SDK 附带 UI 的支持如直播，以及将来中台的拍摄功能 SDK 也是自带 UI 的部分，如要切换，Native 成本最低，选择 Native。另外目前 Flutter 在首页加载还有必定的性能问题，所以还在使用 Native。从长远发展来看，将来到必定程度可能随改版直接改成 Flutter。

关于将来发展

InfoQ：使用 Flutter 多年后，如今回过头去看，您认为哪些公司哪些场景适合 Flutter？

于佳（宗心）：目前看起来有几个典型场景比较适合：

• 中台战略下的小前台产品，从大公司的组织里看阿里、头条、美团都有相对完善的 Flutter 组织或内部技术社区能够提供一些基础服务，保证了基于 Flutter 基础设施在前期投入过程当中的成本均摊，在将来落地过程当中，业务团队能够更加专一于业务研发，而更少的担忧过程当中填坑的成本。

• 中小型企业的初创 App，在人力成本资源都不够的状况下，但愿先跑通流程上线验证的团队，能够尝试使用 Flutter 进行研发，在我本身实际的面试和行业交流过程当中，这一类状况也比较典型。这种方式能够避免前期成本过分投入，在人员调配上也更加灵活。

• 另外这个观点尚未验证，可是逻辑上应该可行。将来面向企业内部流程工具，政府部门的部分工具属性较强的 App，能够尝试使用 Flutter。由于目前我了解的状况来看，在企业这边的应用来看，总体 ToB（美团商家端）和 ToD（好比饿了么骑手端）的场景的 App 特别多。横向比较来看，场景比较相似，也就是说更多中长尾应用有多是 Flutter 技术的主要场景。

InfoQ：您认为将来 Flutter 急需改善的地方是什么？

于佳（宗心）：从 Flutter 2.0 发布后我跟一些一线开发者交流的感觉来看，Flutter 仍是须要推动跨端性能和细节体验的优化。去年一年在大的战略方向上（跨终端），Flutter 作的不错，在 PC 和 Web 侧都有建树，跟车企以及操做系统厂商合做都有必定进展。但回归到产品体验和开发者体验上，还有很多路要走，不少时候对于一个严苛的业务方来讲，小到字体和控件的体验都会成为最后不选择这门技术的缘由。这部分但愿整个开源社区在新的一年能有一些进步。咱们 AliFlutter 组织内部，以 UC 内核团队为首的同窗们，在这方面就有很是多的沉淀以及 PR，在内部引擎制定上有不少体验的提高。将来在 AliFlutter 组织内，咱们也会除了完善整个公司的基建外，进一步关注细节体验，沉淀一些最佳实践给到其余的开发同窗。你们会在2个月内看到咱们最新出版的书籍，欢迎交流。

InfoQ：Flutter2.0 来了，那么 Flutter 会成为主流选择吗？

于佳（宗心）：能够讲一下我对 Flutter 将来的判断。一方面在将来操做系统有可能走向分裂，多终端的场景下，Flutter 会有比较不错的发展，跨平台自己的对企业来讲在成本侧是有很大的诉求的，尤为是互联网公司。可是从历史的经验来看，Flutter 只是渲染引擎，即便今天的游戏开发，在游戏引擎和配套工具完善的状况下，有部分的功能模块（好比社区 / 直播的功能）依然仍是混合的框架，因此混合开发最后必定是一直存在的。能不能成为将来整个移动研发的主流这件事情上看，我没法给出答案，但能够确定的是，在生态更加完善后，会在必定的历史阶段成为客户端研发的另外一种常见的技术选择。

嘉宾介绍：

于佳，花名 宗心，闲鱼技术团队客户端负责人。2012 年应届毕业加入阿里巴巴，经历集团无线化转型的重要时期，参与过集团多款重量级 App 以及移动中间件的设计与开发，多年客户端老兵。2014 年参与了手机淘宝的 iOS 客户端的架构升级，该架构首次完成了对百人团队并行开发的支持，同年主导了手机天猫客户端基础架构以及交易链路向手淘架构的归一，为手机淘宝做为将来集团无线中台奠基了坚实的基础。2015 年加入闲鱼客户端团队负责端架构和团队建设，工做期间完成了基于 Flutter 混合架构的闲鱼客户端的总体架构设计，在工程体系上完善了针对 Flutter 的持续集成以及高可用体系的支撑，同时推动了闲鱼主链路业务的 Flutter 化。将来将持续关注终端技术的演变及发展趋势。