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

杨利霞

) K, W( [4 ?  z. S& F统一架构——优酷主客的标准化开发之路一、超级 APP 的标准化
% c. @- z- z3 I; ]
在技术领域，标准化有很多很好的实践案例。比如服务端容器的出现，应用的构建、分发和交付得以在容器层面上实现标准化，提升了业务创新的效率。
6 Z, k' [, Z. S0 z2 F! e& I( q, g
. d, l2 M+ C7 D: U9 H$ \+ p那么一个客户端应用的标准化是什么呢？一个业务需求通常可以拆解为功能需求，设计需求，体验需求，数据需求和运营需求，而每一种需求都对应着一类开发工作。

+ `. M) y, ~! p4 M7 W% s$ ?通过对每一类开发工作进行分析研究，我们得出了一个结论，客户端开发的标准化是运行时环境一致，视觉效果统一，遵守相同的数据协议，用相同的方法搭建，投放和获得用户反馈的标准化。具体抓手则是以渲染架构标准化为核心的一系列标准化设计和工作。

8 g: [6 g- `7 |" R2 ^4 P二、优酷的标准化实践
  A/ y* W' n3 \
8 N' L2 y2 s) o9 b1 x9 {$ N1．渲染架构标准化
9 Q! S' x  _. A! T
通常一个应用是由一个一个页面组成的，而页面是由什么组成的呢？

5 ~' `& n5 E6 l& w/ y( n/ E7 e$ ]. e我们可以大致分为三个部分：数据，组件和服务。

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

8 X( F( P0 T9 z5 {4 Z数据需要贴合业务，如果有一个环节的格式定义出现差异，最终的结果可能就会大不相同，而刷洗数据，转化格式又会带来效率上的降低。而对统一架构和标准化组件来说，我们又希望数据的格式和字段是一致的。如何来解决这一对矛盾获得最优解呢？
& R; Z9 C) @! _& }6 _- D- C
. Q: \4 N+ P+ c  C4 O& S我们从两个方向进行了尝试，一个是在页面搭建方向上，推进了服务端的数据协议的标准化，之前服务端的数据模型大致都是 page-module-component-item 的多层嵌套结构，它对应了运营同学在搭建页面时，从整体到局部到细节的设计思路和操作行为。我们的标准化思路就是虚化节点定义，明确节点结构。虚化节点定义的意思，我们不再以 page，module 等有具体意思和层级关系的名称作为节点 tag，而是统一为 Node。这样原本有层级关系的结构，就变成了可以任意嵌套的结构。而对于 Node，明确其内部为 level，data[]，style[] 和 subNodes[] 等含义明确的标准化结构。而在组件渲染方向上，我们将数据结构演化抽象为从 PO-DTO-DO-VO【备注】的过程。而我们在 VO 这一层去抹平之前的协议差异。

6 n1 n0 D" ?! b8 m4 H1）组件是页面的表，直接响应用户体验。组件的核心设计原则是组件在不同页面上的复用，为此我们将组件的内部实现分解为 Model，View 和 Presenter 三个部分，各部分之前只以 Contract 约束接口定义。这样三类模块都可以进行不同实现的组合和替换，我们刚才说的在 VO 抹平数据协议差异，就是通过配置不同的 Model 完成的。此外，我们在组件的布局管理使用了 vLayout 的布局混排能力，在配置上通过文件配置进行布局样式上配置和组件 MVP 的搭配，还提供了组件间的通信能力。这些标准化接口的提供，统一了组件的使用环境，大大降低了组件的 UI 开发的难度。
! h2 h& P6 n: i3 l6 K; D
2）服务是页面的神，有了服务页面才是活的。对于服务我们抽象为域内服务和域外服务，域内服务指的是页面范围的视觉动作，比如组件的插入，删除，刷新，加载更多等，这部分能力我们在数据域对象提供了内置的方法，而域外服务则是指对业务中间件和应用基础能力的调用，对于这部分调用，我们在服务能力标准化再介绍。

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


2. 设计体系标准化

$ Y4 J  N3 _* w# }" P, p( t5 C客户端用户界面一致性是设计体系标准化需要关注的核心问题，保证一致性和体验品质，并实现设计开发的工作提效，是“设计语言标准化管理体系”的建设的核心诉求。为此，我们联合设计一起，从零创立了优酷自己的设计体系。我们为设计体系设定了核心目标：建立设计语言的标准化管理体系，改变设计与开发生产模式，实现设计与开发的品质和效率提升。

/ V% c, u1 A! I为了完成这个目标，我们进行了很多工作。设计同学对全站的现有设计进行了盘点，统一设计和技术对界面元素的认知体系，定义了设计规范。开发同学建立了标准化组件库，以视觉规范为基础，把设计侧的规范文档及组件库，通过一种协作语言形成设计与技术的映射关系，实现客户端设计组件与技术组件的统一拉通，沉淀成统一的 SDK 共同维护。而协作语言的确立，标志着标准化的工作的具象，从根本改变了之前设计开发的工作流程。

以往开发实现过程中，研发代码中会写原始属性值，而这个写的过程本身就是孤立的，非标准化的，而现在研发以引入 Design Token 的方式，把视觉样式的代码进行统一管理，形成统一的研发组件库，各业务线可以直接调用，收拢了散落各处的代码。Token 最终会对应什么样的呈现，完全基于标准规范。而通过对规范的调整，可以对应用整套设计进行体系化的调整
1 J3 Q0 R9 ]7 y0 D
" O/ ]3 s% J' b/ W' F( b! ~
8 V- H: V% |, ^* i3 [+ `
3. 服务能力标准化
1 D5 @1 B7 d6 m# A* a8 ~
渲染架构的标准化有一个重要的设计就是将服务和渲染分离开。

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

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

% a: p1 `5 K; c6 u5 U1）未标准化之前。
9 G0 \3 l( b1 i' z, `8 i


  w5 {1 b9 p) e" \, S通过一系列的标准化工作，实际上改变了业务需求的开发的模式。

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

2）从开发的角度看，开发只需要关注组件的个性化需求实现，而可以复用大部分代码。组件开发上，有公共组件库提供从属性到布局多个维护的标准化实现，而且由于在框架层面的隔离，所有的布局和大部分的卡片都是可以复用的，UI 的复用可以使产品需求的实现只需要关心产品的业务逻辑实现。而且组件是自我独立的，和外部容器之间没有直接引用，所以可以在任何环境下正常工作。经过一定时间的积累和沉淀，我们将会有支持大部分 UI 的布局卡片库。而对于能力的调用我们也提供了标准化的调用接口，开发同学不再需要关注最终具体的实现，只需要关注接口本身可以提供的能力即可。
  K/ C" Y+ i  R# q# I
% |: I8 B8 S# }- m  o3）对于产品和运营，统一的配置平台，组件产品全站拉通，都给了他们更低的成本和更好的收益，而设计开发效率的提高也增强了产品试错和复制成功经验的能力。
; k. y* z' R/ W7 p4 t6 M
4）在实际收益上，渲染标准化之后我们已经积累十余个通用组件，节约了垂类业务的开发人力，研发效率提高了 40%。我们的用户体验优化的项目中，比如异步加载，轻量化等等都通过标准化快速落地到了每一个业务场景，将之前两三个月的落地周期缩短到了两个迭代。再如设计标准化，为暗黑模式的快速完成，提供了技术基础，使之前一个月全员投入的需求在两周之内完成上线。
; @8 Q$ D, O% R7 r
我们的架构设计成果，还在促进着阿里集团其他应用的标准化，比如来疯等独客在接入后，一次开发，可以快速在优酷，来疯，虾米等多个应用投放。

: A& O- B0 G- A. l7 {/ d8 Z2 r$ v备注：
  L1 I0 T# D) }5 `# [; ?" @
& F) V/ M  r1 Y7 dPO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应 PO 的一个（或若干个）属性。
1 z+ t" Y# l& d5 N7 `1 G' z
. v& L) V: t7 v3 D, bVO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

6 v% t9 D! F8 }8 Z* a6 J9 MDTO（Data Transfer Object）：数据传输对象，泛指用于展示层与服务层之间的数据传输对象。
3 b5 x: k/ S. O" Q: j) H" z! S( {& F
DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。

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

, a& {) z/ y3 v. g6 o( S————————————————
  @1 N' ?4 v" v7 s版权声明：本文为CSDN博主「阿里巴巴文娱技术」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
! n* _& s4 X& l" E3 [原文链接：https://blog.csdn.net/alienttech/article/details/106167060