转转搭建 iconfont 平台实践-技术圈

点击上方程序员成长指北，关注公众号

回复1，加入高级Node交流群

背景

icon 的管理是设计稿转代码过程中，重要但容易被忽视的环节。

所以在实际的业务代码中 icon 问题的解决方案往往也是八仙过海，能用就行。比如导出为 png, svg 格式的文件，在项目中作为静态资源直接引用，或者上传到 CDN 作为外链引用。显然这些方案多少都存在着一些小问题：

在用户体验上，包括在高分辨率屏幕上显示模糊、增加额外的 http 请求、异步加载造成页面抖动等；
在开发体验上，包括无法通过 CSS 控制样式以便和文本保持一致、难以复用和更新等。

为了解决上述问题，规范一点的做法是把设计稿 icon 转换成 iconfont 字符集，在项目中导入字体文件使用。对于初创团队而言，淘宝免费的 `iconfont`^[1] 网站无疑是快速的解决方案：上传 icon ——生成项目——一键下载，非常方便。然而有几个问题阻碍了它成为企业级的解决方案：

一个是项目间无关联，相同 icon 无法复用和统一更新；
一个是无法强绑定企业账户，在团队协作和人员更迭交接时不可控；
最后一个是 icon 的版权问题，所有人都可以免费使用所有人上传到平台的 icon ，这可能不是公司所希望的。

所以上述的解决方式在项目初期可能确实可以快速解决问题，但随着业务复杂度的指数级别增长，开发周期的拉长，以及项目维护人员的更迭，这都可能成为后期无法维护的技术债，降低开发效率，影响用户体验。在转转的技术体系中，iconfont 平台作为物料中心建设的组成部分，是不可或缺的一环。

预期目标

icon 作为设计规范和物料资源，也有着团队协作和版本更迭的强需求，正如成熟的研发团队往往会部署自己私有的 GitLab 服务管理代码资源一样，搭建自有的 iconfont 平台也应该在合适的时候被提上日程，以解决上述痛点。

我们希望 iconfont 平台可以实现：

明确角色的职责：UI 贡献 icon；FE 使用 icon
权限管理体系
可持续的迭代、同步、和维护
icon 统一分发、同步更新
快速接入到项目中使用

技术选型

从零搭建一套功能完善的 iconfont 管理平台成本是很高的，我们决定先调研市面上支持私有部署的开源项目，通过简单的改造使项目快速落地。直接说结论：其实选择并不是很多，比较好改造的就 Nicon 和 YIcon。基于以下几个因素，我们最终选择了 YIcon 作为原型：

Nicon 是个人开源的项目，YIcon 是去哪儿团队开源的项目，有企业级应用的实际场景；
从功能上来说：YIcon 功能更加完善，包括角色权限管理等；
迭代版本和使用率来说：YIcon 迭代了更多的版本，使用人数也更多；
技术栈来说：数据库 Nicon 使用的是 MongoDB，YIcon 使用的是 MySQL，更符合公司的技术规划方向。

YIcon 架构介绍

YIcon^[2] 是一个集图标上传、展示、使用于一身的字体图标管理平台，拥有严格的审核流程、可控的项目版本和完善的权限管理。系统的 iconfont 使用 unicode 编码（尽管大部分编码都有其固定作用，但 unicode 留出了一个『私用区』可以用来进行字体扩展，这一区域的码值范围是：E000 - F8FF），大概能容纳 6400 个 icon，这个数量虽然不能肆意挥霍，但对于正常的业务需求也可以算是绰绰有余了。

技术栈上，YIcon 基于 React + Koa + MySQL 搭建，前端后端和数据库都采用了比较成熟的技术栈，源码的学习成本不算太高。

YIcon 提供的功能如下所示：

简单来讲，iconfont 管理平台主要面向 UI 和 FE，提供这样一个工作流：

UI 负责把 icon 上传到平台，通过不同的“大库”区分业务线，形成一个 icon 池；
而 FE 则根据项目需要，从 icon 池中挑选 icon，生成项目，导出外链，引入到项目中使用。

所以 iconfont 平台的系统架构由以下几个部分组成：

icon：对上传的 svg 文件统一处理，保存完整的路径信息
大库：和 icon 建立映射关系，对 icon 进行分组、编辑、更新，主要面向 UI
项目：也是和 icon 建立映射关系，面向 FE，挑选 icon 创建项目，负责生成外链、下载图标等能力
用户：对接企业微信扫码登录系统，负责角色和权限管理
日志：记录图标的上传、审核、编辑；人员角色的变动；项目的更新等日志信息，使系统的所有操作可追溯
svg2ttf：解析 svg 路径，转换成 ttf woff eot 等通用的字体文件，并打包上传到 CDN

