本文是 UI 架构系列 的第一篇，将深入探讨颜色层的设计。后续文章将依次介绍：

• 第二篇：Drawable 层规范与工程实践
• 第三篇：Style 层如何系统性消除代码冗余
• 第四篇：设计主权回归与团队落地

注：本文以 Android 为例进行说明，但核心思想完全适用于 iOS、React、H5、小程序等任何平台。

前言

在多年的跨平台 App 开发实践中，我发现 UI 资源管理是困扰许多团队的共性问题：

• 颜色定义混乱，同一个色值重复定义几十次
• 组件形态与颜色过度耦合，难以复用
• 样式属性重复书写，维护成本极高
• 主题切换困难，夜间模式适配工作量巨大
• 新同事需要花费大量时间理解混乱的颜色命名

如果你也被这些问题困扰，这个系列或许值得一读——主要面向设计总监、设计师、研发总监与前端工程师。

本文要点：

1. 三层颜色架构的设计理念和核心原则
2. 每一层的具体设计规范和代码实现
3. 如何实现日间/夜间模式的无缝切换
4. 架构的适用场景和扩展方向

架构全景

本系列介绍的是一套完整的 UI 架构体系，其中三层颜色架构是核心基础：

箭头表示引用/依赖方向：应用层引用 func_；func_* 引用 t_；t_ 引用基础色。定义权在设计侧，自下而上配置。*

颜色层依赖关系：func_* → t_* → 基础色（严格单向依赖）

本文聚焦于三层颜色架构的完整设计，后续文章将介绍上层应用层如何基于颜色层构建。

一、传统颜色管理的核心痛点

1.1 真实项目中的反例

在我接触过的多个项目中，经常会看到类似这样的颜色定义：

<!-- 从真实项目中截取的颜色定义 -->
<color name="bg_login">#FFFFFF</color>      <!-- 登录页背景 -->
<color name="bg_home">#F5F5F5</color>      <!-- 首页背景 -->
<color name="bg_profile">#FFFFFF</color>    <!-- 个人中心背景 -->
<color name="text_title">#141414</color>   <!-- 标题文字 -->
<color name="text_desc">#808080</color>    <!-- 描述文字 -->
<color name="text_hint">#BFBFBF</color>    <!-- 提示文字 -->
<color name="button_red">#DB121F</color>   <!-- 红色按钮 -->
<color name="red_button">#DB121F</color>   <!-- 另一个红色按钮 -->

1.2 问题分析

1.3 根本原因

这些问题的本质在于：颜色定义与业务语义、主题逻辑过度耦合。当一个颜色既承载了"背景"的业务含义，又承载了"白色"的具体色值时，任何改动都会牵一发而动全身。

二、三层颜色架构设计理念

针对这些问题，我设计了一套严格单向依赖的三层颜色架构：

2.1 架构核心原则

重要说明：功能色层封装的是 UI 职能（如文本、背景、边框），而非具体业务场景。func_black_text_1 代表黑色系主档文本色，可用于商品标题、页面标题、按钮文字等任何场景，不绑定具体业务。功能色的定义权归属设计师，研发只引用、不新增。

2.2 严格单向依赖规则

为什么必须严格遵守单向依赖？

• 避免循环依赖导致的颜色定义混乱
• 每层只做自己的事，职责清晰，便于定位问题
• 改一处全局生效，维护成本极低
• 多人开发不会互相冲突

三、分层详解：每一层该怎么设计

3.1 第一层：全局基础色层

定位：纯原始色值定义，不做任何主题绑定和业务关联

命名规则：色系_数字 下划线格式，数字按明度/饱和度递增

设计原则：

• 白色系：数字越小越浅（white_1 = 纯白）
• 黑色系：数字越小越浅（black_1 = 浅灰）
• 彩色系：数字越小饱和度越低
• 不参与日夜切换，保持绝对稳定

完整基础色表（与仓库实现一致）：

