在日常工作流程中，每当一轮迭代任务告一段落，我们都会进行一些设计上的总结，比如回顾那些具有代表性的设计方案背后的思考过程、权衡利弊的决策过程等，这些总结不仅起到备忘录的作用，还能作为我们学习和借鉴的资料。

工作如此，个人项目亦应遵循此理。近期在Store上线的项目，从启动到最终完成，似乎历经了约两个月的时间。在这期间，我利用工作之余的碎片时间，逐步进行制作和精心打磨。如今回顾，这整个过程让我深感自豪，收获颇丰。在制作过程中，我多次萌生在工程竣工后记录心得的念头，这源于我深刻地意识到，相较于以往，我确实在技能和知识上有所精进和收获。

现在，让我们着手进行这项工作。在本文里，我将向大家分享我在创建和维护组件库的过程中所获得的经验和知识，诸如构建和维护组件库的重要性、组件库的构建模式、色彩、样式和文字风格的设定策略、全局命名规则的制定，以及相关插件的应用。

为什么要制作和维护组件库

构思这套体系并非出于偶然。在日常工作里，我们常常需要投入额外的时间来构建和保养个人组件库，每当进入新的开发阶段，都会以此体系作为起始模板；同时，每当一个阶段告一段落，也会将期间涌现出的、最具代表性的、易于复用的组件或样式归纳整理，并纳入库中。随着时间的推移，库的内容逐渐丰富，个人也因此获得了更多益处；例如，在处理日常工作的众多项目需求时，只需轻松拖拽组件或稍作调整，便能迅速完成任务。

运用组件库能让我们更便捷、高效地完成设计任务，但这只是它带来的好处之一；若想真正实现这种便捷与高效，组件库自身必须具备高度的合理性，诸如合理的架构设计、良好的复用性和灵活性、以及较强的扩展性等。这一切都要求我们在整理与维护过程中持续深入思考和学习——或许需要参考市场上UIKit的布局方式，学习其不断推出的强大新功能；基于团队现有产品的设计方案sketch 图标库插件，提取出原子、分子、模块和页面级别的设计模式；同时，对扩展性进行周密预估。这些经历无疑为我们提供了丰富的学习和成长机会。若将组件库比作“鱼”，那么构建组件库的步骤则可视为“捕鱼之道”。我追求“鱼”的同时，亦渴望掌握更高效的“捕鱼之道”——正是这一追求，驱使我持续进行组件库的制作与维护。

当然，关于目前这款针对(iOS)系统的版本，其中蕴含的挑战尤为众多。对于个人自行制作并使用的资源，通常会有一定的妥协与宽容；然而，一旦这些资源面向公众，被众多同行所审视和运用，就务必在各个层面追求极致，比如文件的编排方式、元素的命名规范、组件的灵活性和扩展性标准、制作流程以及满足中英文需求的细节处理等。即便是那些鲜有人关注的条款声明，也需经过反复试验和精雕细琢，最终形成一种最优的、均衡的状态，从而实现真正实用和高效的目标。

关于组件库的组织方式

我在日常工作中所使用的组件库，本质上只是存储在文件中的一个名为“”的页面。在这个页面中，所有颜色、样式、文字风格的设定，以及组件、模块和界面布局等要素都被整合在一起。

这种结构确实有其优点，比如“便于携带”，意味着在创建新文件时，可以直接将 Page 中的所有内容复制过来，从而实现内容的“迁移”；在市场上，众多知名的组件库和模板也普遍采用了这种单一页面的形式。然而，对于本次的“特定项目”而言，情况多少有些不同。

初次尝试对外输出作品，首先要考虑的关键因素之一便是其广泛适用性，也就是说，在摒弃任何特定产品设计的框架后，我们应专注于我们及众多移动端设计师最为熟悉的iOS系统设计风格。系统级的设计模式虽然复杂，但至少在微观层面，确保整个库的架构清晰、层次分明仍是必要的。

尽管不少知名UIKit以单页形式整合了各类元素，然而我并不觉得这些库在实际应用中表现优异。更不用说，它们大多对系统界面进行了高度模仿，从组件的细致程度到色彩搭配，都不太适合交互设计师或产品经理直接用于线框图的制作。

经过全面考量，最终，我的文档被细分为九个页面，其具体结构层次如下：

页面数量众多，手动在不同文件间复制组件库以实现完整套用存在困难，因此我在使用说明中特别指出，用户可以将组件库保存为模板，并以此为基础创建新的项目。

关于样式定义

