【暗黑模式】设计记录

从苹果发布 iOS13 Dark Mode 已有一年时间，网络上关于暗黑模式的文章也非常的多，应用要不要做暗黑模式，以及为什么要做暗黑模式，设计师都很了解。今天这篇文章就简单谈一谈我们在做暗黑模式的过程中遇到的一些问题。

适配暗黑模式和整合设计组件一个道理，框架层级越庞杂的 APP，适配成本越大。从设计投入的时间成本来说，设计师需要将页面使用过的颜色进行汇总整理，再一一设置对应的暗黑模式的颜色。如果原应用中使用到太多不一致的颜色，那适配暗黑模式就会十分痛苦，对于开发来说也是一样。而适配暗黑模式最大的工作量也正好在颜色这里。

1 颜色语义化管理

颜色语义化，简单点来说就是 “给颜色取个名字，让程序快速识别它”。

为什么做暗黑模式要将颜色语义化呢？我们先来看一下不采用语义化的处理方式：

将界面的颜色，用色值来设置成一对一的切换。这时，我们会发现一个问题：切换模式之后，一个颜色可能需要对应成多个颜色。

比如图中的白色 #FFFFFF，按照一对一的规则切换，界面中所有的 #FFFFFF 在暗黑都会变成 #33343E。而根据实际的需求，我们期望在暗黑模式中，按钮文字保持白色不变，这时就无法再使用一对一的色值切换了。

而且随着界面层级的逐渐增多、需求的变化等等因素，很多颜色也许都会出现需要对应多个色值的情况。（补充说明：色值切换的方式，并非只能一对一，也可以单个颜色单独设置，但这样的方式相对来说不是很高效。）现在我们来将颜色根据使用场景，各自分类命名一下，会发现颜色的切换会变得比较清晰。

那在实际操作中，怎样命名颜色更方便呢？根据目前我个人的处理情况来看，在应用中使用到的颜色，大致可以使用这样的分类来命名：

1.1 通用色

不跟随模式切换的颜色，即：不管是 Light Mode 还是 Dark Mode，都不会发生变化的颜色。这样的颜色就可以归纳成通用色，命名的时候加上前缀 Common。

比如说上图中按钮的白色文字，命名为 Common-White；或者用来做弹窗遮罩的黑色，可以命名为 Common-Black。

1.2 背景色

界面最底层背景的颜色，命名的时候加上前缀 BG。

如果有多个背景色，可以根据层级来命名。比如说一级页面的背景色可以用：BG-Primary，二级页面的背景色：BG-Secondary，三级页面的背景色：BG-Tertiary，依次类推。当然使用 BG-1、BG-2、BG-3 这种也不是不可以，只要能分辨得清就好。

1.3 模块色 / 前景色

界面中模块的颜色（也可以称为前景色，与背景色对应），命名的时候加上前缀 Module。如果有多个模块色，和上方的命名逻辑一样：Module-Primary、Module-Secondary、Module-Tertiary、Module-Quaternary… 等等。

为什么背景色和模块色要分开来命名呢？因为如果只用背景色来命名的话，我们有可能会遇到这样的情况：如下图，暗黑模式的页面层级出现问题，前景色比背景色要暗。而为了凸显前景的操作，在暗黑模式中，前景色是需要比背景色亮的。

所以为了让背景色和前景色更加的可控，避免页面层级出错，建议将它们分开来命名。

1.4 主题色

界面中使用到的主题色，一般是品牌的主色和辅色，命名的时候可以不用加前缀。可以直接使用 Red、Green、Blue 这样清晰的词汇来命名。

如果同一类的颜色比较多，可以再进行细分。比如：Blue-1、Blue-2、Blue-3… 以此类推。

1.5 文本色

顾名思义，界面中文本部分使用到的颜色，命名的时候加上前缀 Text。

依旧是可以根据文字的层级来进行命名：Text-Primary、Text-Secondary、Text-Tertiary…

大部分的情况下，以上 5 种颜色分类也就足够了。如果还想做得更细一些，或者还有更多的分类需要，可以再加上线条色（前缀可用 Line）、图标色（前缀可用 Icon）这样的分类。