代码示例：

<!-- ✅ 正确：统一色系_数字命名 -->
<color name="white_1">#FFFFFF</color>
<color name="black_8">#000000</color>
<color name="red_4">#DB121F</color>
<color name="black_1">#F0F0F0</color>
<color name="white_1_alpha20">#33FFFFFF</color>

3.2 第二层：主题适配层（t_）

定位：唯一的日夜模式映射层，只做色值代理，不承载任何业务语义

命名规则：t_基础色名，与基础色一一对应

设计原则：

• 只引用基础色层变量，绝对不写具体色值
• 日间/夜间模式通过 Android 资源限定符自动切换
• 保持与基础色完全一致的命名，便于维护

错误做法（常见误区）：

<!-- ❌ 错误：主题层承载了业务语义 -->
<!-- values/colors.xml -->
<color name="t_bg_page">#FFFFFF</color>
<color name="t_text_main">#000000</color>

<!-- values-night/colors.xml -->
<color name="t_bg_page">#141414</color>
<color name="t_text_main">#FFFFFF</color>

问题：主题层承载了业务语义，破坏了分层原则。新增主题时需要复制所有业务语义的颜色。

正确做法：

<!-- ✅ 正确：只做颜色映射，不关心用途 -->
<!-- values/colors_theme_tokens.xml（日间模式） -->
<color name="t_white_1">@color/white_1</color>
<color name="t_black_8">@color/black_8</color>
<color name="t_orange_4">@color/orange_4</color>

<!-- values-night/colors_theme_tokens.xml（夜间模式） -->
<color name="t_white_1">@color/black_8</color>   <!-- 背景色反转 -->
<color name="t_black_8">@color/white_1</color>   <!-- 主文字色反转 -->
<color name="t_orange_4">@color/orange_3b</color> <!-- 夜间使用较浅的橙色 -->

优势：

• 主题层只做颜色映射，不关心用途
• 新增主题只需要加一个资源目录
• 夜间模式切换完全由 Android 系统自动处理，零代码侵入

3.3 第三层：功能色层（func_）

定位：面向 UI 职能的语义抽象层，不承载业务语义（如「登录页背景」「删除按钮红」）

命名规则：func_{色系}_{职能}_{档位}，档位数字按该职能下的深浅/重要性递增

设计原则：

• 只引用主题层变量，绝对不直接引用基础色
• 采用「色系 × 职能 × 数字档位」模式，保留无限扩展能力
• 由设计师在资源文件中定义与维护；研发在布局/代码中只引用已有 token

为什么我反对固定语义命名？

很多人喜欢这样定义功能色：

<color name="func_text_main">@color/t_black_8</color>
<color name="func_text_sub">@color/t_black_5</color>
<color name="func_text_aux">@color/t_black_3</color>

这在实际项目中会出问题：中间态越来越多，命名很快失控。比如需要一个介于 sub 和 aux 之间的颜色时，该叫 func_text_sub2 还是 func_text_medium？

最佳实践：色系 + 职能 + 数字档位

<!-- 黑色系文本：档位越小越深、越重要 -->
<color name="func_black_text_1">@color/t_black_8</color>
<color name="func_black_text_2">@color/t_black_7</color>
<color name="func_black_text_3">@color/t_black_5</color>
<color name="func_black_text_4">@color/t_black_3</color>

<!-- 黑色系背景：档位越小越浅 -->
<color name="func_black_bg_1">@color/t_black_8</color>
<color name="func_black_bg_2">@color/t_black_7</color>

<!-- 橙色系强调 -->
<color name="func_orange_text_1">@color/t_orange_4</color>
<color name="func_orange_bg_1">@color/t_orange_4</color>

无限扩展能力：

• 需要在 func_black_text_2 与 func_black_text_3 之间加一档，由设计师新增 func_black_text_25 即可
• 不用造 func_product_title 这类业务名
• 规范可长期稳定

