轉轉搭建 iconfont 平臺實踐

點擊上方 程序員成長指北，關注公眾號

回復1，加入高級Node交流群

背景

icon 的管理是設計稿轉代碼過程中，重要但容易被忽視的環(huán)節(jié)。

所以在實際的業(yè)務代碼中 icon 問題的解決方案往往也是八仙過海，能用就行。比如導出為 png, svg 格式的文件，在項目中作為靜態(tài)資源直接引用，或者上傳到 CDN 作為外鏈引用。顯然這些方案多少都存在著一些小問題：

• 在用戶體驗上，包括在高分辨率屏幕上顯示模糊、增加額外的 http 請求、異步加載造成頁面抖動等；
• 在開發(fā)體驗上，包括無法通過 CSS 控制樣式以便和文本保持一致、難以復用和更新等。

為了解決上述問題，規(guī)范一點的做法是把設計稿 icon 轉換成 iconfont 字符集，在項目中導入字體文件使用。對于初創(chuàng)團隊而言，淘寶免費的 `iconfont`^[1] 網站無疑是快速的解決方案：上傳 icon ——生成項目——一鍵下載，非常方便。然而有幾個問題阻礙了它成為企業(yè)級的解決方案：

• 一個是項目間無關聯(lián)，相同 icon 無法復用和統(tǒng)一更新；
• 一個是無法強綁定企業(yè)賬戶，在團隊協(xié)作和人員更迭交接時不可控；
• 最后一個是 icon 的版權問題，所有人都可以免費使用所有人上傳到平臺的 icon ，這可能不是公司所希望的。

所以上述的解決方式在項目初期可能確實可以快速解決問題，但隨著業(yè)務復雜度的指數級別增長，開發(fā)周期的拉長，以及項目維護人員的更迭， 這都可能成為后期無法維護的技術債，降低開發(fā)效率，影響用戶體驗。在轉轉的技術體系中，iconfont 平臺作為物料中心建設的組成部分，是不可或缺的一環(huán)。

預期目標

icon 作為設計規(guī)范和物料資源，也有著團隊協(xié)作和版本更迭的強需求，正如成熟的研發(fā)團隊往往會部署自己私有的 GitLab 服務管理代碼資源一樣，搭建自有的 iconfont 平臺也應該在合適的時候被提上日程，以解決上述痛點。

我們希望 iconfont 平臺可以實現：

• 明確角色的職責：UI 貢獻 icon；FE 使用 icon
• 權限管理體系
• 可持續(xù)的迭代、同步、和維護
• icon 統(tǒng)一分發(fā)、同步更新
• 快速接入到項目中使用

技術選型

從零搭建一套功能完善的 iconfont 管理平臺成本是很高的，我們決定先調研市面上支持私有部署的開源項目，通過簡單的改造使項目快速落地。直接說結論：其實選擇并不是很多，比較好改造的就 Nicon 和 YIcon?；谝韵聨讉€因素，我們最終選擇了 YIcon 作為原型：

1. Nicon 是個人開源的項目，YIcon 是去哪兒團隊開源的項目，有企業(yè)級應用的實際場景；
2. 從功能上來說：YIcon 功能更加完善，包括角色權限管理等；
3. 迭代版本和使用率來說：YIcon 迭代了更多的版本，使用人數也更多；
4. 技術棧來說：數據庫 Nicon 使用的是 MongoDB，YIcon 使用的是 MySQL，更符合公司的技術規(guī)劃方向。

YIcon 架構介紹

YIcon^[2] 是一個集圖標上傳、展示、使用于一身的字體圖標管理平臺，擁有嚴格的審核流程、可控的項目版本和完善的權限管理。系統(tǒng)的 iconfont 使用 unicode 編碼（盡管大部分編碼都有其固定作用，但 unicode 留出了一個『私用區(qū)』可以用來進行字體擴展，這一區(qū)域的碼值范圍是：E000 - F8FF），大概能容納 6400 個 icon，這個數量雖然不能肆意揮霍，但對于正常的業(yè)務需求也可以算是綽綽有余了。

技術棧上，YIcon 基于 React + Koa + MySQL 搭建，前端后端和數據庫都采用了比較成熟的技術棧，源碼的學習成本不算太高。

YIcon 提供的功能如下所示：

簡單來講，iconfont 管理平臺主要面向 UI 和 FE，提供這樣一個工作流：

• UI 負責把 icon 上傳到平臺，通過不同的“大庫”區(qū)分業(yè)務線，形成一個 icon 池；
• 而 FE 則根據項目需要，從 icon 池中挑選 icon，生成項目，導出外鏈，引入到項目中使用。

所以 iconfont 平臺的系統(tǒng)架構由以下幾個部分組成：

