全新大前端业务开发模式：提升60%产研效率，还保留原生体验

嘉宾 | 廖子尧

编辑 | 邓艳琴

我想要兼顾性能和效率，这可能吗？美团平台或许找到了一个不错的答案：MBC 业务标准化容器方案。目前该方案已经大面积应用在美团平台业务，在千万级流量以上页面得到了验证：从方案上线起，在保持了原生体验的同时也为业务带来了 50% 的人力成本减少与 60% 的产研效率提升。

近日，InfoQ 邀请到美团技术专家廖子尧接受采访，他从零到一搭建了 MBC 移动业务容器的动态化解决方案。他还将在 GMTC 全球大前端技术大会（北京站）2021 分享该方案的搭建思路与已有业务标准化改造过程中的攻艰方案。

 InfoQ：可否给我们介绍下 MBC 业务标准化容器方案？包括它的原理、落地规模和提效成果。

廖子尧：随着美团业务的快速发展，产品形态越来越多元化，业务迭代速度更加频繁，在保障用户体验的前提下，为了更好的支持产品诉求，迫切需要一套业务架构，既能满足良好的用户体验，还能提高业务的研发效率，那么 MBC 方案便呼之欲出。

MBC 全称为美团业务标准化容器 (Meituan Business Container)，旨在以标准化为基础，通过提供配置化的能力，在客户端尽可能不发版的情况下，动态孵化并上线新 Native 页面的一套解决方案。该方案整体分为 MBC 协议层、服务端容器、客户端容器、配置化平台这四大块，其中协议是基石，我们在不同环节都制定了标准规范，典型的包括：前后端数据交互协议、页面框架协议、埋点数据协议、自动化测试协议等。服务端容器与客户端容器分别是这套标准协议的生产者与消费者，最后为了进一步提高研发效率，又搭建了配置化平台，可以将设计稿自动转化成代码，完成业务逻辑与数据的绑定、可视化埋点配置、自动化测试等工作，最终实现模块天级动态上线。

目前 MBC 方案在美团平台业务已经大规模应用起来，「美团首页」、「消息」、「我的」等千万级流量以上的页面覆盖度达到 100%，其他二级入口页面覆盖度达到 50%。从该方案上线起，在保持了原生体验的同时也为业务带来了 50% 的人力成本减少与 60% 的产研效率提升。

 InfoQ：你认为这个方案最大的创新点是什么？

廖子尧：该方案打破了原有的开发模式，通过业务建模、标准化约束，使产研在页面结构变更、功能模块调整、UI 样式修改、数据埋点添加等多个环节可以通过配置能力形成闭环，以此来提升研发效率，缩短业务上线周期。比如在该方案上线之前，客户端的样式变更通常需要接口字段来控制，这就需要后端一起配合才能实现。该方案上线后，增加了中台适配层，客户端会亲自参与中台开发，在遵循 MBC 协议的基础上自己给客户端开发接口，这样沟通成本更小，更灵活，而且可以返回更加符合客户端诉求的数据。此外，该方案上线前，没有工具能协助不同角色之间的配合，角色职能交叉，比如数据同学需要的业务埋点是 RD 来手动开发的，该方案上线后，RD 可以专注于功能代码开发，数据同学专注于业务埋点配置，各自负责自己专业的事，大大减少沟通成本，提升业务研发效率。

 InfoQ：是什么样的痛点驱使你们做了这样一套东西？在它诞生之前，你们的方案是什么？

廖子尧：首先作为美团平台业务团队，维护着平台最大的流量入口「首页」，也支撑着各业务的发展，我们最主要的职责就是将入口流量高效地分发到各业务中，带动收入增长。所以我们是一个用户流量大、重展示、重策略、轻交互的业务团队，对我们的要求就是性能优异、样式灵活、快速交付、埋点可靠。为了确保性能优异，我们一直都是采用原生 Native 进行开发，其中美团的动态布局（MTFlexbox）就是在该场景下孵化的一套模块级样式动态化方案，像一些 Feed 流的卡片样式，优选专区模块等，都是使用动态布局实现的。但动态布局具备一定的局限性，无法满足页面级的结构变化，无法动态孵化新页面，导致首页的大量需求和其他新增页面的需求都需要发版才能上线，延缓了产品的迭代速度，这是其一；其二是不同模块间的卡片样式即使相似也都需要重新开发，复用程度差，缺乏配置化的手段降低开发成本；其三是各个角色之间的沟通成本高，导致上线效率低。基于以上三点，我们期望寻求一种开发成本低、上线效率快、动态力度大的高性能解决方案，最终孵化出了 MBC。

 InfoQ：你们是怎么想到要用 MBC 业务标准化容器方案的？有考虑过其他方案吗？为什么放弃了其他选项？

