提单页是美团外卖交易链路中非常关键的一个页面。外卖下单的所有入口，包括首页商家列表、订单列表页再来一单、二级频道页的今日推荐等，最终都会进入提单页，在确认各项信息之后，点击提交订单按钮，完成最终下单操作。
虽然提单页的代码统一放在外卖代码仓库中，但根据业务发展的需要，提单页上的模块分别由不同的业务部门去负责维护。主要包括以下业务方：
外卖侧业务
闪购侧业务
其他业务
随着业务的不断迭代，提单页的模块也越来越多，逻辑的耦合也越来越重。现在提单页的UI展示模块已经超过30个，这些模块的展示与否基本上通过服务端的下发数据来决定。在不同的订单类型下，提单页所展示元素的差异越来越大，很多模块的代码已经不适合统一放在一起维护，代码拆分的需求十分强烈。此外，客户端包体积是衡量客户端性能的重要指标，为了解决业务发展带来的提单页代码量急剧增长的问题，同时实现页面元素的动态配置，我们希望能够实现提单页的动态化，而动态化需要基于容器来实现，所以我们提出了提单页的容器方案。
提单页的容器化与外卖首页的动态化有以下几点不同：
容器化后的提单页，需要实现模块之间的互相无感知，根据服务端的下发数据，客户端可以将闪购代码仓库内的模块和外卖代码仓库内的模块拼接起来组成完整的提单页展示给用户。当用户在提单页完成一系列操作时，各模块可以提供必要的参数给服务端。要想实现这一点，我们需要考虑以下几个问题：
容器化是我们在外卖平台化之后对多方业务能力的支持和扩展，在不改变API数据源等前提下，我们保证其具有动态可配置化的能力。为了更好地支撑业务，我们在业务层面抽离出来容器化框架层，其所提供三个部分的核心功能:1.功能节点扩展及通信功能；2.可配置化功能；3.数据分发功能。在最上层业务容器中，目前所支持外卖提单页面模块、闪购提单页模块、提单页Mach（外卖动态化模板）模块、提单页MRN（RN页面）模块四种不同的业务。
在容器化框架设计过程中，我们引入了一些新的定义，比如在Android端引入了Block的概念，这里的Block是一个功能模块的简称。在提单页页面中，我们可以理解为一个Block对应一个功能条目。在iOS端有与之对应的概念Element（由于两者没有差异，下文陈述中用Block代指两者）。
Block有两种类型：其一是普通的Block，其包含BlockView（视图层）和BlockViewModel（数据层）。BlockView（视图层）用来展示具体的视图以及内部的业务逻辑；BlockViewModel（数据层），用来数据解析。其二是LogicBlock，是没有视图的Block，单纯地用来做数据业务处理。
在容器化之前，我们的业务大多是模块化的结构，模块化宿主类是承载所有模块化的管理类，各个模块之间通过宿主类或者控制器进行数据交互。但在容器化改造中，我们将之前宿主类中管理的模块进行拆解，并重新定义了宿主类的职责。在容器化宿主类中，我们将不再持有各个功能模块的引用，而只要持有RootBlock这一个实例，就可以完成对所有功能模块的管理。而RootBlockContext则用来处理父Block与子Block之间的通信以及子Block之间的通信。
第一部分功能节点扩展及通信功能。主要是目前页面的集成和通信关系，其中RootBlock是BlockTree的根节点，下面会挂载一些SubBlock子节点，RootBlock会控制整体的数据流的分发以及整体样式；RootBlockContext可以理解为上下文环境或通信的总线。每个模块都有自己的Context，来维护自己向外部提供数据以及业务逻辑的能力，这些子Context会统一注册到RootContext中进行管理维护。
第二部分可配置化功能。在发起数据请求成功之后，客户端根据注册的Key以及接收到的数据，动态创建Block的容器化能力。遍历解析数据以及配置文件，先动态创建viewModel，将创建好的viewModel绑定到生成的Block模块上，动态添加到RootBlock中。多业务方在完全不用相互感知的情况下，完成对新增模块的开发。
第三部分数据分发。既将解析之后的数据，由RootBlock节点进行数据分发到各个子Block，各子Block的BlockViewModel在更新数据之后并回传到Block中，Block用更新后的数据更新View的展示。其中，数据可以自动完成分发，也可以手动的接管数据流进行相应的处理。
Android是在编译时期，通过APT（注解处理器）的方式，将在指定模块上的注解信息和Block类关联起来，生成Block类对应的工厂类，然后将这些工厂类存在全局的Map集合中，并在运行时进行初始化操作。
@DynamicBinder(nativeId="block_key_d",viewModel=blockDViewModel.class,modelType=blockDInfo.class)NativeID是用来标识Block块的唯一Key，viewModel是用来绑定View视图的数据层，modelType对应着API的数据Model。
iOS使用Kylin注册，Kylin是美团平台开发的基建库，利用Clang提供的section()函数，在编译时Kylin将{kylin_Key,kylin_Data}格式的数据写入到可执行文件的特定数据段中，运行期就可以通过读取指定的Key值获取相应的数据。使用这种方式，注册代码分散在每个组件内部。注册内容：组件native_id、Element名称、viewModel，其含义同上。
注册宏：
#definePGA_ELEMENT_REGISTER(NATIVE_ID,PGA_ELEMENT,PGA_VIEW_MODEL)\KLN_STRING_EXPORT("AppKey_"#NATIVE_ID"","{\""#PGA_VIEW_MODEL"\":\""#PGA_ELEMENT"\"}");3.API数据结构化由于API下发数据的不规范性，需要将数据按照data_key这种数据模式的方式进行整理，然后在获取数据之后，按照规则进行数据解析并创建相应的功能Block。
目前API数据返回的格式：
需要我们将一个模块的数据统一在一个JSON对象中，整理之后API数据返回的格式如下：
布局及位置信息会对应相应的模块视图层，这由另外的layoutInfo字段给出。数组中的每条元素对应每一个Block模块，其中native_id的值是唯一的且与上面Block在注册时候的Key保持一致，data_key的值映射上面整理之后的API数据的Key，这样在编译时期生成Block的时候，就可以动态地关联相应的ViewModel以及数据模型。
{"layout_info":[{"native_id":"order_pay_by_friend","data_key":"pay_by_friend"},{"native_id":"block_container_default",//容器组"children":[{"native_id":"order_flower_cake","data_key":"flower_cake"}]}]}当然，这里可以以组为维度将一些功能相似的模块聚合在一起，native_id的含义同上，Children是子Block结点的数组。
由于之前模块化的时候，我们通过中间类的方式承载各个业务模块的通信逻辑。以Android为例，我们将多个子模块之间需要通信的逻辑，用接口的方式抛到Activity层，由Activity层进行业务逻辑的实现，但是由于子模块众多，最终导致该类的膨胀和模块的高耦合性，难以进行扩展和维护。
在容器化设计的时候，为了更好地使各个业务之间进行通信，降低耦合性，我们引入了BlockContext，同上所述，理解为通信总线。
每个Block都有自己的BlockContext，各个BlockContext汇总到RootBlockContext中去实现，最终，各个Block就可以通过BlockContext进行数据传递。
整体的通信分发图如下：
将所需要的数据包装成事件，在指定的位置驱动事件的执行进而拿到需要的数据。
RootBlock在接收数据的之后，会按照Block结点进行数据的分发。父Block将数据逐次的分发给子Block。
Block创建的顺序由API结构化数据中的layoutInfo数组来决定，layoutInfo数组的具体格式如第三节API数据结构化中内容所示。容器化后的提单页会根据layoutInfo数组的顺序，依次创建对应native_id的Block模块。因此，对于一些基础公共模块（比如wm_confirm_order_logical对应的Block），我们可以将其放在layoutInfo数组的最前面让其提前加载，保证负责UI展示的Block创建时数据可用。
由于提单页的模块比较多，在页面曝光、页面刷新或提交请求时，需要从指定的模块获取相应的数据，作为请求的入参，那么如何做成在不感知其他业务方模块的情况下，完成数据的组装呢？
如上面的通信设计思路，我们利用Event数据交互方式，从各个模块中将需要的数据取出来，完成数据的拼装。其中不同业务场景提取数据需要的校验工作，也分散在各个模块中进行处理。最终，即使在物理层面上隔离了对Block的感知，但是依然可以完成对请求所需数据的获取。
在实际的开发中，有些Block的页面View大致上相似，但是逻辑上有些细微的差异，为了快速开发，我们在设计上复用了其视图。Block、BlockView以及ViewModel的关系：一个Block对应一个ViewModel和一个BlockView，一个ViewModel和一个BlockView可以对应多个Block。
容器化之后的提单页完全由各模块组成，这些模块可以负责UI展示，也可以不展示任何UI模块，单纯地处理业务逻辑。模块内部的开发方案也可以根据业务形态自由选择，相互之间做到了完全无感知。这些优点为后续提单页的业务迭代和技术优化都提供了很大的空间。
容器化之前的提单页，页面各部分共享同一个数据模型，服务端接口数据返回后，在提单页控制器内进行数据的更新、过滤和二次加工之后，再分发给页面上的各模块。当不同的RD同时开发提单页的需求时，这些放置在一起的业务逻辑会提高RD的开发成本，另外很容易出现代码层面的冲突，在需要RD手动解决的同时，也很容易因为开发流程的不规范出现Bug。
容器化之后的提单页，开发模式也相应发生了改变，RD在开发过程中，不会感知到别的模块内业务需求的改动，各业务可以在各自的容器内进行有效的推进迭代，而不用担心会影响到其他业务，从而让多人协作开发效率得到一定的提升。
在客户端业务开发的层面，MVC架构得到了广泛应用。容器化重构之前的提单页，虽然也以模块化思想为基础做过多次重构，但是依然深受MVC思想的影响，在提单页控制器内保留了大量业务逻辑的代码。这些业务逻辑的代码最终会在业务迭代过程中逐渐变得臃肿和不可控，最终成为下一次代码重构计划中的业务背景。
提单页承载着美团的外卖业务和闪购业务，在未进行容器化之前，两个业务方需要同时向订单库提交代码，在订单库整体“瘦身”的过程中，我们发现这种开发模式让包大小优化的工作多次出现反复，并且统计指标也难以统一和对齐。对提单页进行容器化改造之后，外卖和闪购分别维护各自模块内的代码，相互之间无依赖，闪购侧可以直接在自己的代码仓库内完成提单页模块的新增和修改，不需要再给外卖代码仓库提PR，也就不会对外卖侧的包大小统计产生影响。
动态化是整个外卖业务的发展方向。提单页的动态化建立在容器化的基础之上，在完成容器化之后，就具备了动态化的基础。当前提单页的动态化，所指的主要是模块层级的动态化，提单页的各模块展示顺序、展示与否，都可以完全由根据服务端下发的数据决定，各模块可以自由地进行组合、拼装，实现提单页的动态配置。
之前因为历史原因，提单页很多的功能模块，Android和iOS在实现上大相径庭，完全不一样的实现让两端在新业务需求到来时，在与服务端接口对接、开发工时和开发方案上都存在很大的差异，这些差异点对产品需求的排期、开发和测试上线上都产生了很多负面的影响。
提单页在容器化后的另外一项收益，就是Android和iOS在模块层级的代码实现，完成了统一。借助于PGA框架和Element注册机制，Android和iOS具有大致相同的模块结构，相同native_id的模块获取的API接口返回字段完全一致；在页面请求接口数据时，相同ID的模块也提供同样的数据字段。在后续的开发过程中，两端对API接口字段的请求趋于一致，可以最大程度地减少因为两端不一致带来的合作方开发成本，也可以在一定程度上减轻下游的测试压力。
外卖客户端一直在推动核心页面的标准化，同时一直在探索尝试让核心页面也具备动态化能力。提单页作为下单路径上的核心页面，在PGA框架的基础上完成了容器化重构。至此，外卖首页、点菜页和提单页在页面这一层级都统一使用PGA框架实现。统一化和标准化之后，可以让编程风格趋于一致，代码结构在不同平台保持统一，在后续的需求开发中，可以有效减少因为两端实现不一致出现的隐性开发成本。
提单页在容器化之后，让区域动态化的技术演进更容易推进。模块之间的解耦让不同模块可以自由选择模块内使用的技术栈而不会对其他模块产生影响。对于提单页的部分模块，完全可以通过Mach或者RN等动态化方案来实现，通过区域动态化来进一步减少开发成本，提高业务需求的开发效率。
在提单页之后，客户端会继续推进订单状态页使用PGA框架实现容器化，让标准化框架对用户下单路径上的核心页面实现100%覆盖。同时积极在提单页的商家商品信息展示、放心吃、准时保等模块探索页面的部分区域动态化，进一步缩减包大小，提高开发效率。
1.Mach(马赫)是外卖终端组自研的多终端跨平台级的局部动态化技术。
2.MRN是美团基于React-native0.54.3进行的二次封装，抹平了两端上的差异，并且提供了一些基础库和组件库供业务开发同学使用。
3.Metrics是美团平台团队和外卖团队，开发的新一代App性能采集、监控、统计平台。
李肖、廷瑞、彦平、同同均为美团外卖团队工程师。
美团外卖长期招聘Android、iOS、FE高级/资深工程师和技术专家，Base北京、上海、成都，欢迎有兴趣的同学投递简历到tech@meituan.com。