超级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/小程序等的跨应用通投都有重要的意义。 跨端技术方案提供了跨端的技术基础，而标准化设计体系则给出了跨端的实际方案。