• icon：對上傳的 svg 文件統(tǒng)一處理，保存完整的路徑信息
• 大庫：和 icon 建立映射關系，對 icon 進行分組、編輯、更新，主要面向 UI
• 項目：也是和 icon 建立映射關系，面向 FE，挑選 icon 創(chuàng)建項目，負責生成外鏈、下載圖標等能力
• 用戶：對接企業(yè)微信掃碼登錄系統(tǒng)，負責角色和權限管理
• 日志：記錄圖標的上傳、審核、編輯；人員角色的變動；項目的更新等日志信息，使系統(tǒng)的所有操作可追溯
• svg2ttf：解析 svg 路徑，轉換成 ttf woff eot 等通用的字體文件，并打包上傳到 CDN

項目改造

回顧我們之前列出的預期，可以說 YIcon 在很大程度上是滿足了我們的需求的，接下來我們就對未滿足的環(huán)節(jié)進行改造。

登錄系統(tǒng)

YIcon 原設計是支持內部系統(tǒng)  cas、sso 或 ldap 等三種登錄模式，但是不支持第三方登錄。這需要改造成轉轉內部系統(tǒng)統(tǒng)一的企業(yè)微信掃碼登錄模式，并調用賬號系統(tǒng)接口做權限處理，登錄后自動注冊角色，初始化權限。

使用方式

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 并不支持，所以我們需要大幅降低使用成本——把首選的“下載圖標”改成“生成外鏈”——這一步會把原本需要下載到本地的一大堆字體文件統(tǒng)一上傳到 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" />

另外，項目的每一次變動都會生成遞增的版本號，所以作為普通靜態(tài)資源使用強緩存策略即可，對性能也非常友好。

功能性改造

YIcon 最后一次更新是在 2017 年，年久失修，坦白講改造工作的成本比預期的要高得多，無論是流程的不合理還是系統(tǒng)自帶的 bug，數量都超過了我們對開源項目的理解。

• MySQL 數據庫升級，語句優(yōu)化和規(guī)范
• 升級 svg2ttf，解決版本過低導致的 svg 解析錯亂
• 流程優(yōu)化（包括上傳、審核、版本更迭、角色權限等環(huán)節(jié)的各種 bug）

項目落地

這部分的工作雖然屬于推動項目落地部分，但前期的調研，其實比后期的推廣更重要。做一個面向用戶的產品，先了解用戶的痛點和需求，只有戳中了用戶的痛點和需求，才能得到用戶的認可，項目才能順利落地。做技術要避免“自嗨”，避免醉心于酷炫的技術而忽視了用戶的訴求，這也是轉轉價值觀中重要的理念。

前期調研

所以我們前期花了大量的時間，在 UI 團隊和 FE 團隊調研和溝通，以確保 iconfont 平臺正是他們想要的。

這其實是第一節(jié)背景介紹的內容，正是因為了解到無論是 UI 團隊還是 FE 團隊，對 iconfont 平臺都有著各自的迫切訴求，希望設計能更好的被還原，希望設計資源能更好的被歸檔和迭代，希望能有更省心省力的系統(tǒng)來對接工作...等等。

后期推廣

在平臺上線之后，我們也面向 UI 團隊和 FE 團隊分別做了推廣，明確了各方的職責，以更好地相互配合。這樣的工作流是十分清晰的：

• UI 負責統(tǒng)一管理 icon 資源——把 icon 上傳到平臺，通過不同的“大庫”區(qū)分業(yè)務線，形成 icon 池；
• 而 FE 則只需關心自己的項目——從池中挑選 icon，生成項目，導出外鏈，引入到項目中使用。

小插曲

接入新的工作流的過程中，其實也有一些歷史遺留問題。

比如之前 UI 并不需要自己把 svg 轉換成 iconfont，所以在設計的時候也自然不會去考慮路徑閉合、形狀合并或者尺寸規(guī)范之類的問題，導致部分圖標上傳到平臺后無法解析的問題。放在以前這都是 FE 需要頭疼的問題，也可能會導致相互扯皮，而如今 UI 則需要梳理一下歷史圖標，自己把握 icon 的質量。

成果

最后回顧一下 iconfont 項目，雖然遇到了一些波瀾，但總體上還是完成了預期的目標。在提高 UI 團隊和 FE 團隊的配合效率、提高 iconfont 資源的可維護性和最終呈現的用戶體驗等環(huán)節(jié)，都有顯著的成效。

后續(xù) iconfont 平臺也會進一步提高體驗，比如這兩天淘寶 iconfont 團隊分享的文章，iconfont 支持全新的彩色字體圖標，就很值得關注和跟進，彩色化一定會讓 iconfont 有更廣闊的應用前景。

參考資料