既然被称为“组件库”，其核心价值必然由组件本身所体现，这包括原子级的控件、图标，以及分子级的栏和列表视图等。然而，正如我在使用说明中所述，“一个命名得当、架构清晰的样式库，是所有组件定义的基础”。构建组件库、设计模板，乃至更广泛的设计体系，首要且关键的工作即是制定全面、细致、易于维护与拓展的样式规范。

我通常会将所谓的“样式定义”细分为三个不同的部分，并按照一定的顺序逐一展开。这些方面分别是：

颜色（）

色彩作为构建信息层次和对比度的关键设计元素之一，对于界面设计领域sketch 图标库插件，这一基本原则不仅在高保真视觉表现上适用，即便是在以线条框和灰色草图风格为主的交互设计中，也同样适用。

与众多好友相似，我亦曾走过“满屏 Axure 原生黑框”的简陋时期，而后又有一段时间，我热衷于运用浅灰色勾勒出简洁雅致的线框草图。随着时间的流逝，我的经验不断丰富，认知水平也有所提高，最终我深刻领悟到，对于交互设计师来说，颜色的运用并非儿戏之举——通过运用不同的灰色调来打造界面整体与局部信息的对比度，从而使内容的层次和节奏变得清晰可见，这有助于其他职能的协作人员轻松迅速地理解交互设计的意图，而这正是交互设计师的一项基本职责。

在处理特定产品的具体需求时，我日常工作中所使用的组件库中包含了超过十种的灰色调；此次项目亦是如此，针对 iOS 系统的特定特性，我们提供了多达十二种色彩方案，其中包括七种灰色，以及纯黑色、纯白色，以及半透明状的黑色和白色等。

那些属于深色区间的灰色，涵盖了从Grey0到Grey4，其深度呈现递减趋势；而归属于浅色区间的灰色，则包括 ，这些颜色同样是从深到浅排列。这种以“Grey”、“Light”和数字为灰色命名的方法在整体上保持了一致性，并且可以进一步应用于样式（ ）以及文字风格（Text ）的命名构建中。然而，与后两者相较，颜色并非构成功能体系的基本元素，缺乏一个能够进行管理和重复利用的所谓“模块”。因此，自行构建并维护一套基础色盘，并在整个系统中保持命名和使用的统一性，显得尤为关键。

将文件保存为模板（Save as），随后基于此模板创建新文件（New From），此时系统色盘中的“配色方案”区块将展示预设的配色选项，便于您在为文字或图形元素选取颜色时使用，尽管如此，在大多数情况下，依旧推荐您使用预设的“文本”或“图形”配色，以实现颜色的集中式管理。

样式（ ）

经过对日常工作中使用的组件库进行整理和总结，在本次活动中，我已将涵盖的52种不同样式进行分类，并将它们归为三大类，以便于在制作各种典型组件时能够灵活运用。

“实色填充”与“空心描边”分别与12种颜色定义相匹配，应用广泛，如用于制作图片和头像的占位符等实色图形，界面背景以及半透明遮罩，以及空心按钮和布局容器等。“这种填充方式及多向边线设计较为复杂，因其涵盖了多种边框方向设定，常用于创建各种栏（Bars）以及表格视图单元格（Table View Cells）。例如，你可以运用‘Fill-White---Grey4’这一设置来创建带有下边框的表格视图单元格样式。”

关于这类单一边框或分隔线样式的制作方法，实际上也是一个颇具趣味性的话题。我通常采用“Inner”属性来完成这一操作，比如，若需为一个矩形添加下边框，只需将“Inner”按照下方的示例图进行相应的配置即可。

同理，要实现左、右边框的样式，则可以：

为何不利用 Line 对象来绘制边框或分隔？实际上，这并无大碍，有时还能带来便利。然而，在调整 Line 或容器尺寸时，可能会遇到一些麻烦。相比之下，直接在容器上应用样式会更灵活、更可靠。若未来能够实现多方向边框的设置，那么这样的麻烦也将不复存在。

文字风格（Text ）

定义文字风格，这个过程在整体样式定义工作中显得尤为棘手，有时甚至可以说是相当繁琐。

该平台提供了468种不同的文字风格定义，每种风格都涵盖了六个属性设置。在这六个属性中，有四个是显性的，文字风格的命名规则正是基于这四个显性属性，具体为“对齐方式、字体粗细、颜色名称、字号”。例如，广泛应用的“Left-Grey1-17”风格，其含义是文字左对齐、采用常规粗细、颜色为Grey1、字号为17号。

排版方式涵盖了左对齐、居中对齐和右对齐，字体粗细分为粗体和正常，色彩选择包括从灰色0号到灰色4号以及白色，字号范围从10号到28号共有13种选择——将这些选项进行组合，其数量级可达三位数。

