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

杨利霞

( f  P& j* E3 j* f9 y* [统一架构——优酷主客的标准化开发之路一、超级 APP 的标准化
0 z6 M* ~" k7 i/ N
在技术领域，标准化有很多很好的实践案例。比如服务端容器的出现，应用的构建、分发和交付得以在容器层面上实现标准化，提升了业务创新的效率。

那么一个客户端应用的标准化是什么呢？一个业务需求通常可以拆解为功能需求，设计需求，体验需求，数据需求和运营需求，而每一种需求都对应着一类开发工作。

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

二、优酷的标准化实践
9 d) w. c8 ^) V# _
1．渲染架构标准化
9 F" k$ m& Q6 n' Y
8 w  X1 V! Y5 }8 c6 q2 V通常一个应用是由一个一个页面组成的，而页面是由什么组成的呢？
0 o$ D, V6 }( B  l* i5 a9 Y2 j/ j
我们可以大致分为三个部分：数据，组件和服务。
% b$ [3 r0 U: x/ D5 B) G( g
, ?( o/ \, F) F" Z/ a+ O数据模型是业务模型的抽象化产物，是页面的里，它的结构来源于业务的需要，影响着组件的实现。数据从媒资，算法等生产源头通过 CMS（内容管理系统）汇聚而来，通过网络以字节流传输到客户端，客户端下载，解析，转换成对象，或统一保存，或组织分发给每一个显示单元，从而完成其从生产到消费漫漫征途。

& w. i6 i# Z' C/ R% s8 W数据需要贴合业务，如果有一个环节的格式定义出现差异，最终的结果可能就会大不相同，而刷洗数据，转化格式又会带来效率上的降低。而对统一架构和标准化组件来说，我们又希望数据的格式和字段是一致的。如何来解决这一对矛盾获得最优解呢？

. H/ k3 S0 \5 F& T0 N! J- k我们从两个方向进行了尝试，一个是在页面搭建方向上，推进了服务端的数据协议的标准化，之前服务端的数据模型大致都是 page-module-component-item 的多层嵌套结构，它对应了运营同学在搭建页面时，从整体到局部到细节的设计思路和操作行为。我们的标准化思路就是虚化节点定义，明确节点结构。虚化节点定义的意思，我们不再以 page，module 等有具体意思和层级关系的名称作为节点 tag，而是统一为 Node。这样原本有层级关系的结构，就变成了可以任意嵌套的结构。而对于 Node，明确其内部为 level，data[]，style[] 和 subNodes[] 等含义明确的标准化结构。而在组件渲染方向上，我们将数据结构演化抽象为从 PO-DTO-DO-VO【备注】的过程。而我们在 VO 这一层去抹平之前的协议差异。

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

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

4 W7 }% A! H& a7 p0 D/ i
/ K9 Y( }( J' g. G' p2. 设计体系标准化

" {% O" |+ L9 Y客户端用户界面一致性是设计体系标准化需要关注的核心问题，保证一致性和体验品质，并实现设计开发的工作提效，是“设计语言标准化管理体系”的建设的核心诉求。为此，我们联合设计一起，从零创立了优酷自己的设计体系。我们为设计体系设定了核心目标：建立设计语言的标准化管理体系，改变设计与开发生产模式，实现设计与开发的品质和效率提升。

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

6 _* R9 L* L5 H' Q7 f3 T* _以往开发实现过程中，研发代码中会写原始属性值，而这个写的过程本身就是孤立的，非标准化的，而现在研发以引入 Design Token 的方式，把视觉样式的代码进行统一管理，形成统一的研发组件库，各业务线可以直接调用，收拢了散落各处的代码。Token 最终会对应什么样的呈现，完全基于标准规范。而通过对规范的调整，可以对应用整套设计进行体系化的调整
, ]" e8 \" i5 ~  N2 @/ k
, V  F1 N+ O0 y

3. 服务能力标准化

渲染架构的标准化有一个重要的设计就是将服务和渲染分离开。

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

% o, n- u8 R8 w$ _为此，我们设计了标准化的服务接口和服务中间层，每个模块都通过调用服务中间层的标准化接口，来获得或者触发服务。这既使渲染和服务解耦，也完成了中间件之间的接耦，形成了高内聚低耦合的架构层次。
9 _. l3 C& Y! t: n
1）未标准化之前。
6 b5 x$ \, S1 T5 C

8 H. p& M9 R$ Z9 r2 o: U
  m8 z9 g* o: L1 H- g0 M通过一系列的标准化工作，实际上改变了业务需求的开发的模式。
3 \7 N  o2 z  ^
1）从设计的角度看，现在的设计首先考虑的整体的设计规范，然后才是个性化需求的表达，从设计的输出物上看，不再是基于数值的标注，而是基于协作语言的标注，对于最终的效果，设计在设计开发阶段就可以有明确的感知，不再需要逐个元素和开发细调，解放了人力。
6 V: G# F' f) U
2）从开发的角度看，开发只需要关注组件的个性化需求实现，而可以复用大部分代码。组件开发上，有公共组件库提供从属性到布局多个维护的标准化实现，而且由于在框架层面的隔离，所有的布局和大部分的卡片都是可以复用的，UI 的复用可以使产品需求的实现只需要关心产品的业务逻辑实现。而且组件是自我独立的，和外部容器之间没有直接引用，所以可以在任何环境下正常工作。经过一定时间的积累和沉淀，我们将会有支持大部分 UI 的布局卡片库。而对于能力的调用我们也提供了标准化的调用接口，开发同学不再需要关注最终具体的实现，只需要关注接口本身可以提供的能力即可。

3）对于产品和运营，统一的配置平台，组件产品全站拉通，都给了他们更低的成本和更好的收益，而设计开发效率的提高也增强了产品试错和复制成功经验的能力。

8 |, Q$ I$ t# i; T% E4）在实际收益上，渲染标准化之后我们已经积累十余个通用组件，节约了垂类业务的开发人力，研发效率提高了 40%。我们的用户体验优化的项目中，比如异步加载，轻量化等等都通过标准化快速落地到了每一个业务场景，将之前两三个月的落地周期缩短到了两个迭代。再如设计标准化，为暗黑模式的快速完成，提供了技术基础，使之前一个月全员投入的需求在两周之内完成上线。
. D3 ?( d3 n4 l6 t/ x7 K+ v. O% t2 \
+ r+ P, Q& }* v: Y: X1 _我们的架构设计成果，还在促进着阿里集团其他应用的标准化，比如来疯等独客在接入后，一次开发，可以快速在优酷，来疯，虾米等多个应用投放。

8 U& o( n$ [* I9 t" b: ^" o备注：

PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应 PO 的一个（或若干个）属性。
; i' z: V0 |; E2 k( i
: x: g$ e3 @# Z9 O, l- S' v: X4 R+ FVO（View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

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

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

8 z. c& S2 w5 Y( e1 F作者 | 阿里文娱无线开发专家 涵父

* z7 @0 H/ S, X) N( A# @————————————————
版权声明：本文为CSDN博主「阿里巴巴文娱技术」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
& z# n2 V, J6 v7 t; O. o' B原文链接：https://blog.csdn.net/alienttech/article/details/106167060
- h4 X) c; B6 t$ c% G0 X( y, R
2 V7 x5 Y' l2 g/ S