转转搭建iconfont平台实践

见贤思齐

背景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平台的系统架构由以下几个部分组成：iconfonticon：对上传的svg文件统一处理，保存完整的路径信息大库：和icon建立映射关系，对icon进行分组、编辑、更新，主要面向UI项目：也是和icon建立映射关系，面向FE，挑选icon创建项目，负责生成外链、下载图标等能力用户：对接企业微信扫码登录系统，负责角色和权限管理日志：记录图标的上传、审核、编辑；人员角色的变动；项目的更新等日志信息，使系统的所有操作可追溯svg2ttf：解析svg路径，转换成ttfwoffeot等通用的字体文件，并打包上传到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;}挑选相应图标并获取字体编码3这非常繁琐，用户体验很差。淘宝的iconfont后面推出了font-class的引用方式来简化这个步骤，而YIcon并不支持，所以我们需要大幅降低使用成本——把首选的“下载图标”改成“生成外链”——这一步会把原本需要下载到本地的一大堆字体文件统一上传到CDN，并生成一个css文件链接，在项目中引入即可。@import url('https://s1.zhuanstatic.com/common/font/my-iconfont-1.0.3.css');然后配合zz-ui组件库，开箱即用。另外，项目的每一次变动都会生成递增的版本号，所以作为普通静态资源使用强缓存策略即可，对性能也非常友好。功能性改造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的质量。成果最后回顾一下iconfont项目，虽然遇到了一些波澜，但总体上还是完成了预期的目标。在提高UI团队和FE团队的配合效率、提高iconfont资源的可维护性和最终呈现的用户体验等环节，都有显著的成效。后续iconfont平台也会进一步提高体验，比如这两天淘宝iconfont团队分享的文章，iconfont支持全新的彩色字体图标，就很值得关注和跟进，彩色化一定会让iconfont有更广阔的应用前景。参考资料[1]iconfont:https://www.iconfont.cn/collections/index[2]YIcon:http://ued.qunar.com/yicon/index.html