项目改造

回顾我们之前列出的预期，可以说 YIcon 在很大程度上是满足了我们的需求的，接下来我们就对未满足的环节进行改造。

登录系统

YIcon 原设计是支持内部系统 cas、sso 或 ldap 等三种登录模式，但是不支持第三方登录。这需要改造成转转内部系统统一的企业微信扫码登录模式，并调用账号系统接口做权限处理，登录后自动注册角色，初始化权限。

使用方式

YIcon 原先的使用方式，类似于淘宝的 iconfont，需要在项目中点击“下载图标”按钮，把一大堆字体文件下载到本地，拷贝到项目中，然后按部就班地修改以下代码：

定义生成的 font-face

@font-face {
  font-family: 'iconfont';
  src: url('iconfont.eot');
  src: url('iconfont.eot?#iefix') format('embedded-opentype'),
    url('iconfont.woff') format('woff'),
    url('iconfont.ttf') format('truetype'),
    url('iconfont.svg#iconfont') format('svg');
}

定义使用 iconfont 的样式

.iconfont{
  font-family: "iconfont" !important;
  font-size: 16px;
  font-style: normal;
  -webkit-font-smoothing: antialiased;
  -webkit-text-stroke-width: 0.2px;
  -moz-osx-font-smoothing: grayscale;
}

挑选相应图标并获取字体编码

<i class="iconfont">&#x33;</i>

这非常繁琐，用户体验很差。淘宝的 iconfont 后面推出了 font-class 的引用方式来简化这个步骤，而 YIcon 并不支持，所以我们需要大幅降低使用成本——把首选的“下载图标”改成“生成外链”——这一步会把原本需要下载到本地的一大堆字体文件统一上传到 CDN，并生成一个 css 文件链接，在项目中引入即可。

@import url('https://s1.zhuanstatic.com/common/font/my-iconfont-1.0.3.css');

然后配合 zz-ui 组件库，开箱即用。

<z-icon class-prefix="my-iconfont" name="star" />

另外，项目的每一次变动都会生成递增的版本号，所以作为普通静态资源使用强缓存策略即可，对性能也非常友好。

功能性改造

YIcon 最后一次更新是在 2017 年，年久失修，坦白讲改造工作的成本比预期的要高得多，无论是流程的不合理还是系统自带的 bug，数量都超过了我们对开源项目的理解。

MySQL 数据库升级，语句优化和规范
升级 svg2ttf，解决版本过低导致的 svg 解析错乱
流程优化（包括上传、审核、版本更迭、角色权限等环节的各种 bug）

项目落地

这部分的工作虽然属于推动项目落地部分，但前期的调研，其实比后期的推广更重要。做一个面向用户的产品，先了解用户的痛点和需求，只有戳中了用户的痛点和需求，才能得到用户的认可，项目才能顺利落地。做技术要避免“自嗨”，避免醉心于酷炫的技术而忽视了用户的诉求，这也是转转价值观中重要的理念。

前期调研

所以我们前期花了大量的时间，在 UI 团队和 FE 团队调研和沟通，以确保 iconfont 平台正是他们想要的。

这其实是第一节背景介绍的内容，正是因为了解到无论是 UI 团队还是 FE 团队，对 iconfont 平台都有着各自的迫切诉求，希望设计能更好的被还原，希望设计资源能更好的被归档和迭代，希望能有更省心省力的系统来对接工作...等等。

后期推广

在平台上线之后，我们也面向 UI 团队和 FE 团队分别做了推广，明确了各方的职责，以更好地相互配合。这样的工作流是十分清晰的：

UI 负责统一管理 icon 资源——把 icon 上传到平台，通过不同的“大库”区分业务线，形成 icon 池；
而 FE 则只需关心自己的项目——从池中挑选 icon，生成项目，导出外链，引入到项目中使用。

小插曲

接入新的工作流的过程中，其实也有一些历史遗留问题。

比如之前 UI 并不需要自己把 svg 转换成 iconfont，所以在设计的时候也自然不会去考虑路径闭合、形状合并或者尺寸规范之类的问题，导致部分图标上传到平台后无法解析的问题。放在以前这都是 FE 需要头疼的问题，也可能会导致相互扯皮，而如今 UI 则需要梳理一下历史图标，自己把握 icon 的质量。