超级App暗黑模式的最佳实践---标准化设计体系

什么是最佳实践

Best Practice ：最佳实践。Wikipedia 上对其解释为：

A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things. 

  (最佳实践是一种：因其产生的结果优于其它选择下的结果，或其已经成为一种做事的标准，从而被普遍认可优于任何替代方案的方法或技术。) 这个概念源于管理学，简而言之，就是所谓“正确的做法”。   最佳实践本身是美好的存在，犹如夜空中的一轮明月，照亮黑暗中的方向，指引着摸索前行的凡人。   但是对于最佳实践，人们容易犯教条主义的错误，以为就是放之四海而皆准，反而受其所累。所以我们要先明确一下我们实践的目的和环境，并寻求这种场景下的最佳实践。   我们的目的是对于android和ios的最新系统版本新增特性--暗黑模式进行适配。   那么什么是暗黑模式呢？暗黑模式影响的范围？我们适配的App是一个什么样的App？我们的技术环境是怎样的？我们准备投入多少成本来完成？   明确完这些问题，我们就可以确定最适合的设计的方案。

项目需求

什么是暗黑模式？

Android Q 与 iOS13 先后发布深色模式，之前随公众理解的深色氛围一跃而上成为系统平台级能力。 IOS：developer.apple.com/design/huma… Android：developer.android.com/guide/topic… 深色界面在专注环境下与内容有更高的契合度，更凸显内容、缓解视觉疲劳。 深色界面更易营造品质感与沉浸感。 深色界面更易建立填充感 -- From 设计

暗黑模式影响的范围

而作为一种系统平台能力，它打造的是一个整个用户使用周期的全链路视觉体验，也就是要覆盖到用户能到达的每一个角落。 这包括了分发场景，搜索场景，消费场景等复杂的页面结构的场景，也包括落地页，活动页等独立页面，还包括了弹窗，Toast，播放器等常用组件。要Cover如此复杂细碎的场景就需要整体性的视觉呈现效果和低成本的用户和平台开关。

优酷现有的类似场景及其技术方案

分析完需要影响范围，我们再来看一下，我们实践的对象--优酷APP。优酷App发展到今天，已经从一个单体App，进化成了一个承载集团众多业务出口的超级App。所以优酷app的页面是由十几个建制完整的内部和外部团队共同贡献的，这种全站范围的适配将涉及到上百位相关的设计开发和测试同学，管理成本，落地成本都非常高。 在确定技术方案前，我们先调研了每个业务团队现有的技术方案。 主要有三种，第一种是通过服务端下发视觉模式标记，客户端通过解析该标记的配置，转化成对每一个视图的代码设置。一个视图在某个视觉模式对应的代码设置在开发时就确定了。第二种，是服务端下发一套视觉样式的KV，客户端预先写好视觉样式的Key和某一个/类视图元素的对应关系，在客户端渲染时，通过这个Key在服务端数据中找到对应的Value并设置给视图元素。第三种，是依赖于原生的资源加载器，不同的视觉模式对应不同的资源文件。

预期成本

由于优酷的业务需求较多，以往大量占用业务需求的开发人力的方式，成本较高。所以我们希望可以以较低的开发成本完成需求。而我们又希望第一时间将系统的新特性尽早的呈现给客户，所以我们的开发周期定在了双十一之后的两周。

如何落实最佳实践

最简即最优

在确定技术方案之前，我们还需要确定设计原则。我们的原则是： 简单 准确 全面 具备一定的动态性 设计体系

简单是因为暗黑模式在超级App落地涉及的团队非常多，而大家真的技术栈非常不同，极具差异性，所以我希望我的技术方案一定要在紧贴系统，才能让大家容易接受，才不会和别的技术方案产生冲突。技术方案可以叠加但不能冲突，不然落地就遥遥无期了。 准确是因为暗黑模式涉及的页面非常多，设计开发也自然非常多，如何把控总体的效果，而不在落地的过程中发生变异，就需要一个唯一的标尺，而且这样在开发中出现设计或者需求修改的情况也能够快速响应。 全面是因为暗黑模式的页面中，不仅有Android/IOS这样的native页面，还有Weex，H5等动态页面，未来还有可能有Flutter，小程序这种新兴势力。所以一定要设计一个全面的技术方案。另外，我们希望我们的方案可以输出，到文娱，到集团，甚至到外部。所以也需要一个全面的设计。 具备一定的动态性是考虑到可能需要服务端下发，或者针对不同页面做定制。 设计体系 之前的设计开发之前是割裂的，通过标注进行沟通，开发不对设计效果负责，设计往往都要在集成前才能看到设计效果，然后设计再找开发修改，再review，形成循环。这是纵向的割裂。还有横向的割裂，同样的设计在不同的应用场景要重复循环，而不同的设计和开发可能在最终的效果上有不同的表达，造成风格的不统一，降低用户体验。所以我们希望的我们的实践能够减少这些gap，形成完整的设计体系。

