图标虽小门道多！带你回顾图标简史，了解其来龙去脉

图标的体积虽然不大，其中蕴含的学问却相当丰富。可以说，图标的演变过程是整个网络技术发展历程的一个缩影。本文将为你梳理图标的发展历史，让你明白图标技术的演变轨迹。

古代：一个图标一张图

远古时期的象征，本质上就是一幅图画。那个年代的网络速度迟缓，六十秒才能载入一个站点，所以信息量是关键，视觉设计反而不重要，“没什么价值”的符号还没有被当作网页不可或缺的部分。标志数量稀少，应用场景有限，自然就没人去精心制作了。

近代：CSS Sprites（雪碧图）

网络信息急剧增加，同质化竞争日益激烈，创新手段趋于枯竭，行业焦点开始转向服务品质。这种转变促使网站更加注重用户感受，力求提供更优质的服务。尽管后来内容创作再度成为热点，但这已是另一段发展历程。

追求体验差异的方法五花八门，但在宽带网络尚未普及的年代，最明显的体现就是数据加载的快慢。采用“一个图标对应一张图片”的设计思路，在加载速度上会遇到明显瓶颈。这种瓶颈主要源于两个因素：一是建立连接所需的时间，二是浏览器允许同时下载的任务数目的上限。前者受到 HTTP 协议的制约，后者则与浏览器的具体实现有关。

HTTP 的约束条件不难明白,通过代理、DNS 查询、建立连接、发起询问以及响应首次字节所需的时间,对于图标这类微小文件而言,往往要远远长于它们被载入的时间。

浏览器同时处理太多任务的情况，在技术层面上是必须加以约束的。若不控制并发下载的数量，首先，浏览器会启动众多工作进程，导致用户设备难以承受；其次，服务器将面临海量同时抵达的访问指令，服务器同样会承受巨大压力，很容易使一些技术基础较弱的站点崩溃。

浏览器会控制同时下载的数量，如果请求的数量超过了设定的限制，多余的请求就必须等待，对于那些包含大量图标、图片、样式表和脚本的小文件页面，即便网络传输速度很快，这种等待过程也可能持续相当长的时间。

明显，改进的目标是降低同时进行的下载量，因此，改进的方法也就一目了然了：将所有的小图像合并成一张大图，再设法让浏览器将其再次分割成若干部分。正好，浏览器有个功能叫做background-position，换言之，如果我们把这张大图设为某个元素（宽为w、高为h）的背景图，并且设定了background-position的值为(x, y)，那么这个元素的背景就会是大图上从(x, y)到(x+w, y+h)所截取的那部分区域。这样操作之后，N 个并发下载就整合成了一个大图文件，以及一个 CSS 文件。

这种做法若采用人工组合，过程相当复杂，为此人们研制了专用程序，将其纳入整体开发流程，同时界面设计相关的一些软件也开始支持直接生成合并图像的功能。

近代：Data URL

将多个图片整合为一张雪碧图并非唯一途径，另一种方法也能有效降低同时发出的数据请求量，即采用数据网址形式。

Data URL 的基本格式是这样的：以 data 开头，后面跟着一个冒号，接着是内容类型，再接一个分号，然后是编码方式，比如 image/svg+xml 表示图像的 SVG 格式，utf8 表示字符编码，base64 编码则是在 data 后面加上 base64，并以一个分号和空格开始，编码内容以一个句号结束，例如 PHN2ZyB4bWxucz0iaHR0cDo。

浏览器看待 Data URL 和常规的 http URL 并无差异，唯独无需进行额外获取。因此，所有适用 http URL 的场景，均能替换为 Data URL，例如在网页代码中

，在css里设置背景图片为url括号内的地址，这样就能把图标获取和html及css文件下载整合在了一起。

但是，这种方式也有缺点，那就是拖慢了整体渲染速度。

一般来说，网页加载的顺序是先加载主体结构，再加载样式，最后加载其他附件，所以经常出现网页主体内容已经呈现，但图片却只加载了一部分，需要一段时间才能全部显示出来。如果我们把很多图标直接放在样式表或者主体代码里，就会让这些文件变得更大，从而使得网页在初始阶段加载得更加缓慢。

因此，采用 Data URL 方式必须慎重评估，要依据性能测试结果来调整。

现代：字体图标

随着视网膜屏幕的出现，图标遭遇了前所未有的困境，即清晰度要求。

一般情况下，图标文件像素尺寸与屏幕显示尺寸相匹配，但在高分辨率显示设备上，这一说法不再适用。当设备像素比值为三时，图标需使用九个点才能在屏幕上呈现一个标准显示单位，否则图像会显得不够细腻。

即便不把文件体积当作考量因素，也必须对既有工作流程加以革新才行。不妨索性另寻他途进行尝试。

近代的另一项发明派上了用场，那就是“自定义字体”。

