统一架构——优酷主客的标准化开发之路

杨利霞

- ^( G. t/ p/ x* y7 \# |统一架构——优酷主客的标准化开发之路一、超级 APP 的标准化
: \) Z9 G1 v) l# c, N3 @6 X
2 I  ?5 M  N1 z* {' E& L1 t: Z. r在技术领域，标准化有很多很好的实践案例。比如服务端容器的出现，应用的构建、分发和交付得以在容器层面上实现标准化，提升了业务创新的效率。

( U# w% _  q4 o& O3 h4 e/ [那么一个客户端应用的标准化是什么呢？一个业务需求通常可以拆解为功能需求，设计需求，体验需求，数据需求和运营需求，而每一种需求都对应着一类开发工作。
0 }, |# o: u5 A4 ^& I
通过对每一类开发工作进行分析研究，我们得出了一个结论，客户端开发的标准化是运行时环境一致，视觉效果统一，遵守相同的数据协议，用相同的方法搭建，投放和获得用户反馈的标准化。具体抓手则是以渲染架构标准化为核心的一系列标准化设计和工作。
/ I/ M9 m$ \+ k2 w
) k2 Y. J$ ]7 w" ]0 w* L二、优酷的标准化实践

: C9 E8 ~4 Z2 V* B+ t1．渲染架构标准化

# V" W, w+ p9 D通常一个应用是由一个一个页面组成的，而页面是由什么组成的呢？

1 z% `6 F" Q+ V: H6 y我们可以大致分为三个部分：数据，组件和服务。

1 n: C; X# b# w' H# m- R0 D数据模型是业务模型的抽象化产物，是页面的里，它的结构来源于业务的需要，影响着组件的实现。数据从媒资，算法等生产源头通过 CMS（内容管理系统）汇聚而来，通过网络以字节流传输到客户端，客户端下载，解析，转换成对象，或统一保存，或组织分发给每一个显示单元，从而完成其从生产到消费漫漫征途。

$ r6 y$ X0 b" W& n1 `) g9 m数据需要贴合业务，如果有一个环节的格式定义出现差异，最终的结果可能就会大不相同，而刷洗数据，转化格式又会带来效率上的降低。而对统一架构和标准化组件来说，我们又希望数据的格式和字段是一致的。如何来解决这一对矛盾获得最优解呢？
; z% z/ ]5 t' U
我们从两个方向进行了尝试，一个是在页面搭建方向上，推进了服务端的数据协议的标准化，之前服务端的数据模型大致都是 page-module-component-item 的多层嵌套结构，它对应了运营同学在搭建页面时，从整体到局部到细节的设计思路和操作行为。我们的标准化思路就是虚化节点定义，明确节点结构。虚化节点定义的意思，我们不再以 page，module 等有具体意思和层级关系的名称作为节点 tag，而是统一为 Node。这样原本有层级关系的结构，就变成了可以任意嵌套的结构。而对于 Node，明确其内部为 level，data[]，style[] 和 subNodes[] 等含义明确的标准化结构。而在组件渲染方向上，我们将数据结构演化抽象为从 PO-DTO-DO-VO【备注】的过程。而我们在 VO 这一层去抹平之前的协议差异。
1 E0 ~$ k* P9 J7 h6 e9 }* i
1）组件是页面的表，直接响应用户体验。组件的核心设计原则是组件在不同页面上的复用，为此我们将组件的内部实现分解为 Model，View 和 Presenter 三个部分，各部分之前只以 Contract 约束接口定义。这样三类模块都可以进行不同实现的组合和替换，我们刚才说的在 VO 抹平数据协议差异，就是通过配置不同的 Model 完成的。此外，我们在组件的布局管理使用了 vLayout 的布局混排能力，在配置上通过文件配置进行布局样式上配置和组件 MVP 的搭配，还提供了组件间的通信能力。这些标准化接口的提供，统一了组件的使用环境，大大降低了组件的 UI 开发的难度。
1 V* d: }! A' y: {0 l) I
2）服务是页面的神，有了服务页面才是活的。对于服务我们抽象为域内服务和域外服务，域内服务指的是页面范围的视觉动作，比如组件的插入，删除，刷新，加载更多等，这部分能力我们在数据域对象提供了内置的方法，而域外服务则是指对业务中间件和应用基础能力的调用，对于这部分调用，我们在服务能力标准化再介绍。

