深度解读58本地服务Flutter落地实践：两点优化建议，四个避坑经验
Posted 前端之巅
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了深度解读58本地服务Flutter落地实践：两点优化建议，四个避坑经验相关的知识，希望对你有一定的参考价值。
李旭：2020 年 3 月 58 同城商家版开始使用 Flutter，5 月灰度，6 月份正式上线。之前商家通是 Native+React Native+H5 技术栈，但 React Native 的性能较差，加上前端 React Native 开发人力资源紧张，以及很多业务迭代快，不仅要跨端还要跨 App（微信、58App），在这方面显然 H5 更适合，React Native 逐渐不适用。多次迭代试验后，现在商家通就变成了 Native+Flutter+H5+React Native 的技术栈。
58 阿姨是我们在 2020 年 9 月份开始启动的新项目，此时 Flutter 已经在商家通上取得了良好效果，58 阿姨项目便继续选定 Flutter 作为了技术栈。从这两个项目综合来看，我们选择 Flutter 最主要的原因是因为其开发提效和双端一致性，以及接近原生的性能体验，并且 FLutter 不依赖原生的 UI 库，这让 Flutter 升级更平缓，项目更易维护。
李旭：58 商家通一直是 58 本地服务的试验田，新的技术都会在此进行验证。选择 Flutter 一开始也只是尝试，但随着版本迭代，Flutter 双端一致性、良好的交互、节省人力的好处逐渐体现出来。尤其本地服务一直处于创业状态创新阶段，Flutter 更利于快速迭代试错。
至于工程庞大的 C 端 58app，阻碍使用 Flutter 的主要因素应该是包大小和基础建设问题。iOS 端集成 Flutter，市场包会多出 10M+，影响 C 端用户的转换率，这是不被允许的，而 B 端对包大小没有这么严格的要求。
另一方面完善的 Flutter 基础建设才会提高各个业务线共同开发的效率，所以目前 C 端还是以稳健为主。但相信随着 Flutter 基础建设的完善，5G 的普及对包大小的忽略，日后 C 端也会接入 Flutter。
李旭： 现阶段 58 商家通是 Flutter 混合模式，有 6 个模块使用了 Flutter 页面，58 阿姨则是纯 Flutter 项目，这在 58 也是首次如此大规模使用 Flutter。在 Flutter 调研期间，公司无线通道技术委员会就组织了两期 Flutter 共建项目，58 本地服务也做了核心的部分。优化层面，主要解决了 Flutter 项目工程结构管理、原生的混合开发、可视化埋点、布局动态化等问题，后面本地服务也在内存泄漏检测和代码覆盖率方面做了开发优化。
李旭： 遇到的挑战主要是项目工程结构管理，与原生的混合开发、埋点、布局动态化、内存泄漏、代码覆盖率等问题。这些问题现阶段都有了落地的解决方案：
比如 Flutter 官方的 Add to App 方案，对原生工程有入侵，无法支持 Native 和 Flutter 并行开发，于是我们做了 Flutter 开发工具流 magpie，实现独立的、可视化的 Flutter 工程的创建、开发、编译、打包流程：
https://github.com/wuba/magpie
以 iOS 端为例，将 Dart 的代码编译为 iOS 工程中可用的产物，同时还附带了 Dart 依赖的 Plugin 的 Native 代码、Plugin 的注册器、Cocoapods 的配置文件 podspec 以及快速集成到 iOS 工程用的脚本。这样一来，iOS 工程就可以通过 Cocoapods 直接集成 Flutter 构建产物，做到了源码和编译环境的隔离，同时保留了本地调试 Flutter 的功能。
在布局动态化遇到的一些问题，例如：Flutter 剔除 Dart mirror，缺少反射能力，Flutter 版本迭代较快，适配成本高，第三方插件的如何支持等。经过研究我们使用 Function.apply() + 自定义 Widget mirror 解决反射问题，使用代码转换器和注解完成对 Flutter 版本的适配和第三方组件的转义。根据 Flutter 源码生成 DSL 和业务逻辑代理文件，降低了开发人员的接入成本。想了解更多关于布局动态化的信息，请关注 58Flutter 布局动态化框架 Fair：
https://github.com/wuba/fair
目前 Flutter 开发工具流 magpie、布局动态化框架 Fair 均已开源，相信应该对大家有帮助，欢迎使用。
李旭： 在商家通一期迭代中提出了一些试运营类活动需求，类似于卡牌抽奖的小游戏，如果用原生做，使用动画引擎成本较高，使用 Native 动画技术又很难保证效果的一致性，一般都会选用 H5 去实现，但交互上又会有些不流畅。
这种情况下，我们尝试了一下使用 Flutter 去解决，但由于工时较短，加之产品和 UI 一直也没有沟通好动画的效果，在只有静态图和语言描述的情况下，客户端先进入了开发，UI、UE 同时去制作动画效果。结果 Flutter 开发效率较高，最后是开发人员和产品沟通下先完成了大概的动画效果，UI 和 UE 随后才按照实现效果微调后做出了最终的动画视频。
李旭： 项目的技术选型跟项目的人力配置、迭代周期、业务需求、业务目标等有很大的关系。Flutter 主要是可以替代部分 Native 开发的一种方案，虽然可以节省人效，但不能热更新也是一个劣势，所以业务需要热更新能力就不要考虑 Flutter 了。
而且中小型项目中不易有太多的技术栈，会加剧项目的复杂性，如一些项目中有了 React Native 和 Native 混编模块，其实没有必要再接入 Flutter。很多项目接入 Flutter 可能只是尝试和试验，经常在接入一个页面后就没有扩展了，并不会为开发带来更多优势，反而会增加项目的维护成本。此外，对包大小敏感的项目也会忽略 Flutter。目前来看，Flutter 更适合中小型快速创新项目 Native 部分的开发。总体来说，框架选型一定要适合自己的业务。
李旭：Flutter 实践最让人期待的应该是在物联网终端中使用。现在谷歌 Fuchsia 会以 Flutter 为 UI 框架，并且一套代码可以在 iOS、android、Mac、Windows、Linux、Web 上运行，58 本地服务也已经成立终端技术部，未来的开发环境不仅是手机和 PC。
针对跨平台开发，我认为手机系统厂商为了维护自身的开发生态，不会出现大一统的局面，依旧会维持百家争鸣、百花齐放的行业状态，混合开发将会长期存在。Flutter 应用虽然不会替代原生，但使用的数量和场景会变得更多。我们还是要根据业务的形态去选择技术栈，但我仍旧看好 Flutter 的未来，它不一定是物联网终端系统的主流技术，但是目前看来是最接近的。
李旭： 第一，Flutter 的嵌套声明式开发容易造成魔鬼嵌套，会降低代码的可读性，要注意组件拆分。
第二，在混合开发上 Flutter 官方的方案不成熟，三方方案不完美，而且有停止维护风险。建议 Flutter 页面做业务闭环，避免多 Flutter 容器的共存现象。
第三，Flutter 在快速发展中性能和完善性还在逐步提升，中小型团队在对 Flutter 进行性能优化或者适配工作时，应避免对 SDK 或引擎改进带来的高成本，毕竟目标是提效。技术服务于业务，讲究成本与收益。
第四，目前 Flutter App，Web，PC 技术栈中，除了 Flutter App，其它的技术栈还需要优化，在生产上使用还达不到提效的作用。
李旭： 前端和客户端的技术日新月异，Flutter 也可能会淘汰，所以前端、客户端开发还是要向下挖掘沉淀，掌握解决问题的核心思想，不局限在 UI 的构建上。也可以向视频、图片处理、即时通讯等方向深度发展，做到以不变应万变。
李旭，2016 年加入 58 同城，58 本地服务 iOS 资深开发工程师，58 无线通道技术委员会成员，先后负责 58 商家通，58 阿姨等项目。多年客户端开发经验，负责项目中 Flutter 的落地方案和实践，目前专注于 Flutter，深度参与 Flutter 动态化，内存泄漏工具的开发。
8 月 20-21 日，InfoQ 首场 PCon 全球产品创新大会落地北京。大会共设置 10 个专题，涵盖优秀产品及运营发展所需了解的管理、运营、设计、能力培养等多个方向相关内容，更包括现象级产品背后的精彩故事，以及产品经理成长过程中的经验分享，值得希望未来在产品道路上更好前进的你了解学习。
目前大会 8 折报名优惠阶段，点击「阅读原文」查看更多大会信息。有兴趣的同学欢迎联系票务小姐姐：17310043226（微信同号）。
以上是关于深度解读58本地服务Flutter落地实践：两点优化建议，四个避坑经验的主要内容，如果未能解决你的问题，请参考以下文章
如何提高IT运维效率深度解读京东云基于自然语言处理的运维日志异常检测AIOps落地实践