这项技术原本旨在改善网页文字的呈现效果，例如若需展示用户设备中不存在的特色字体，只需附加相应的字体文件，此类文件内含目标文字的字体轮廓信息即可实现。这些轮廓数据属于矢量类型，其作用在于展现每个字符的绘制方式：起始点是 0,0，通过 50%,10% 这个中转坐标，生成一条贝塞尔曲线，最终到达 100%,30% 这个终点位置。这种数据不会受到显示设备分辨率的影响，与我们平时观察到的文字表现一致，不论放大多少倍都不会出现模糊或变形的情况。实际上，这正是所有矢量图形绘制方法都具备的一个显著长处。请记住它，因为后面我们还会用到另一种矢量绘图技术。

既然能够操控呈现内容，将字母 A 变成手写形态的 A，那么是否也能让它变成一个与 A 样貌迥异的图形呢？譬如……一座房屋？确实能够实现，实际上，这正是字体图标的运作方式。

字体图标具备一个长处，就是它本质上就是文字，可以像普通文字一样调整大小，可以改变颜色，还可以设定行高，不受任何限制。这种图标在运用时，经常需要和普通文字并排出现，这种特性完全符合我们的需求。

不过，字体图标也有一些缺点。

最主要的不足之处在于只有单一色调。因为字体文件里仅包含轮廓信息，不涉及色彩信息，所以，由这类字体生成的图标必然是单色的。这种情况在某些使用环境下难以满足需求。

其次是工具链过于繁复，尽管存在部分工具能够将一组矢量图文件组合生成字体文件，但这些工具对矢量图的规格有十分严苛的限定，并非所有矢量图都适用。你很难向用户体验设计师阐明哪些图形能够使用、哪些图形无法使用。其次，即便 svg 能够使用，你也很不清楚如何向工具说明每个图标的基准点是哪里，通俗地讲，基准点是指这个图标的底部和字母 g 的底部是否对齐，或者是和字母 h 的底部对齐。

这些特质使得在常规组合中运用专属字体符号变得十分不便。幸而存在一些非常规的组合，例如 FontAwesome，他们专门开发并维护了一批无成本符号资源提供给公共协作领域。倘若你所需的符号恰好在其中，便可以直接选用，你只需执行引入它的样式表文件，然后在文档里进行标记。

当代：svg 图标

这个图标库虽然不错，却并非包治百病。它常常难以融入用户体验的设计规范，而用户体验显然也不肯迁就图标，为了适配图标而调整自身的整体风格。

所以，对研制集体更适宜的做法要能灵活调整，并且便于逐个操作。倘若能直接运用界面设计者提交的矢量图形文件，那无疑是最完美的。麻烦的是，具体该怎样实施。这其中涉及诸多技巧。

当前情况下，雪碧图和数据链接依然适用，因为它们只关注图像本身，不关心图像的具体类型，svg 同样属于图像，具备类似的利弊——不过它具备适配高分辨率显示的能力

不过，svg 的特点，让我们还有了一些另外的用法。

首先，可以将 svg 直接嵌入 html 文档中。svg 与 html 在语法结构上十分相似，二者都属于 xml 语言族系，只是采用了不同的命名空间定义（xmlns）。因此，我们可以把 svg 当作一个元素直接插入到 html 中，当前版本的浏览器能够准确解析它们。这种用法显得十分流畅，在网页中添加的样式同样能够对图形内部的物件产生效果，图像和文字能够完全融合。

这种用法存在两个弊端，首先，svg 内部各个元素的标识符会纳入页面整体命名体系，举例来说，若在 svg 中引入了一个称作 a 的滤镜效果，假设 html 或其他 svg 文件也定义了同名滤镜，就会引发命名冲突，这种情况下，在规模较大的项目中，处理此类冲突会变得十分棘手。其次，该标志物若频繁出现，其信息将在网页代码里反复呈现，文件大小也随之增长。

幸运的是，svg 提供了一种解决方案，那就是 use 标签功能。借助这个标签，能够通过 id 来调用当前页面内的 svg 组件，同样也可以引用来自其他 svg 文件中的组件。例如要选取本页中标识为 a 的矩形框，只需输入相应代码，同时在此处可以自行设定 svg 属性，用以变更初始元素上的 svg 参数，如此一来，图标内容被反复使用的情况便得以消除。若采用此种方式，则能够应用源自外部文件 path/to/file.svg 中所设定的成分，因而 id 冲突的难题亦可获得化解，毕竟它们归属于不同的命名范畴。

不过，这种方式相对于字体图标还有两个缺点：

图标色彩不会随文字色彩自动变化，例如初始元素设定的矩形为红色，无论将其放置在任何色彩的文本中，它始终维持红色。难道需要在每个应用场合手动调整其色彩吗？完全无需这样，另有一种特性能够应对此问题，即当前色彩。这个值代表一种预设的特殊色彩，实际效果等同于采用当前文字的色调。举例来说，若将此值用于图标，并置于灰色文字旁边，那么图标的背景色会呈现灰色；若置于蓝色文字旁边，背景色则变为蓝色。此外，图标的其它区域依然允许单独设定颜色，例如主体部分可以跟随文字色调变化，而特定区域则始终显示为蓝色。处理完成后，你不仅能够克服字体图标的不足之处，还能再进一步，实现彩色图标的显示功能！即便你并不需要彩色图标，依靠 svg 对元素透明度的处理能力，也能让你的图标比字体图标更加色彩斑斓。