廖子尧：MBC 容器方案可以说是我们业务在迭代发展过程中一个必经之路，当然我们也考虑了其他方案，比如美团内部的 MRN 框架、Agent 框架、Flutter 等。我们选用方案首先要考虑的是稳定性和性能，因为这个方案是需要在美团首页进行使用的，首页是用户的必经入口，因此对启动耗时增长、FPS 降低、Crash 等指标要求较高。第二看中的是动态性问题，首页作为承接流量的入口页面，避免不了大量的线上实验，而首页的实验最多的是与 UI 样式相关的实验，所以我们需要一定的动态性，但是不需要像 H5、React Native、小程序这样这么丰富的动态能力。第三看中的是效率问题，一般的技术框架都是在前面提到的两点之间做平衡选择，而我们还期望进一步从流程上解决根本问题，降低开发成本与沟通成本，这是目前任何一个技术框架都不具备的。我们要做的事情就是把产研流程与技术框架进行深度融合，在性能、动态性、效率之间达到一个很好的平衡点。

 InfoQ：从想法到落地，大概经过了几个阶段？有里程碑事件吗？

廖子尧：该项目从 2019 年 1 月份立项开始，至今主要经历了三个大阶段。

第一个阶段是验证阶段（至 2019 年 6 月）：由于 MBC 方案涉及到客户端参与中台开发，这在以前是没有过的，为了验证可行性，需要通过一个实际项目将想法用最低成本落地，看看会遇到哪些困难，在这个阶段中，我们主要完成了 MBC 标准协议的制定、服务端动态容器的上线、动态布局样式库的上线，初步通过「我的」页面完成了全流程的可行性。

第二个阶段是实施阶段（至 2020 年 2 月）：主要是增强 MBC 的动态性并打造产研流程闭环，该阶段完成了客户端动态容器的上线和配置化平台的上线。

第三个阶段是提效阶段（至今）：为进一步降低线下开发成本，我们研发出了一种使用 UI2Code（设计稿自动生成代码）生成动态布局样式模板的方案，并集成进配置平台，具备了完全 0 代码开发，快速上线新功能的能力。

 InfoQ：最难的是哪个阶段？你们是怎么扛过来的？

廖子尧：最难的可能是第二阶段时，项目刚落地后的推广阶段，每个新项目的落地总会面临无数的质疑与挑战。我们也不例外，新的研发模式下，客户端要参与中台的开发给自己定制接口、UI 同学可以在线调整 RD 开发的模板以确保对设计稿的还原度、数据 PM 需要在模板上线前配置埋点来保证数据的准确性等，这些流程都是和以前不太一样的点，好像每个人的工作都多了一点。但其实一个完善的流程正常运转起来后，对效率的提升是非常巨大的，就像工厂流水线一样，如果工人都扎堆到一起通过口头交流的方式生产产品，不仅质量不高，效率也会很低下，流水线方式就是充分发挥了每一个员工的优势，划清职责，用专业的人做专业的事。刚开始大家都会怀着质疑和试一试的态度来尝试一遍，只要经历过几次需求上线的检验，疑虑就会打消，只要有了一个成功的经验，后续的推广就会更加容易。

 InfoQ：对于工程化领域，要去评估和量化某一个方案的效果，其实是一个难点，除了主观体验之外，我们还需要一些客观的数据来做支撑，那么你们是否建立了一套评估标准体系？

廖子尧：是的，一个方案的好坏，能否被推广和大规模应用，一定是有衡量指标的，我们主要是从性能指标、线下效率、线上效率三个维度进行了评估。

首先是性能指标：由于 MBC 是纯 Native 的方案，我们要求使用 MBC 和纯 Native 能达到完全一致的性能体验，主要指标包括滚动 FPS、缓存渲染时间、网络渲染时间、首屏渲染时间、端到端耗时等，让性能不成为业务的掣肘。

