本文讨论的是如何将UED的设计标准化体系在研发侧进行落地，以及我们对“超级App实现暗黑模式的最佳实践”这一问题的深度思考。

我们的目的是对Android和iOS的系统新增特性–暗黑模式进行适配。暗黑模式本质上是一个视觉模式，而视觉模式的适配对于业务复杂，页面众多的超级App来说一直是个工作量繁重的需求。

下面我们来看看，在设计标准化体系建立之前，优酷客户端是怎么实现视觉还原的工作的。

一、各自为战：前"设计标准化"时代的视觉还原工作

每一年，优酷App都会优化体验设计，对整个App的视觉呈现进行改版。视觉改版工作分配到各个团队的技术同学手中，有三种主要的实现方式。

第一种:

通过服务端下发视觉模式标记，客户端通过解析该标记的配置，转化成对每一个视图的代码设置。一个视图在某个视觉模式对应的代码设置在开发时就确定了。

第二种:

服务端下发一套视觉样式的Key-Value值，客户端预先写好视觉样式的Key和视图元素的对应关系，在客户端渲染时，通过这个Key在服务端数据中找到对应的Value并设置给视图元素。

第三种:

依赖于原生的资源加载器，不同的视觉模式对应不同的资源文件。

横向对比来看，方案一的设计最简单，完全取决于需求，典型的推一下走一步。方案二落地成本最高，需要对每一个视图增加响应配置的能力实现，开发的自由度最低，每个业务的开发都需要遵守相同数据协议完成相同的动作。而且它只能控制接入了这一视觉样式实现的业务，是渲染时方案，无法影响到XML形式的布局文件，只能在运行时才能看到效果。但是它的好处是变更成本较低，可以动态的修改服务端模版并下发到客户端页面。

对于方案三，则最符合原生开发习惯，也有最全面的开发工具支持，在编写布局文件时就能看到效果。但缺点是写完了就固定了，变更成本非常高。

为此，UED和研发同学共同研发了优酷统一的设计标准化开发体系，携手迈进了“设计标准化”时代。

二、最简即最优 - "设计标准化"的设计原则

在确定设计标准化技术方案之前，我们还需要确定设计原则。

我们的原则是：

简单，准确，全面，具备一定的动态性的设计体系

1、简单 是因为视觉模式适配在超级App落地涉及的团队非常多，而大家的技术栈各有不同，极具差异性，所以希望技术方案贴近系统原生实现，清晰且简单，才能让大家容易接受，才不会和不同团队的的既有技术方案产生冲突。技术方案可以叠加但不能冲突，不然落地的时间遥遥无期。

2、准确 是因为视觉模式适配涉及的页面非常多，参与的设计和开发同学也非常多。如何统一地把控总体的效果，不在落地的过程中发生变异，就需要一个唯一且准确的标尺。这样，在开发中若出现设计或需求的修改，也能够快速响应。

3、全面 是因为视觉模式适配的页面中，不仅有Android/IOS这样的native页面，还有Weex/H5等动态页面，未来还可能有Flutter，小程序这种新兴势力。所以一定要设计一个全面的技术方案。另外，我们希望我们的方案可以输出到文娱其他团队，供集团其他BU甚至外部公司参考。所以最终的技术方案一定是具有通用性的。

4、动态性 是考虑到可能需要服务端下发设计配置信息，或者针对不同页面做定制。

5、设计体系。在前“设计标准化”时代，设计和开发同学的工作是割裂的，通过视觉稿上的标注进行沟通。开发不对设计效果负责，设计往往都要在开发工作完成之后才能看到设计效果，然后设计再找开发修改，再Review，形成循环。这是纵向的割裂。另外，还存在着横向的割裂，同样的设计在不同的应用场景要重复循环，而不同的设计和开发可能在最终的效果上有不同的表达形式和标注，造成App风格的不统一，降低用户体验。所以希望我们的技术方案能够减少这些Gap，形成完整的设计体系。

三、"设计标准化"时代的视觉还原工作

下面，为大家介绍我们现在的方案——设计标准化体系。

我们和设计同学一起对线上的产品进行了摸底，归纳抽象出了其中具有共性的设计，站在全站的高度，共同搭建了设计产品化能力。把影响视觉风格调性的基础属性（颜色、字号、间距、圆角、尺寸）进行了统一的命名（DesignToken），设计与开发团队共同维护一套可扩展的视觉属性。视觉属性与框架布局分离，并与开发逻辑相互对应，通过集中式的SDK统一管理，一处替换全端生效，便于统一控制并快速修改产品风格。

在App视觉还原的具体工作上, 设计同学负责确定界面的色彩框架，形成设计规范，建立模式色板。而研发同学则不再像以往一样，根据视觉稿上具体的数值进行开发，改为根据DesignToken的语义名进行开发，而且通过多级的视觉开发代码复用，最大程度的减少具体业务组件的适配工作，将适配开发改为了页面走查，且只需要走查没有纳入或使用DesignToken的场景。

另外，我们考虑到语义化名字在设计和开发之间的自然流转，还修改和增强了设计开发工具。将之前直接标注数值在视觉稿上的方式，改为了输出DesignToken和示例代码在标注上。在不给设计同学增加标注成本的前提下，大大减少了设计和开发的沟通成本。