在命名好颜色之后，最好将所有的颜色归纳整合成一份团队成员能快速查看的图表。这里我选择的是直接在 Figma 上建立一个画板来做记录：将颜色的名称和色值做成对应的表格，并适当加上一些备注。

2 制定规则时，值得注意的地方

2.1 因为需求变化，某些颜色无法遵循原来制定的规则，怎么办？

比如原来的颜色 A，按照切换规则应该变成颜色 B。但可能因为一些原因，在某个特殊的页面，需要变成颜色 Z。这时，就要对该颜色进行单独的处理，不写在规则中。这种情况，设计师一定要做好记录，避免走查的时候遗漏。

2.2 阴影的样式，也可以使用语义化命名，但建议采用通用的样式

有的模块组件需要带有阴影，在不必要的情况下，建议尽量选择带透明度的黑色来作为通用的阴影样式，而不是 Light 和 Dark 各自采用不同颜色的阴影，这样可以适当减少一些不必要的工作量。

当然如果 APP 需要一些特殊的阴影处理，这一点可以忽略。

2.3 同一个颜色，不同透明度，需要命名成两个名称吗？

建议最好是命名为两个名称，尤其是文字部分，很容易使用同一个颜色不同透明度来区分层级。

2.4 Light Mode 和 Dark Mode，需要出两套设计稿吗？

保险起见，至少第一版的 Dark Mode 是需要出设计稿的，方便检查制定的规则是否有问题和遗漏。后续的迭代更新如果界面改动不大，可以考虑不出设计稿，但界面需要的切图素材还是需要给到的。

不过，为了避免设计师自己走查失误，时间允许的话，个人建议还是都出一下设计稿比较好。

3 设计素材的处理

使用矢量的图标，可以只提供一份设计素材；

而使用 png 格式的图标，除去两种模式都通用的图标，其余的图标需要提供两套切图；

部分插画、动效，也需要分模式提供两套。

简而言之，如果一套素材无法同时在两个模式都有很好的表现，就需要制作两套。

4 实用的操作建议

说了那么多，在实际的操作中，对于设计师来说，有哪些比较迅速切换模式的方法呢？

Sketch

手动切换：将颜色设置为样式，按照 Common、Light、Dark 进行分类。在设计暗黑模式的时候，方便进行选择。

插件切换：暂时还没有发现比较便捷的插件。

早在之前有一个 Sketch 的插件：Color System，可以用来做暗黑模式的切换。

不过它同一个颜色只支持命名一次，等于是实现两个色值的替换，并不是真正意义上的语义化替换。所以如果要使用这个插件的话，除非页面十分的简单，否则个人不是很建议用。

Figma

手动切换：将颜色按照 Common、Light、Dark 进行分类命名，Figma 会将相同分类命名的颜色分组到 Color Styles 里。

需要注意的是，最好在 Local Styles - Color Styles 中需要将颜色进行合理的排列，这样在色板里选择的时候，会更事半功倍。处理完命名之后，在设计暗黑模式时，直接在色板里选择对应的颜色就好。（可以看到 Figma 比 Sketch 的选择更直观和方便。）

插件切换：Dark Mode Switcher （推荐）

这个插件的逻辑，和手动切换的逻辑一模一样。只要参照了手动切换的颜色设置，再使用这个插件就能一步到位。

在使用的时候，注意颜色的命名中一定要有 Light 和 Dark 作为关键词。命名完全相同的颜色，使用插件选择模式，就会立即切换。

You can specify your favor ColorStyle which separated by “/” and contains “Dark”(“dark”) or “Light”(“light”) key. Exmaple: “Background/Dark/Primary” will change to “Background/Light/Primary”.

5 语义化存在的问题

其实和所有组件化的问题一致，就是 “牵一发而动全身”。

从某些角度上来说，这样的方式提高了工作的效率，但在一定程度上，也会丢失一些灵活性。同时在设计和开发走查的过程中，需要特别仔细地去核对各个页面是否有误，尤其是那些在规则之外，被特殊处理的地方。

但并不是说这样的方式不好，只是在实操的过程中，需要特别留意到这些问题。
https://mp.weixin.qq.com/s/iePEyJdUQFrRfqGXvC5ZDw