美团外卖前端容器化演进实践( 四 ) _美团

文章插图

6. Block页面的复用问题
在实际的开发中，有些Block的页面View大致上相似，但是逻辑上有些细微的差异，为了快速开发，我们在设计上复用了其视图。Block、BlockView以及ViewModel的关系：一个Block对应一个ViewModel和一个BlockView，一个ViewModel和一个BlockView可以对应多个Block 。

文章插图

计算机界有一句名言：“计算机科学领域的任何问题都可以通过增加一个中间层来解决。”（原始版本出自计算机科学家David Wheeler）相似的，为了视图层的复用，屏蔽数据层的差异，我们在数据层的逻辑中转部分引入一个中间层ViewData，ViewData是为了更好地适配数据模型以及区别视图展示上的差异，这样就大大提高了代码的复用率。
收益
在开发过程中，我们将iOS和Android系统的模块进行了对齐和统一，容器化完成之后，两端同一NativeID对应的模块展示着相同的UI数据，也具有完全一样的业务逻辑。经过容器化后的提单页，相关代码被划分到了33个模块当中，这些模块分别承担着不同的职责。这里按照模块的业务功能、所采用的技术栈和所属业务线将这些容器化后的模块进行划分，得到如下的柱状直方图：

文章插图

文章插图

容器化之后的提单页完全由各模块组成，这些模块可以负责UI展示，也可以不展示任何UI模块，单纯地处理业务逻辑。模块内部的开发方案也可以根据业务形态自由选择，相互之间做到了完全无感知。这些优点为后续提单页的业务迭代和技术优化都提供了很大的空间。
解耦的收益
开发效率提升
容器化之前的提单页，页面各部分共享同一个数据模型，服务端接口数据返回后，在提单页控制器内进行数据的更新、过滤和二次加工之后，再分发给页面上的各模块。当不同的RD同时开发提单页的需求时，这些放置在一起的业务逻辑会提高RD的开发成本，另外很容易出现代码层面的冲突，在需要RD手动解决的同时，也很容易因为开发流程的不规范出现Bug 。
容器化之后的提单页，开发模式也相应发生了改变，RD在开发过程中，不会感知到别的模块内业务需求的改动，各业务可以在各自的容器内进行有效的推进迭代，而不用担心会影响到其他业务，从而让多人协作开发效率得到一定的提升。

文章插图

控制器瘦身
在客户端业务开发的层面，MVC架构得到了广泛应用。容器化重构之前的提单页，虽然也以模块化思想为基础做过多次重构，但是依然深受MVC思想的影响，在提单页控制器内保留了大量业务逻辑的代码。这些业务逻辑的代码最终会在业务迭代过程中逐渐变得臃肿和不可控，最终成为下一次代码重构计划中的业务背景。
本次提单页的容器化改造彻底解决了这一问题。基于PGA框架，包括接口异常处理、数据模型传递和二级页面跳转等业务逻辑代码都被收入到对应的Element和Block中，改造后的提单页中已经不存在业务逻辑相关的代码，彻底杜绝再次出现臃肿页面VC的可能。经统计，iOS侧提单页控制器的代码行数从2894行减少到289行，控制器类中仅包含Block组装的业务逻辑。

文章插图

包体积减少
提单页承载着美团的外卖业务和闪购业务，在未进行容器化之前，两个业务方需要同时向订单库提交代码，在订单库整体“瘦身”的过程中，我们发现这种开发模式让包大小优化的工作多次出现反复，并且统计指标也难以统一和对齐。对提单页进行容器化改造之后，外卖和闪购分别维护各自模块内的代码，相互之间无依赖，闪购侧可以直接在自己的代码仓库内完成提单页模块的新增和修改，不需要再给外卖代码仓库提PR，也就不会对外卖侧的包大小统计产生影响。
动态化的收益
动态化是整个外卖业务的发展方向。提单页的动态化建立在容器化的基础之上，在完成容器化之后，就具备了动态化的基础。当前提单页的动态化，所指的主要是模块层级的动态化，提单页的各模块展示顺序、展示与否，都可以完全由根据服务端下发的数据决定，各模块可以自由地进行组合、拼装，实现提单页的动态配置。