在渲染架构标准化的设计中，我们强调了解耦，而这对配置化的实现也带来了便利。通过对页面布局能力的拆解，对组件 MVP 的结构设计，渲染标准化架构把一个组件拆解成了这个组件的容器，容器的 adapter，组件的 MVP 部件，组件交互需要的领域能力，组件交互需要的基础服务等独立部分，可以自由配置组合。在组件承载的业务上，我们也通过代理来进行配置，代理可以拿到页面的上下文，监听业务的消息进行响应，不同的使用场景都遵循着相同规则。


) o) ~: O) T; F$ h- w* w  E' m2. 设计体系标准化
  [2 ?& B$ q/ I8 v4 p! G1 ~  l3 x
客户端用户界面一致性是设计体系标准化需要关注的核心问题，保证一致性和体验品质，并实现设计开发的工作提效，是“设计语言标准化管理体系”的建设的核心诉求。为此，我们联合设计一起，从零创立了优酷自己的设计体系。我们为设计体系设定了核心目标：建立设计语言的标准化管理体系，改变设计与开发生产模式，实现设计与开发的品质和效率提升。

为了完成这个目标，我们进行了很多工作。设计同学对全站的现有设计进行了盘点，统一设计和技术对界面元素的认知体系，定义了设计规范。开发同学建立了标准化组件库，以视觉规范为基础，把设计侧的规范文档及组件库，通过一种协作语言形成设计与技术的映射关系，实现客户端设计组件与技术组件的统一拉通，沉淀成统一的 SDK 共同维护。而协作语言的确立，标志着标准化的工作的具象，从根本改变了之前设计开发的工作流程。
5 `' h8 h9 ~" @$ @- H
以往开发实现过程中，研发代码中会写原始属性值，而这个写的过程本身就是孤立的，非标准化的，而现在研发以引入 Design Token 的方式，把视觉样式的代码进行统一管理，形成统一的研发组件库，各业务线可以直接调用，收拢了散落各处的代码。Token 最终会对应什么样的呈现，完全基于标准规范。而通过对规范的调整，可以对应用整套设计进行体系化的调整



3. 服务能力标准化
/ W  w4 \7 i1 i& d, h
5 V/ }0 l4 z% I" N# q* N! C渲染架构的标准化有一个重要的设计就是将服务和渲染分离开。

不同业务模块，一般都会依赖不同的中间件，按照之前的服务和渲染耦合的设计，相同的服务能力在不同业务模块间往往实现多次，这既增加了学习成本，形成技术壁垒，也使代码结构脆弱和臃肿。而且服务的接入成本高，迭代成本也高，冗余的代码既影响了编译速度，更影响了启动速度。

1 {6 Q  b0 C9 Y, ^- Q为此，我们设计了标准化的服务接口和服务中间层，每个模块都通过调用服务中间层的标准化接口，来获得或者触发服务。这既使渲染和服务解耦，也完成了中间件之间的接耦，形成了高内聚低耦合的架构层次。

1）未标准化之前。

2 e8 w% f' I, b  v5 W  y

; D  g9 n: ]* m1 ]$ m* I通过一系列的标准化工作，实际上改变了业务需求的开发的模式。

5 j$ k  A8 K( O. M& `) E1）从设计的角度看，现在的设计首先考虑的整体的设计规范，然后才是个性化需求的表达，从设计的输出物上看，不再是基于数值的标注，而是基于协作语言的标注，对于最终的效果，设计在设计开发阶段就可以有明确的感知，不再需要逐个元素和开发细调，解放了人力。

2）从开发的角度看，开发只需要关注组件的个性化需求实现，而可以复用大部分代码。组件开发上，有公共组件库提供从属性到布局多个维护的标准化实现，而且由于在框架层面的隔离，所有的布局和大部分的卡片都是可以复用的，UI 的复用可以使产品需求的实现只需要关心产品的业务逻辑实现。而且组件是自我独立的，和外部容器之间没有直接引用，所以可以在任何环境下正常工作。经过一定时间的积累和沉淀，我们将会有支持大部分 UI 的布局卡片库。而对于能力的调用我们也提供了标准化的调用接口，开发同学不再需要关注最终具体的实现，只需要关注接口本身可以提供的能力即可。
" Y8 w7 W2 E) w
3）对于产品和运营，统一的配置平台，组件产品全站拉通，都给了他们更低的成本和更好的收益，而设计开发效率的提高也增强了产品试错和复制成功经验的能力。
, A. k) u8 y8 b
  K+ p4 g+ |' A5 c4）在实际收益上，渲染标准化之后我们已经积累十余个通用组件，节约了垂类业务的开发人力，研发效率提高了 40%。我们的用户体验优化的项目中，比如异步加载，轻量化等等都通过标准化快速落地到了每一个业务场景，将之前两三个月的落地周期缩短到了两个迭代。再如设计标准化，为暗黑模式的快速完成，提供了技术基础，使之前一个月全员投入的需求在两周之内完成上线。
/ @' M  o0 U! q, t
; E% W. j6 E+ X2 i我们的架构设计成果，还在促进着阿里集团其他应用的标准化，比如来疯等独客在接入后，一次开发，可以快速在优酷，来疯，虾米等多个应用投放。
1 d6 A+ u  Q* z
9 E( W$ K- E+ L% t' I0 D备注：
2 Y( k' Y' T0 x+ I  t0 f
0 p+ M! }- E/ q+ E' iPO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应 PO 的一个（或若干个）属性。
6 o9 g! f3 A6 H+ P/ P$ v+ T
VO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

DTO（Data Transfer Object）：数据传输对象，泛指用于展示层与服务层之间的数据传输对象。

DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。

作者 | 阿里文娱无线开发专家 涵父

————————————————
版权声明：本文为CSDN博主「阿里巴巴文娱技术」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
6 s. D5 |. H2 `" M8 n, Y& j原文链接：https://blog.csdn.net/alienttech/article/details/106167060
/ l9 @7 I4 R# J% i; O7 U