标准化设计体系

下面为大家介绍我们最终的实践方案---标准化设计体系 我们和设计同学一起通过对大量线上的产品进行了摸底，归纳抽象出了其中的共性的设计，站在全站的高度，共同搭建了视觉产品化能力，把影响视觉风格调性的最基础属性（颜色、字号、间距、圆角、尺寸）进行了统一的命名（DesignToken），设计与开发团队共同维护一套可扩展的视觉属性。视觉属性与框架布局分离并与开发逻辑相互对应，通过SDK的方式统一管理，一处替换全端生效，遍于控制并快速定义产品风格。 在暗黑模式的具体工作上，设计同学负责确定暗黑模式的色彩框架，形成设计规范，建立模式色板。而研发同学则不再像以往根据具体的数值进行开发，改为根据语义名进行开发，而且通过多级的视觉开发代码复用，最大程度的减少具体业务组件的适配工作，将适配开发改为了页面走查，走查没有纳入或使用DesignToken的场景。 另外，我们考虑到语义化名字在设计和开发之间的自然流转，还修改了设计开发工具。将之前输出数值在标注上的方式，改为了输出DesignToken和示例代码在标注上。在不给设计增加标记成本的同时，大大减少了设计和开发的沟通成本。

此外，我们还对于暗黑模式进行了色彩分层，静态色层是全站使用的基础色值，它直接对应着一个具体的值。它不会随着视觉模式的变化而变化。在它之上的是动态色层，动态色在不同的视觉模式下，对应不同的静态色。这是通过android原生的资源加载机制完成，即暗黑模式对应关系在暗黑资源文件中，普通模式在普通资源文件夹中。而在动态色层之上，是代码编写的色彩管理器，它在合适的时间会去获取当前的所有静/动态色值，设计这一层有两个原因，一个是提高性能，提前缓存一份给更上层调用，另一个是形成中间层，众所周知，xml资源文件的动态性是不足的。XML资源启动即加载，加载后就是只读的。有了这一层，我们可以支持服务端动态下发色值token的定义，以达成一定程度的动态性。在色彩管理器之上，是公共的控件和组件，由于这样的层次关系，使最终的业务设计可以通过搭建完成，完全不需要从零写起，也不需要关注设计标注的细节，开发再也不用一个元素一个元素的调整，设计也不需要一个像素一个像素的校对了。只要在第一次纳入的时候进行一次就够了，大大提高了工作效率。

Weex && H5

对于Weex和H5，我们考虑了几种方案，比如只提供模式查询能力，由JS开发控制效果，再如建立JS版本的资源库和设计标准化体系，前者过于简单，难以控制最终结果，后者又比较重，需要较长的时间成本。我们的最终的方案，JS侧开发按照DesignToken进行开发，这样设计对于不同渲染方式是无感的，而Native在调用Weex或H5的渲染时，将当前的色值表传给JS侧，这样JS侧对于当前所处的视觉模式也是无感的，但是最终效果就是和Native完美契合的。

留给未来

我们觉得设计标准化体系大大的提高了如暗黑模式这种全站视觉开发的效率，DesignToken的设计将开发从繁琐的视觉效果开发中解脱了出来，未来我们会继续深化和丰富标准化设计体系的能力。也希望这种开发方式可以在不同的App间变成通用方式，这样对如公共组件池，Weex/Flutter/小程序等的跨应用通投都有重要的意义。 跨端技术方案提供了跨端的技术基础，而标准化设计体系则给出了跨端的实际方案。