职能分类速览（详见第六节完整矩阵）：

四、两个关键争议点的深度解析

4.1 争议1：主题层到底该不该承载业务语义？

我的答案：绝对不应该。

主题层的本质是颜色代理，它的唯一职责是根据当前主题返回对应的基础色。它不应该关心这个颜色是用来做背景还是文字。

如果主题层承载了业务语义：

• 每新增一个主题，你都要复制所有业务语义的颜色
• 业务语义变化时，你需要修改所有主题文件
• 架构的解耦性被完全破坏

4.2 争议2：功能层用数字命名会不会可读性差？

不会，只要约定好规则。

我们只需要在团队内部约定：

• 文本色：数字越小越重要、越深
• 背景色：数字越小越浅
• 边框色：数字越小越深

新人只需要花 5 分钟就能记住这些规则，比记住几十个不同的语义名称要容易得多。

五、核心优势：为什么这套架构能解决问题？

5.1 维护成本显著降低

改色流程对比：

5.2 无限扩展能力

• 新增色系：只需要在基础色层添加
• 新增主题：只需要加一个资源目录
• 新增 UI 职能档位：由设计师在功能层顺延数字编号

5.3 团队协作零成本

• 统一的命名规范，没有歧义
• 新成员 5 分钟就能上手
• 多人开发不会互相冲突

六、功能色层详解：7大色系 × 6种职能

在实际项目中，我们发现一个 App 中常用的颜色职能只需要6种：

而这 6 种职能，组合7大色系，就构成了一个完整的颜色体系。

6.1 为什么是这7大色系？

6.2 完整颜色矩阵

文本色（7色系 × 4档 = 28个）：

背景色（7色系 × 2档 = 14个）：

边框色（7色系 × 2档 = 14个）：

分割线、透明度、阴影色（各7色系 × 2档 = 各14个）：

理论矩阵规模：7 色系 × 6 职能 × 2–4 档 ≈ 84 个 token，可覆盖绝大多数通用 UI 场景。本仓库 demo 仅实现常用子集（见 colors_semantic.xml）；完整矩阵由设计师按产品需要逐步补齐，研发不自行「补色」。

6.3 核心原则：职能无关，业务通用

这套颜色体系是业务无关的。同一个 func_red_text_1：

• 在电商 App 中可以用作「商品下架」提示
• 在社交 App 中可以用作「被拉黑」提示
• 在金融 App 中可以用作「交易失败」提示

颜色本身不承载业务语义，业务语义由使用场景决定。

6.4 反例 vs 正例

反例：业务绑定

<!-- ❌ 错误：业务绑定，无法复用 -->
<color name="func_product_delete_text">@color/t_red_5</color>    <!-- 商品删除文字 -->
<color name="func_order_cancel_text">@color/t_red_5</color>    <!-- 订单取消文字 -->

正例：职能无关

<!-- ✅ 正确：职能无关，业务通用 -->
<color name="func_red_text_1">@color/t_red_5</color>    <!-- 任何需要红色文字的地方 -->
<color name="func_red_text_2">@color/t_red_4</color>    <!-- 任何需要浅红文字的地方 -->

6.5 完整命名规范速查表

命名公式：func_{色系}_{职能}_{档位}

色系前缀：

职能后缀：

七、总结

这套三层颜色架构的核心思想其实很简单：解耦。

• 把色值定义和主题适配解耦
• 把主题适配和 UI 职能语义解耦（职能语义仍由设计师定义，不绑定具体业务页面）
• 每一层只做自己最擅长的事

通过「7大色系 × 6种职能」的设计，我们构建了一套完整、可扩展、业务无关的颜色体系，覆盖 App 所有通用 UI 场景。

参考代码：

• 基础色定义
• 日间主题层
• 夜间主题层
• 功能色定义

💡 如果你觉得这篇文章对你有帮助，欢迎点赞、收藏、转发。关注我，获取更多 Android 架构设计干货。