原标题：Flutter到家助手实践

目的

从2019年8月起“到家助手App”在团队正式使用Flutter进行App开发，其中Flutter开发页面占比约70%。目前此占比在行业内是比较高的一个值，而Flutter做为一个比较新的“跨端开发框架”，在引入过程中遇到了不少问题，踩了不少坑。所以本文会介绍团队是如何引入Flutter到现有App开发的过程，供读者参考借鉴。

Flutter概况

在介绍引入Flutter技术前，需要介绍一下Flutter是什么？Flutter是谷歌的跨端移动UI框架 ，可以快速在iOS和Android上构建高质量的原生用户界面。

从2018年12月1.0版本正式发布，就受到移动研发工作者的广泛关注与应用，如上图所示：在GitHub上的Stars 数量是68,000 ，使用了短短一年，在Stars数量上就接近了同行业领头羊React Native(以下简称RN)，RN从发布至今已经有 4 年有余，拥有较为完善的开发生态。

跨端方案选择

每个移动前端团队在提升开发效率上都会重点关注跨端方案的选择，目前行业主流方案有两个分别是RN与Flutter，接下来会从四个方面对两个主流跨端方案进行对比：

成熟度：RN已经发布多年，行业对其也比较认可，积累了丰富的开发组件。所以在此方面RN目前更有优势，但随着时间推移，而且在Google的大力推动下，会有越来越多开发者的参与，相信不久的将来Flutter开发生态也会越加成熟；

性能：在渲染技术方面Flutter 一开始就定义了一个目标：“以每秒120帧的速度持续渲染”，正是基于此目标，Google选择了自己实现(GDI)，避免了RN的那种通过桥接器与Java通讯导致效率低下的问题。

如下图所示，在XCode里的Debug View Hierarchy可以看到，Flutter View的布局是一个整体。而RN的渲染上采用的是把<View>标签里的内容转成原生View，虽然比基于Cordova的HTML5好很多。但一旦遇到嵌套层级多view的情况时，就很容易出现页面渲染瓶颈。所以在性能方面比RN更胜一筹。

调试效率：Flutter 在Debug时“革命性”的引入JIT(动态编译)，在开发过程中Flutter通过JIT 可以实现中Hot Reload （热更新），开发者可以在不用重新运行程序的情况下就可以快速刷新开发页面，提升了开发效率。

而Release时使用的是AOT（静态编译），效率等同于原生的代码的执行效率。所以在调试效率上的表现，Flutter也更优于RN；

UI一致性：“一套代码，多端运行”是跨平台开发方案都在倡导的，但在UI一致性上RN让很多开发者又爱又恨。

因为RN框架本身不负责界面渲染，而是由原生代理实现。所以开发者除了要掌握RN框架外，还必须同时熟悉 iOS 和 Android 系统的前端匹配等相关知识。

而Flutter则闭环了渲染过程，不依赖于底层操作系统提供的任何组件，从根本上保证了视图渲染在 Android 和 iOS 上的高度一致性。近期Flutter还发布了Web方面的支持，未来前景可期；

局限

对一项新技术不能全看优势的方面，也要看到一些局限的地方，Flutter局限地方如下：

• 包大小提升：使用Flutter后应用包大小会明显提升，iOS ipa包会变大10M左右，Android apk包会变大6M左右；
• 学习成本高：Flutter作为全新技术学习成本较高，是众多开发者犹豫进场的最主要原因；
• 生态相对弱：Flutter作为新技术在第三方库数量相对较少，很多功能需要自己造“轮子”；
• 原生功能限制：部分原生功能Push、地图、定位、蓝牙等功能还是需要借助原生实现；

组员学习

针对Flutter“学习成本高”这一问题，团队在引入新技术到团队开发之前，前期先整理Flutter的学习框架，再根据团队情况与时间排期，进行了学习项优先级分阶。

上图中的标红项，“基础Widget”、“网络与存储”、“工程管理”、“打包”等四项是需要优先组织团队培训学习。另外，其他项如“测试”、“调试”、“线上运维”等其他项为非业务阻碍项，就暂时调低其学习优先级。

在确定了学习优先级后，分两期对组员进行内部培训，第一期内容是“基础Widget”使用，第二期是“网络与存储”与“工程管理”。经过一个月的培训，使团队的每个成员具备了Flutter的基础开发能力，可以进行业务开发。

另外，笔者也建议大家要学习上图的其他项，像“状态管理”，“跨组件通信”等，都是将来学习或开发第三方Flutter插件的重要基础。

落地项目

确保团队成员有开发能力后，就要去思考如何进行落地项目? 在落地项目的程中，需要面临的问题有三个，分别是“协同开发”，“混合开发”和“容灾降级”。

问题

• 协同开发：由于是Dart是新的开发语言，而团队的原技术栈分别是Android与iOS，所以需要解决三端代码管理与协同开发；
• 混合开发：大多数的项目是需要采取混合开发（Android/iOS +Flutter)，那么Native页面与Flutter页面的相互跳转，是需要关注并解决的问题；
• 容灾降级：在Flutter技术引入前期，我们对部分Native页面进行了Flutter改造，所以要考虑极端情况下，若Flutter页不可用可以降级回原来的Native页面；

“协同开发”方案

“协同开发”需要关注的事项有三个，分别是“代码仓库模式”、“原工程支持Flutter开发”、和“混合栈框架”，接下来分别对这三个事项进行详细介绍。

两种仓库模式

谈到协同开发就需要涉及到代码仓库调整，所以需提前介绍一下Flutter开发的两种模式，其中一种是“混合模式”，另外一种是“产物模式”，以下是两种模式的优缺点说明：

在经历前期培训后，团队组员已掌握Flutter的开发技术，所以“混合模式”在当前情况下，是比较适合我们团队的代码管理方式。未来会考虑迭代使用“产物模式”来进行代码管理，这样的好处是将来稳定的功能模块可以实现组件化。

原生工程支持Flutter开发

iOS平台配置

可能需要做一个假设，你已有的iOS工程路径在 ~/integratedFlutter 目录中，你需要在这个目录里创建 Flutter 的模块：

在 my_flutter 目录中 flutter 会创建一些 Dart 代码，一些 Ruby脚本，启动项以及一个隐藏的.ios子目录。 接着在你的 Podfile 文件中添加以下脚本：

责任编辑：