- 在线时间
- 1630 小时
- 最后登录
- 2024-1-29
- 注册时间
- 2017-5-16
- 听众数
- 81
- 收听数
- 1
- 能力
- 120 分
- 体力
- 554195 点
- 威望
- 12 点
- 阅读权限
- 255
- 积分
- 171631
- 相册
- 1
- 日志
- 0
- 记录
- 0
- 帖子
- 5313
- 主题
- 5273
- 精华
- 18
- 分享
- 0
- 好友
- 163
TA的每日心情 | 开心 2021-8-11 17:59 |
---|
签到天数: 17 天 [LV.4]偶尔看看III 网络挑战赛参赛者 网络挑战赛参赛者 - 自我介绍
- 本人女,毕业于内蒙古科技大学,担任文职专业,毕业专业英语。
 群组: 2018美赛大象算法课程 群组: 2018美赛护航培训课程 群组: 2019年 数学中国站长建 群组: 2019年数据分析师课程 群组: 2018年大象老师国赛优 |
2 }: G$ K; u' K V# i7 n; u统一架构——优酷主客的标准化开发之路一、超级 APP 的标准化
: S; Y K K+ S2 d o$ i6 q7 {6 X% l
在技术领域,标准化有很多很好的实践案例。比如服务端容器的出现,应用的构建、分发和交付得以在容器层面上实现标准化,提升了业务创新的效率。8 U4 t; C7 v1 R) J9 R
9 z6 U! q7 w/ b8 R3 Z
那么一个客户端应用的标准化是什么呢?一个业务需求通常可以拆解为功能需求,设计需求,体验需求,数据需求和运营需求,而每一种需求都对应着一类开发工作。
0 r5 r9 N9 d0 h3 L- ]- T
2 j/ [ N9 v+ x2 q t通过对每一类开发工作进行分析研究,我们得出了一个结论,客户端开发的标准化是运行时环境一致,视觉效果统一,遵守相同的数据协议,用相同的方法搭建,投放和获得用户反馈的标准化。具体抓手则是以渲染架构标准化为核心的一系列标准化设计和工作。 p# ?5 `, k v2 R
6 O t/ M! O; n- v( i. c二、优酷的标准化实践
6 }7 f2 U! c) c2 s2 p# p- u; c* U B
1.渲染架构标准化, O1 k9 X- ~3 Y6 L- V- v
; s# N' Q: r* W+ {
通常一个应用是由一个一个页面组成的,而页面是由什么组成的呢?1 |# D& X$ n# [
! j; v7 E0 b, _. r2 k我们可以大致分为三个部分:数据,组件和服务。$ E& V, u9 o* F# L' C) P& d: F
2 Y0 J9 y& B: l2 Z0 T; h' r* @
数据模型是业务模型的抽象化产物,是页面的里,它的结构来源于业务的需要,影响着组件的实现。数据从媒资,算法等生产源头通过 CMS(内容管理系统)汇聚而来,通过网络以字节流传输到客户端,客户端下载,解析,转换成对象,或统一保存,或组织分发给每一个显示单元,从而完成其从生产到消费漫漫征途。& s# Q+ }. }2 V4 S- \) ^& b
- ~+ h3 q% ?( l1 `6 }9 ?数据需要贴合业务,如果有一个环节的格式定义出现差异,最终的结果可能就会大不相同,而刷洗数据,转化格式又会带来效率上的降低。而对统一架构和标准化组件来说,我们又希望数据的格式和字段是一致的。如何来解决这一对矛盾获得最优解呢?& ~0 | ]8 b* W1 V; _
# r8 I# y% S0 A& H3 Y+ m7 [# F我们从两个方向进行了尝试,一个是在页面搭建方向上,推进了服务端的数据协议的标准化,之前服务端的数据模型大致都是 page-module-component-item 的多层嵌套结构,它对应了运营同学在搭建页面时,从整体到局部到细节的设计思路和操作行为。我们的标准化思路就是虚化节点定义,明确节点结构。虚化节点定义的意思,我们不再以 page,module 等有具体意思和层级关系的名称作为节点 tag,而是统一为 Node。这样原本有层级关系的结构,就变成了可以任意嵌套的结构。而对于 Node,明确其内部为 level,data[],style[] 和 subNodes[] 等含义明确的标准化结构。而在组件渲染方向上,我们将数据结构演化抽象为从 PO-DTO-DO-VO【备注】的过程。而我们在 VO 这一层去抹平之前的协议差异。
2 { c" F/ l4 k1 z/ ^
- l6 e0 N/ t' ]1)组件是页面的表,直接响应用户体验。组件的核心设计原则是组件在不同页面上的复用,为此我们将组件的内部实现分解为 Model,View 和 Presenter 三个部分,各部分之前只以 Contract 约束接口定义。这样三类模块都可以进行不同实现的组合和替换,我们刚才说的在 VO 抹平数据协议差异,就是通过配置不同的 Model 完成的。此外,我们在组件的布局管理使用了 vLayout 的布局混排能力,在配置上通过文件配置进行布局样式上配置和组件 MVP 的搭配,还提供了组件间的通信能力。这些标准化接口的提供,统一了组件的使用环境,大大降低了组件的 UI 开发的难度。7 ?) C+ U/ |, A6 _- Z8 o5 S
. b' D% M6 c) @- \1 M2)服务是页面的神,有了服务页面才是活的。对于服务我们抽象为域内服务和域外服务,域内服务指的是页面范围的视觉动作,比如组件的插入,删除,刷新,加载更多等,这部分能力我们在数据域对象提供了内置的方法,而域外服务则是指对业务中间件和应用基础能力的调用,对于这部分调用,我们在服务能力标准化再介绍。 j" J* f* b2 P4 S
" U% m4 r% s5 l7 F y0 i! Y
在渲染架构标准化的设计中,我们强调了解耦,而这对配置化的实现也带来了便利。通过对页面布局能力的拆解,对组件 MVP 的结构设计,渲染标准化架构把一个组件拆解成了这个组件的容器,容器的 adapter,组件的 MVP 部件,组件交互需要的领域能力,组件交互需要的基础服务等独立部分,可以自由配置组合。在组件承载的业务上,我们也通过代理来进行配置,代理可以拿到页面的上下文,监听业务的消息进行响应,不同的使用场景都遵循着相同规则。
; H' G; t2 n2 D) f+ J
t! S8 [ M& j; O, [% }1 d: P* t
' J8 M! e: p1 r. B: m- l, S2. 设计体系标准化( Q. w* z6 [1 o. J$ [, T
# o( r9 y5 ?9 O) }( v7 w
客户端用户界面一致性是设计体系标准化需要关注的核心问题,保证一致性和体验品质,并实现设计开发的工作提效,是“设计语言标准化管理体系”的建设的核心诉求。为此,我们联合设计一起,从零创立了优酷自己的设计体系。我们为设计体系设定了核心目标:建立设计语言的标准化管理体系,改变设计与开发生产模式,实现设计与开发的品质和效率提升。4 H; U' p) B0 ?1 @4 q9 W( {
" ?# g* n( _6 p+ F# z% C3 h" K/ S
为了完成这个目标,我们进行了很多工作。设计同学对全站的现有设计进行了盘点,统一设计和技术对界面元素的认知体系,定义了设计规范。开发同学建立了标准化组件库,以视觉规范为基础,把设计侧的规范文档及组件库,通过一种协作语言形成设计与技术的映射关系,实现客户端设计组件与技术组件的统一拉通,沉淀成统一的 SDK 共同维护。而协作语言的确立,标志着标准化的工作的具象,从根本改变了之前设计开发的工作流程。7 `# H* O: A* z" {
0 E: _0 z& q2 ?1 t# n5 k) v* Y) P- l( n
以往开发实现过程中,研发代码中会写原始属性值,而这个写的过程本身就是孤立的,非标准化的,而现在研发以引入 Design Token 的方式,把视觉样式的代码进行统一管理,形成统一的研发组件库,各业务线可以直接调用,收拢了散落各处的代码。Token 最终会对应什么样的呈现,完全基于标准规范。而通过对规范的调整,可以对应用整套设计进行体系化的调整3 x( j5 D5 L/ j" ~* M
. ?- g+ o. P1 ?" Q1 N/ F9 H
' j( z% A' E5 ^( w) R, P' c! z
* [8 u. `: j5 ]( ~3. 服务能力标准化
/ {5 ~' ^' U& w4 h' F3 o0 N4 @% T
渲染架构的标准化有一个重要的设计就是将服务和渲染分离开。7 [ ?1 y- I7 v
4 q$ x: i7 `8 E$ w+ `% r6 J P/ r
不同业务模块,一般都会依赖不同的中间件,按照之前的服务和渲染耦合的设计,相同的服务能力在不同业务模块间往往实现多次,这既增加了学习成本,形成技术壁垒,也使代码结构脆弱和臃肿。而且服务的接入成本高,迭代成本也高,冗余的代码既影响了编译速度,更影响了启动速度。
' X# R; A' e2 T( f8 x8 q$ T% B6 ?7 p @ G
为此,我们设计了标准化的服务接口和服务中间层,每个模块都通过调用服务中间层的标准化接口,来获得或者触发服务。这既使渲染和服务解耦,也完成了中间件之间的接耦,形成了高内聚低耦合的架构层次。& x3 x+ Y z! P# \/ m% E" x4 B S
* N) C5 D$ a- J4 r
1)未标准化之前。
8 p% a# E$ H4 v; C( V/ v
c' Q: ?6 {9 ]2 p) l$ p/ m Z5 S
5 w# ~$ E% Y, k. t' ~% ~8 t9 c2 k
% `$ o+ X2 L1 s* b. u7 Z通过一系列的标准化工作,实际上改变了业务需求的开发的模式。! b- X, s/ }' ^+ y
) @' ^0 Q; I* y! b, K
1)从设计的角度看,现在的设计首先考虑的整体的设计规范,然后才是个性化需求的表达,从设计的输出物上看,不再是基于数值的标注,而是基于协作语言的标注,对于最终的效果,设计在设计开发阶段就可以有明确的感知,不再需要逐个元素和开发细调,解放了人力。/ ~0 L+ q" t+ U& M
, i1 Z6 K2 f' {; N9 r( C
2)从开发的角度看,开发只需要关注组件的个性化需求实现,而可以复用大部分代码。组件开发上,有公共组件库提供从属性到布局多个维护的标准化实现,而且由于在框架层面的隔离,所有的布局和大部分的卡片都是可以复用的,UI 的复用可以使产品需求的实现只需要关心产品的业务逻辑实现。而且组件是自我独立的,和外部容器之间没有直接引用,所以可以在任何环境下正常工作。经过一定时间的积累和沉淀,我们将会有支持大部分 UI 的布局卡片库。而对于能力的调用我们也提供了标准化的调用接口,开发同学不再需要关注最终具体的实现,只需要关注接口本身可以提供的能力即可。
+ N: H# e, c- @/ l1 a2 O/ I, o* v6 \9 U
3)对于产品和运营,统一的配置平台,组件产品全站拉通,都给了他们更低的成本和更好的收益,而设计开发效率的提高也增强了产品试错和复制成功经验的能力。& u O* o" G! R; x
2 S" \* o" H" R! ]( W4)在实际收益上,渲染标准化之后我们已经积累十余个通用组件,节约了垂类业务的开发人力,研发效率提高了 40%。我们的用户体验优化的项目中,比如异步加载,轻量化等等都通过标准化快速落地到了每一个业务场景,将之前两三个月的落地周期缩短到了两个迭代。再如设计标准化,为暗黑模式的快速完成,提供了技术基础,使之前一个月全员投入的需求在两周之内完成上线。
' s; ^& O- \6 g( X8 ?) I9 Y$ W" m, B0 k
我们的架构设计成果,还在促进着阿里集团其他应用的标准化,比如来疯等独客在接入后,一次开发,可以快速在优酷,来疯,虾米等多个应用投放。% s3 k1 q" w7 r6 @/ s
# r7 e* i$ P7 X7 H备注:
+ C. G4 u; i5 D7 V( `2 F0 U1 N |: C0 a5 L. A
PO(Persistent Object):持久化对象,它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系,如果持久层是关系型数据库,那么,数据表中的每个字段(或若干个)就对应 PO 的一个(或若干个)属性。8 u" E6 t* n, l6 T5 R
, ^" y( t/ P i4 \$ w
VO(View Object):视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。
9 g/ ^$ t) c/ d \5 R, P+ f8 _! S% `! ?+ N" p" U9 f
DTO(Data Transfer Object):数据传输对象,泛指用于展示层与服务层之间的数据传输对象。
1 J- D8 t7 ]1 P+ ]6 S! B. D: \6 G) {2 S" g! k2 a
DO(Domain Object):领域对象,就是从现实世界中抽象出来的有形或无形的业务实体。
$ @% l6 i0 h! B$ F7 ^
$ ~6 a4 y6 a8 q- m b# P! r# e作者 | 阿里文娱无线开发专家 涵父9 R- A3 \9 M# x$ L7 p* Q
$ ]( Q4 b5 q7 `+ s
————————————————3 E9 n* |2 g0 O- }: u$ T
版权声明:本文为CSDN博主「阿里巴巴文娱技术」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。3 U8 @2 o& L' N$ T9 o
原文链接:https://blog.csdn.net/alienttech/article/details/106167060
. Y, |* C; \- l9 `0 _# R5 P* U" i) C; G& E
; S) x0 g+ v" t8 v! s
|
zan
|