其次标志的尺寸不会随文本大小自行调整，但这个问题很简单，因为样式表中有一个功能，能够将当前文字大小作为度量基准，即em单位，例如将标志尺寸设定为1em，就能使标志的实际大小与当前文字大小相同。

当代：合字（Ligature）

知道“囍”这个符号吗？它其实并非一个独立的汉字，而是由两个汉字组合而成的“合字”。这两个汉字原本分别存在，但它们被设计在一起，看起来就像一个整体。由于这个组合非常普遍，所以在文字库中，它被赋予了独立的编码位置。然而，相当一部分类似组合无法享受这种特殊对待，诸如“孔孟勤学”的并置，还有“biangbiang面”里的“biang”符号；拼音标注的声调（例如中文方案）也是合成字符。

怎样借助规范手段来呈现这些复合字符呢？事实上，当代的字体集合早已具备处理复合字符的功能，只是日常生活中应用频率不高，多数人并未察觉。然而，在图形符号设计方面，这类字符重新获得了广泛的应用机会。我所了解的初始采用复合图形标志的体系是谷歌的材质设计，例如输入home就能呈现一座房屋，其运作方式是怎样的？实际上，material-icons 类为这个 i 元素指定了支持合字的字体库，即 'Material Icons'，接着会在该字体库中查找 home 这个合字所对应的单字，然后显示出那个单字即可。换言之，home 是某个单字的别称。

但是，我们为何不学 FontAwesome 直接调用这个独立符号，反而要借助复合字做过渡呢？要解答这个问题，首先得明白一个关键点，那就是：

访问互联网并不是我们这些健全人的专利！

全球范围内存在大量身体有障碍的人士，其中包括视力受损者，例如全盲者、视力不佳者等，并且将来我们自己年老时，也有可能会成为他们中的一员。这些人浏览网络时，无法像我们那样通过眼睛看懂网页内容，而是必须借助一种辅助工具来读取信息。

显示屏程序不能识别某个文字代表房屋图标的含义，所以网页的设计者必须给这个图标附上特殊的 a-label等标记，让屏幕阅读程序能够读出它们。这种做法叫做无障碍设计，简称为a11y。想想看，你添加过多少这种标记？许多人都不添加，觉得太麻烦。合字无需考虑相关难题，它本身具备可读性，在 html 中的表达方式与常规文本相同。因此，只要你顺其自然地运用合字，便已符合 a11y 的部分标准。

所以，尽管“合字”本身创新性不大，我还是将它划入“当代”，它理应作为一种现象受到关注。

图标在开发中的其它方面

在实际的开发工作中，还有一些问题需要考虑。

第一个议题是树形结构精简，即那些未被实际应用的图标应当由系统自动剔除，无需人工介入去甄别哪些图标未被运用，并从原始代码中移除它们。以往多数方法难以提供确切结果，唯有将svg直接内嵌的方式较为得当。具体而言，开发一个构建程序，若在html文档中检测到某个

当获取这个 svg 文件的资料，并且直接嵌入到 html 文档里，那么只要某个文件从未被其他地方调用过，就会自动被移除。如果你使用的是基于 WebPack 的打包工具，可以采用我开发的一个 “markup-inline-loader”插件。现代框架如 Angular，使用起来无需额外操作。只需将每个图标单独设计成组件，以 svg 图形作为其内容模板，然后像其他组件一样进行调用。未使用到的图标，Angular 会自动进行清理。

第二个问题涉及单页面应用。当前多数前端项目采用单页面架构，因此通常无需一次性下载众多图标资源，而是采取按需加载模式。这种做法与过去那种每个图标对应独立图片的做法存在差异。针对你的具体工作环境，进行流程分析后，或许会发现这种传统方式反而更为适宜。

第三个问题在于对 svg 文件进行精简。许多生成工具输出的矢量图数据冗余，包含大量对视觉呈现无用的信息。部分矢量图标即便压缩至原尺寸的一半，其显示效果依然不受影响。由此可见，专门针对 svg 格式进行优化，能够带来切实的益处。当然，这件事无需手动完成，有个现成的软件能处理这个工作，它叫做 svgo，你只需执行 npm i -g svgo指令就能完成全局部署，这个工具可以对单个文档或整个文件夹进行优化，既可以单独使用，也可以纳入工作流程中。

结语

这些图标技术，先后问世，并非彼此取代那么简单，各有长处和短处，适合不同的使用环境。

市场环境和科技发展不断更新，采购方案需要相应地改变，部分情形下需将多种方法组合，以便充分利用它们各自的长处。

继续浏览有关 图标简史Web技术演化 的文章