当然，在众多文字风格中，仅有少数会被频繁采用。然而，从宏观角度来看，我更偏好初期投入充足的时间来打造一套高度统一的样式定义，这套定义能够应对大多数使用场景。我的目的是为了最大程度地减少在后期使用过程中对基础样式进行调整的需求。

隐性属性涵盖了文字的行距和字符间的间隔，这些特性在命名时并不显现，然而在设置过程中却对耐心提出了不小的挑战。一般情况下，即便每个字号文本仅采用预设的两种属性，也极少出现显著问题，顶多只是字距上的细微差异；但若处理多行文本，尤其是我们关注的中文内容，问题便会显现——行高的调整会显著影响文字在垂直方向上的显示位置，而当原本布局精准的英文示例被替换为中文后，垂直方向上的位置关系将出现严重问题。我借鉴了苹果官方及其他第三方作者所提供的UIKit资源，为每一种字号精心调整了其行高和字间距，力求最大限度地恢复系统自带的样式特性。

在线框稿中是否必须对文字的每一个细节进行精确调整，以达成高度的真实还原效果？我坚信这一点是无疑的，尤其在移动设备上，面对小尺寸屏幕和多样的使用场景，对文字的样式、尺寸以及布局的敏感性更是交互设计师不可或缺的素质。

关于命名方式与插件的使用

前文多次提及了命名方式和规则的相关问题，这一环节在此次制作组件库的过程中给我留下了极为深刻的印象。

在颜色、样式、文字风格的界定，以及元件模板、图标、范例界面的设计及编排过程中，始终遵循着统一、普遍、便捷的命名准则。关于样式定义中的命名问题，之前已有详细讨论，此处不再赘述，接下来我们重点探讨其他相关方面。

正如“关于组件库的组织方式”一文所述，本次提供的组件将依照“栏（Bars）”、“列表视图（Table Views）”、“视图（Views）”、“控件”等类别进行划分，每个类别下又细分为多个子类别，例如“栏”类别下包括Bar、Tool Bar、Tab Bar等，而这些子类别则由一系列典型的组件组成。

这样的结构层次清晰，对命名规范提出了严格的标准，既要让制作流程井然有序、条理分明，又要保证最终形成的组件库文件易于索引和运用。为了彰显层次感，我在命名过程中首次引入了“/”符号来区分不同类别，例如“Bars / Bar / ”、“Table Views / Cell / - - Edit Mode”等。

系统能够自动识别“/”符号，并将其作为分类的界线，进而逐级构建，最终呈现出一个完整的目录体系，这正如您在文件的下拉菜单中所观察到的情形。

只要明确所需组件的具体要求，你便可以轻松地逐级进行检索。

而说到插件，并非要罗列“我的20款常用 插件”一类。将命名规则与讨论主题合并在一处，其原因是之前所提及的命名规则的确立并非一蹴而就，无论是针对Text还是其他内容，在命名整理过程中都历经了多轮的反复试验与修正；这些环节中，一些关键插件的作用不可或缺，没有它们，所需完成的工作量将极其庞大；以下将对此进行简要阐述，有相同困扰的朋友不妨一试。

It

此功能适用于批量对选定的图层、图层组或文件夹进行重命名操作，仅限于左侧图层列表中这些对象的名称，并不影响其内容。

该插件设有两种批量处理功能，分别是“自定义批量命名”和“查找与替换层名”，前者允许用户自行设定命名规则，而后者则专注于搜索特定字符并进行替换操作。

Find And

这款插件适用于对文本对象中的具体文字进行批量替换，不同于前一款It插件针对图层列表中的对象名称进行操作；其设置选项多样且实用；在探索命名规则时，我能够利用该插件对样式定义中显示的文字风格名称进行批量修改。

在完成命名规则设定和初始样式或字体属性调整后，如何进行批量生成呢？只需选中所有示例对象，运用该插件提供的特定功能，即可根据所选对象的图层名称自动创建相应的元素，整个过程无需手动进行命名。

小结

大致情形便是如此，涉及此次制作组件库过程中所涌现的思考、所汲取的知识、以及所深刻领悟到的内容。

我们探讨了构建与维护组件库的重要性、组件库的架构设计、风格规范、命名规范以及插件应用的相关内容，涵盖了四大关键领域；尽管未深入到具体操作细节，但作为总结与学习记录，已经足够详尽；同时，我也希望这能为各位提供一定的学习与借鉴价值。

最终仍需向那些购买并持续给予我鼓励与支持的朋友们表达诚挚的感激之情，未来我将继续探索并尝试其他种类的组件库；对于那些尚未熟悉的朋友们，不妨回顾一下之前的介绍，或者扫描下方的二维码直接前往 Store 进行浏览。

如有侵权请联系删除！