设计侧同学对标准化设计体系的思考，可以参看《优酷的设计标准化体系建设》，这里不再赘述。

下面，我们从开发的角度介绍一下设计标准化体系的具体实现，以及设计标准化体系上线之后，优酷是怎么实现暗黑模式的。

1、以Android为例，以下是我们的设计标准化整体架构图：

在代码的工程结构上，也体现了设计标准化体系的分层思想，分为了属性，控件，组件和容器四层，每一层都是基于其下一层的DesignToken搭建而成，层层叠加，最终构成完整的页面。

以Android为例，我们将DesignToken的设计翻译为Android的具体技术实现：

1）我们定义了很多基础属性：

下面是几个基础属性的例子:

    <!--静态属性-->
    <color name="cd_1">#000000</color>
    <color name="cg_6">#F5F5F5</color>

    <!--基础间距-->
    <dimen name="dim_5">6dp</dimen>

    <!--动态属性-->
    <!--背景层-->
    <color name="ykn_primary_background">@color/cd_1</color>
    <!--信息层-->
    <color name="ykn_primary_info">@color/cd_1</color>

        <!--组块背景-->
    <color name="ykn_primary_grouped_background">@color/cg_6</color>

2）在布局文件和代码中直接使用这些基础属性

<?xml version="1.0" encoding="utf-8"?>
<com.youku.resource.widget.YKTextView  -----  自定义文本组件
        android:id="@+id/yk_item_title"
        style="@style/text_view_4b"      -----  自定义组件的Style也是基于token设置
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout_marginTop="@dimen/dim_5" -----  自定义组件的属性也是基于token设置
        android:layout_marginRight="@dimen/dim_5" -----  自定义组件的属性也是基于token设置
        tools:text="我的标题" />

上面就是Android业务代码使用公共资源库的代码示例。

2、对于iOS来说，我们将DesignToken的设计翻译为iOS的具体技术实现

1）我们定义了很多基础属性：

以色彩属性为例:

@property UIColor * ykn_primaryBackground;  /// 一级背景
@property UIColor * ykn_secondaryBackground;/// 二级背景
@property UIColor * ykn_tertiaryBackground; /// 三级背景
@property UIColor * ykn_quaternaryBackground; /// 4级背景
@property UIColor * ykn_elevatedPrimaryBackground; /// 升起的一级背景
@property UIColor * ykn_elevatedSecondaryBackground; /// 升起的二级背景
@property UIColor * ykn_elevatedTertiaryBackground; /// 升起的三级背景

2）在代码中直接使用这些基础属性

self.view.backgroundColor = UIColor.ykn_primaryBackground;

得益于我们对现有设计的抽象和归纳，这些公共样式的布局文件是由专人提前开发完成，业务开发同学只要直接使用就可以了。对于实际的业务开发同学来说，他们不需要再关注设计的细节，设计和开发都是基于共同的DesignToken展开工作。

3）设计同学可以通过对DesignToken底层定义的控制，把控整个App设计的实现效果。

四、设计标准化体系在优酷落地的意义

设计标准化体系在优酷的最终落地，极大地提高了优酷设计和研发团队的工作效率。

1、统一管控

所有的页面都是基于统一的DesignToken来实现的，可以做到“一处修改，到处生效”。如果未来出现所谓的“红色模式”，“蓝色模式”，我们有信心在非常短的时间之内完成整个优酷App的视觉换新工作。

2、节省人力

所有的设计和开发同学都基于统一的设计语言沟通，极大地减小了交流成本。在版本迭代的末期，设计同学需要对视觉效果做微调和修改时，其作用尤为显著。

3、方便开发

现在优酷App中可以使用的UI基础属性全部属于一个受控的DesignToken集合，业务开发同学不需要关心和理解设计的具体细节，只需要将视觉稿翻译为Android/iOS原生实现即可; 不再需要反复确认设计稿细节和反复微调来还原视觉效果。

经过优酷数个版本的迭代，对比原有的开发模式，大部分设计和研发同学都感受到了设计标准化的强大威力，也认可了新的基于设计标准化的工作流。因此，优酷的设计标准化体系的持续开发一定会坚持下来，继续演进和迭代，支持更多的场景，支撑更多的大文娱业务。

究竟设计标准化体系的威力有多么强大呢？暗黑模式的落地是一个最好的Case。有了设计标准化体系打下的良好的基础，优酷App的暗黑模式的开发工作总体上是很顺利的。业务开发同学反映工作量比预期的少很多，设计同学视觉走查的结果是仅仅发现了很少量的视觉问题，这也反映出设计标准化体系和暗黑模式的技术方案设计比较完善，组件标准化的覆盖率达到相当高的程度。

下面，我们分Android、iOS、Weex&H5三篇文章，各自介绍我们是怎样基于设计标准化体系，完成“暗黑模式”的技术支撑方案。

作者简介：

涵父，阿里文娱无线开发专家。

相关阅读：

优酷暗黑模式（一）：是什么、为什么、如何落地？

优酷暗黑模式（二）：如何建立设计语言标准化管理体系

优酷暗黑模式（三）：暗黑模式设计指南

创作场景

优酷暗黑模式（四）：设计标准化的技术实现