其次是线下效率：线下我们最关注的是新流程下不同角色间的配合成本、沟通成本以及开发成本。所以针对每个需求，我们从评审、开发、测试、验收这 4 个阶段分别进行统计，数据主要通过需求管理平台和 MBC 配置平台获取。

最后是线上效率：一是线上策略的变更成本，二是孵化新页面新模块的成本，我们也按照动态性、双端一致性、开发成本、上线成本等多个维度来衡量。

最终我们发现，MBC 方案的性能有着与原生 Native 完全一致的表现，同时 MBC 方案的需求覆盖力度达到了 70%，产研效率提升明显。

 InfoQ：MBC 业务标准化容器方案适用于哪些场景？如果其他团队想参考你们的方案，你是否有一些建议？

廖子尧：MBC 方案诞生的初衷是为了解决重展示轻交互的大流量入口级页面动态性不足的问题，后续经过发展和优化，除了业务交互非常复杂的页面不太适合外，基本所有的列表型页面都可以适用，以下是一些比较常见的适用场景：

• 团队对页面的性能要求和稳定性要求较高，还期望有不错的动态能力的
• 业务以展示为主的，诸如列表型首页、商品列表页、Feed 流页面、搜索页面等
• 后端接口模型稳定，但客户端技术方案、展示样式多变的
• 现有的产研流程配合效率成为了业务发展的瓶颈，也不妨尝试一下，也许会有新的发现

在使用我们方案的过程中，首先团队的技能边界会多样化，每个客户端同学都会对服务端开发技能有所了解，因为服务端是 Java 开发，所以 Android 同学会比较容易，而 iOS 在初期会有一定的学习成本，但是付出一定是大于收获的，需要时间的检验。其次 MBC 标准化方案可以统一客户端不同的业务场景，后期只需维护一套架构，而且是双端一致的，成本更小。

 InfoQ：接下来的迭代方向，能透露一下吗？

廖子尧：目前 MBC 方案主要在向三个方面努力：

• 更强的逻辑动态化能力：MBC 方案的性能是它的第一优势，但是逻辑动态化没有 React Native、小程序这种纯动态化的方案灵活，后续将在保证性能的基础上，将动态化能力进行提高
• 更完善的配置能力：目前我们已经完成业务模块级的产研配置闭环，实现了模块 0 代码开发、天级配置上线的要求，页面级产研配置闭环正在规划中，实现后存量和增量的页面都可以进行在线配置下发，实现数据和样式的千人千面
• 更小的上手成本：从现在的客户端参与中台开发，优化成客户端参与中台配置，同样 0 代码开发，完成后端接口的上线

 InfoQ：7 月初，你会在 GMTC 北京 2021 分享这个全新方案，如果要给自己的演讲写一段推荐语，你会怎么写？

廖子尧：MBC 方案提供了一个新型的产研配合思路，可以在保证性能的同时提升产研配合效率，并且经历了千万级用户与时间的检验，目前在美团平台业务中广泛使用。如果你正在为迭代效率发愁，为在动态性、效率、性能之间寻找一个平衡点，那么可以看看 MBC 方案的思路，通过建立标准，再使用流程化、工程化、配置化的手段为业务带来价值，相信会为你打开一片新大陆。

嘉宾简介

廖子尧，2017 年 10 月加入美团，先后负责过美团首页、美团大搜的架构优化工作。从零到一搭建了 MBC 移动业务容器的动态化解决方案，该方案致力于降低开发成本、提升上线效率，打造高效的产研流程闭环，目前已在美团平台业务内大范围使用。

 活动推荐

GMTC 全球大前端技术大会（北京站）将于 7 月 4-5 日落地北京国际会议中心。大会设置了跨端技术、Flutter 技术探索与实践、小程序开发实践、大前端工程化提效、Serverless 业务场景落地、前端团队管理、前端框架等 16 个热门专题，现场近百位资深技术专家，与你相约北京国际会议中心。

点击【阅读原文】或识别二维码了解更多关于 GMTC ，目前 9 折购票中，购票立减 480 元，团购还有更多优惠！有任何问题欢迎联系票务小姐姐 ：13269078023（微信同电话）

点个在看少个 bug👇