招贤纳士
我们急切需要浏览器渲染引擎/Flutter 渲染引擎的人才，欢迎大牛们加入我们。
前言
1 月 16 日，UC 技术委员会联合掘金、谷歌开发者社区举办了 2021 年首届 Flutter 引擎为主题的技术沙龙活动。活动吸引了 150 多名同学报名，由于疫情控制现场人数的影响，最终我们只能安排 50 名同学来到现场。另外，有 2000 余名同学围观了现场直播。活动中，来自阿里巴巴集团内的五位技术专家与大家分享了基于 Flutter 构建的研发体系，开发与优化经验，动态化方案，以及 UC 定制的 Flutter 增强引擎 Hummer 的优势与新特性。
从今天开始，我们会陆续将五位讲师在沙龙上的精彩演讲整理成文章与读者分享，敬请关注。
第一场分享是由 UC/夸克客户端负责人、UC 移动技术中台负责人辉鸿带来的《打造基于 Flutter 的 UC 移动技术中台》。本文约 6300 字，20 张图片，整体阅读时间约 15 ～ 20 分钟。
分享内容
大家下午好，直播间的新老朋友们，大家下午好。首先非常感谢大家对本次沙龙的关注和参与，以及感谢掘金社区和谷歌开发者社区对于本次沙龙的支持。我今天分享的主题是打造基于 Flutter 的 UC 移动研发体系，今天我的分享会以介绍研发体系为主，其中里面的一些细节，包括引擎的深度优化、性能优化、移动端的中间件建设以及我们在 Flutter 上的一些动态化的建设等，将由我的同事来跟大家去做细致的分享。
我先跟大家分享我们对于整个移动端发展趋势的总结和判断，我们把整个移动端的发展分为三个阶段：
第一个阶段是大概在 08~13 年左右叫萌芽期，这个阶段整个移动端的基建是不太完善的，包括操作系统、网络以及设备等，这个阶段客户端团队的主要工作除了业务开发之外，主要就是去完善移动端基建，去做端的性能优化，这个阶段是以原生开发为主，包括安卓的客户端，iOS 客户端是独立的去开发和演进。
第二个阶段是移动互联网快速发展的阶段，这个阶段移动端基建已经相对完善，借助人口红利，整个业务的发展是非常迅猛，业务对于技术的要求就是要能够快速的迭代，在这样的要求下诞生初出像 Weex/RN 这样的一些快能够帮助业务快速迭代的一些技术。
当下我们管它叫第三个阶段，这个阶段人口红利已经基本消失，整个移动互联网呈现存量竞争的局面，大部分产品进入到了平台期，对于平台期的产品来说，它又回归到用户体验为王，通过用户体验去拉用户留存，所以这个时候它对端的性能要求重新提升到一个新的高度，除此之外就是精细化的一些运营工作，这是对于成熟产品的要求，除了对于成熟产品的打造之外，大家都在积极的去寻找团队和公司发展的第二增长曲线，所以这个时候就会去不断的去探索创新，对于创新来说，最重要的事情就是要能够快速的去孵化出创新产品，同时现在的创新对于技术的要求也非常高，需要通过技术去驱动整个业务的变化，对于技术来说需要有这种领域的专业的知识，包括现在比较流行的端智能，以及多媒体相关的技术。
在第三个阶段，也呈现出多 APP 产品矩阵的一个趋势，这个时候每个团队都有多个 APP 去维护，同时不断的去孵化新的 APP，在这种多 APP 形态下对开发模式有了新的要求。
我们就在设想移动端理想的或者它的终局的开发模式是什么？在回答移动端的模式之前，我们先看 PC 端， PC 端其实大家都知道，因为已经经历过了，PC 端它的开发模式最后是 Web 主导的，因为每个人 PC 机上面都有一个支持 w3c 标准的浏览器，这个浏览器承担了业务容器的工作，对于开发者来说，他不怎么需要去关注操作系统，只需要去跟浏览器打交道，这样它整个开发的门槛是比较低以及开发的效率是非常高的。
回归到移动端，我们认为不太可能达到像 PC 那样的状态，App Store 生态造成 APP 的割裂，不可能出现一个像 PC 浏览器这样的大一统的容器出来，我们定义的理想开发模式是这样的，首先它是是分层的，它有一个通用的符合自身业务特点的一个的容器，这个容器它在双端是统一的、是丰富能力，在这样一个容器上，有一个足够高效的开发框架，它的研发效率要是要足够高的，它的体验是要足够好的，同时它的研发门槛是要足够低的， 由于做了分层，当团队内的多个 APP 都有统一的容器，那上层的业务就具备了多端投放的能力。
这就是我们对整个理想的移动开发模式的理解，那要达到这样的一种状态，我们把它分了有几个关键的因素：
第一个关键的因素就是要有一个功能稳定并且相对强大的容器，这个容器刚才已经介绍它的特点，在 UC 团队里面，我们是基于移动技术中台去打造的这么一个容器。
第二个是要有一个高效的、高体验的业务开发框架，我们选择的是 Flutter，把 Flutter 当成是我们创新 APP 甚至主营 APP 的首选业务开发框架。
除了技术之外，还有一个很重要的一个点是组织的保障，它需要一支多技术栈联合作战的团队，包含对底层引擎、容器建设、开发框架、高可用体系都能掌控的团队，由于这个开发模式的理念来自于前端，需要把客户端和前端这样的一些理念和技术去做结合，团队是需要客户端和前端一起来去参与配合。
就是要达成这样的效果。这三点我认为是缺一不可，接下来会着重的介绍前两点，包括移动中台的打造，以及我们在 Flutter 上的选择和建设。
非常的幸运，在 UC 的团队有机会或者有契机去做一个移动技术中台，中台的建设需要天时地利人和，中台核心也是为业务服务的，我们现在的业务战略可以理解成 2+x 的战略，2 就是 UC 浏览器和夸克 APP， 在这两个大型 APP 之外，我们还会去做创新的一些尝试，基于这样业务的一些判断，为了提升整个团队研发的效率和增强团队的技术能力，我们打造了内部的中台，我们的判断中台是对于这种多 APP 战略下的一个必然的选择，当然中台的核心目标还是业务的成功。
接下来简单介绍一下我们中台打造的一些思路，我们把 APP 分成了三层，最下面这一层是我们的 APP 容器层，它包括了端到端的一些服务，比如说账号能力，支付能力、运营能力等等一些通用的能力。这部分的工作大概占到整个 APP 的 30% 左右的工作，这一部分我们的目标是能够 100% 复用的，起码在同一个研发体系下的都能复用。
中间这层是通用的业务解决方案层，虽说 APP 它的产品形态千千差万别，但是有很多的功能都是可以复用的，包括启动流程、个人中心、Feeds 流、评论、甚至播放界面等很多模块经过简单改造是可以复用的，不需要每个 APP 都是需要重新去去做。这部分按照不同的 APP 占比不太一样，大概是占 20%~30% 左右。
最上一层是个性化业务的开发层，这一部分都是需要重新的去开发的，我们的思路是去提升这一层的开发效率，同时把个性化的模块不断得往中台去沉淀，让更多的个性化的业务变成通用的业务，以便多个 APP 可以复用。
除了这三层之外，最下面是我们的研发效能体系，目前整个 UC 的研发效能平台已经在做技术产品化和技术商业化的一些工作，也取得了一定的效果，大家有感兴趣可以去搜索岳鹰和岩鼠这两个平台。最上面是我们的整个中台的门户，方便创新 APP 的开通激活以及信息的管理，这是整个中台我们的架构，接下来会简单的介绍一下我们容器里面的一些服务和业务模板打造的一些思路。
整个容器里面有超过 30 个以上的服务，这些服务都是端到端一体的，这里就不一一去介绍每一个服务，我会着重的讲我们做这些服务的思路：
首先我们这些基础的服务它是具备一键半自动的开通能力，提升整个服务开通的效率。
第二个是服务高可用，几乎所有的服务都是在 UC 和夸克这样大级别的 APP 上实践过的，同时每一个服务从客户端到服务端都有完整的监控，每一环节的链路，每一环节的效果和转换，我们都会全部的监控起来。
第三个所有的服务、所有的能力都是有对 Flutter 去做透出的。
比如说以 push 为例的话，如果一一去对接长链接、对接各厂商通道的话，是非常繁琐和耗时的，在我们中台把所有的流程都固化下来，只需要把从厂商那申请的 key 填到配置文件里，整个链路就通了，包括对接画像，对接内容、通道等。第二个重点的服务是我们的网络服务，我们的 uPaas 网络服务是在印度和印尼这样恶劣的弱网的环境下经过了千锤百炼，对于弱网环境做了极致的优化，同时支持 httpdns、http3 这样的一些能力，并且现在也支持了自动的去做网络状态的诊断；剩下要介绍的两个服务是我们跟多媒体相关的，包括整个播放的服务和拍摄的服务，我们的播放器在公域、私域这样的内容形态下，在秒开率和 seek 秒播的效果都是做到行业的突出的水平。
对于业务框架或者叫业务模板，刚才我已经说了，我们把行业里面大部分的 APP 做了分析，来分析他们的共同点，把这样的通用能力从客户端到后端到算法到内容做了以全面的打通，对于内容型的产品来说，它通常有两个流，第一个是客户端出发的叫日志流，用户的操作行为；第二个是内容流，从内容的引入到加工到算法的推荐，以及到客户端的展现，所以它围绕着这两个流在展开我们整个系统的工作。
整个系统里面我们统一了 APP 的 ID，所有的业务系统都通过 APP ID 去串起来，同时我们把端的一些参数通过公参的形式去做了接入，避免每一个业务系统都需要找找客户端来定义参数，后端有统一的 APP 网关，减少业务系统和客户端的联调成本。
对于每一个模板，有两个设计目标：可被高效二次开发和高体验，为了实现了业务模板可以被高效的定制和二次开发，我们跟 UI 同学订了一套规范，包含字号、色表和 icon，定制开发时只需要改这份主题文件就可以实现全局的 UI 生效，在模板设计上，我们用了 redux 的研发框架，实现 UI 和数据分离，在跟后端的协议和数据层提供扩展位和代码自动生成，这样既保证了一致性，又能做扩展和二次开发。
有了业务模板、基础的容器和基础服务，剩下的工作就是组装成一个新 APP，在中台门户上点选相应的服务和模板，会通知各个服务子系统开通对应的服务，并生成一份配置，通过这份配置就能够去不同的仓库里面拿到代码去组合成一个孵化器的工程。具体的业务开发就可以围绕着这样的一个孵化器工程去展开，基于这个工程做个性化部分的业务开发，创新可以做到从 1 起步。
上图是中台门户，我们的中台内部名称是 UMP（UC mobile platform），目前还是以内部使用为主。
刚才介绍的是以中台为基础打造的统一容器，在这样统一的容器上面，我们业务开发框架的选择是什么？因为这个论坛是 Flutter 技术沙龙，所以我们首选框架毫无疑问是 Flutter！对比其它的技术来说，Flutter 有明显的优势，尤其是在做创新项目时，首先看原生的开发（Native），我把原生开发用一个词来形容：笨重，基本上写过 Weex 或 Flutter 的同学也不太愿意去回去用原生做业务开发的，以 UC 浏览器为例，改完代码全量编一次可能需要数分钟，而且还得双端开发，开发的效率非常低；再看 Weex/RN 这样的技术，由于它的实现是强依赖平台的控件，所以它双端不一致，对双端依赖较重的问题，我们在实际业务开发时，经常会遇到一个功能的实现，需要一个 Weex/RN 研发再拖着一个 Android 和一个 iOS 研发，所以这样的效率在前期并没有很好的节省，反倒是需要解决很多端不一致的一些问题，同时它的性能也会有一定的问题。
所以我们内部 APP 的开发就变成 Flutter 为主，H5 和 Native 为辅的一个状态(Flutter > H5 > Native)，这么选择的还有一个很重要的因素是有一支能够优化 Flutter/H5 性能和体验的内核团队，Flutter 对标的是 Native，H5 解决动态性很高的场景。
Flutter 的优势，待会我的同事会跟大家去做介绍，网上也有很多的描述，比较关键的一点还是出于对未来开发模式的判断，对于我们能解决好过程中遇到问题的信心。
我们团队是从 2018 年就开始研究和实践 Flutter，之前主要还是在一些小 APP 的小场景去做试验，在试验和逐步铺开的过程中，我们核心关注两个点：第一个能力能不能达到我们的要求，尤其是多媒体的能力，比如图片、视频等，第二个是它的性能是不是如官方说的那么好，一步一步从我们前期的试水到后面开始在主 APP UC 浏览器和夸克的一些二级页面去做使用，去年开始大胆在创新 APP 上去铺开使用，创新 APP 80% 的业务功能是用 Flutter 来完成的（包括首页），这还是一个挺大胆的一个决策。
整个 Flutter 在 UC 团队内的体系在我们在业务发展过程中通过边打边建的方式建起来，具体做得事情跟行业里做的差不多，相对来说有两个差异点：
第一个，我们围绕着 Flutter 去建设了我们的移动技术平台，而且这样的移动技术平台能够持续的去做演进和积累，来发展我们的业务。
第二个，我们有一支内核团队参与到引擎的优化里面来，让我们遇到的很多的业务问题都能得到快速的解决。
当然这个过程中有一个很重要的点就是团队，技术选择了，还是需要人去实现的，团队内的业务开发同学需要具备 Flutter 业务开发能力，Flutter 虽然入门简单，但是要写出高性能的业务代码还是有一定的门槛和挑战的，为此团队内部开展了大概十来场的培训，来完成整个团队的技术升级。
这是我们的实践的一个效果，包括 UC 浏览器、夸克以及我们的一些创新产品。
在 UC 上，包括 UC 的个人中心，大家可以看到 UC 浏览器的第 4 个 TAB 个人中心，已经是用 Flutter 实现了，这个场景它代表的是在一级页面的使用，在 UC 浏览器上的第二个应用场景是正经部业务，这个业务是多媒体属性很强的业务，有很多的动图、视频等等，这个场景还是有一定的复杂度的，经过优化后，目前帧率在 55 帧+，内存可控，过程中也遇到很多内存问题，待会凌凌同学会给大家去做介绍。在夸克上，大量的创新业务场景都是用 Flutter 实现的，包括我们最近做的夸克的个人中心、文件中心、清理功能等等；我们也做了一些创新的产品的尝试，有一些已经上线了，有一些还在路上。
经过优化，在这些业务场景上，基本上能够做到媲美 Native 的体验，但是开发效率会 Native 的开发效率要提升两倍以上，而且整个开发的门槛下降不少。
刚才已经说了，在 Flutter 推广的过程中， 性能是一个核心关注点，围绕性能的问题，我们建设一套高可用的体系，它的建设思路是参照了客户端和前端的性能体系去做的，包括 Flutter 页面的 TTI，白屏率、出错、内存、流畅度等指标，其中基于 BuildContext 的内存泄露检测方案在行业里都有一定的先进性，它的原理有点类似于 Android 的 LeakCanary，我们去监控 BuildContext 这样一个相对大的、有生命周期的对象的申请和释放情况，通过这样的监控能够完成很多自动化的完成内存内存泄漏的检测；在高可用平台上，我们通过这么一个仪表盘的形式把 Flutter 页面的各项指标都监控起来，对于异常情况做到快速预警；除了我们的性能指标、高可用平台，我们还有一部分就是我们引擎的优化；
Flutter 在设计上是参考了前端的设计思路，是有固定范式的响应式编程框架，为了进一步提升研发效率，我们团队也探索了 Flutter D2C 的可能性，跟 UI 设计同学一起来升级整个研发流程，UI 和研发同学定义统一的规范：颜色、字号、字体、常规组件、图层设计的基础约束，在这样的统一规范下面，UI 同学通过 Sketch 完设计稿后，会基于我们开发的 sketch 插件设计稿上传到我们的 Vision 平台，Vision 平台将设计稿转换成 Flutter 的代码，然后研发同学就可以在 Vision 平台看到界面的代码和标注，就可以基于这个生成的代码做二次开发了，包括控件类型调整、点击事件绑定、数据绑定的工作，由于我们统一了 Flutter 的开发框架，Vision 也能主动生成整个模块的骨架代码，省去研发的很多繁琐工作，目前这个平台已经在团队内部用起来了，界面还原度高，对于偏简单的静态页面，提效非常明显，接下来对于整个代码的一个可读性会去做着重的提升。
OK，今天我主要讲的东西都已经讲完了，最后再做一个总结，UC 的移动研发体系有两个特点，第一个是围绕 Flutter 去展开，第二个基于中台做的统一容器的建设，整个开发有几个特点，第一个是统一规范，我们跟 UI 同学、算法同学以及业务系统的同学是有达成统一的规范，大家围绕着数据流、内容流、操作流去做统一的协议的制定，APP 开发有统一的开发框架，这让我们在开发业务的时候，能够做到像一个人一样去开发，这是统一规范的力量；第二个是整个高可用体系的建设，来确保整个 APP 的体验和质量；第三个就是我们会去尝试的代码自动生成这样的一个方向，在 Flutter 上面是完全可行，目前也拿到了不错的效果。
我们的创新在路上，Flutter 建设也还在路上，在业务深度使用的过程中，我们看到 Flutter 在复杂场景下还面临不小的挑战，主要体现在内存问题和掉帧的问题，尤其是内存峰值管控的问题，要达到完全对标 Native 开发上是有很多的工作需要去做，希望跟社区的开发者们一起去把 Flutter 的技术去完善的更好，让它变得更加的完美，谢谢大家。
关注公众号请搜索 U4内核技术，即时获取最新的技术动态
