在如今化前端中使用特殊字體

需求導向

做爲一個前端，確定遇到過這個需求，UI作出來的設計稿利用了特殊字體。雖然對於前端來講，管你什麼字體，我微軟雅黑通吃，可是有時候UI會很執着，「這個必定要實現，你直接切一張圖片上去也行」。爲了省事，咱們確定是直接切一張圖上去啊，可是每次切完圖以後，圖片都須要加工優化。每次替換文字都要從新編輯psd圖 -> 切圖 -> 優化圖片。因此還原高保真的時候要遵循一個原則，能用html實現的就不要用圖片代替，美言之爲了性能，其實仍是爲了無止境的需求變動。

咱們知道使用特殊字體，只要引入字體的ttf文件（ttf文件，這裏不作介紹，可自行百度）就行。以下：

@font-face {
  font-family: "fashion";
  src: url('./fashion.ttf') format('truetype');
  font-weight: normal;
  font-style: normal;
}
.fashion-font {
  font-family: "fashion";
}
複製代碼

可是字體文件通常包含全部字體，字體文件大小几M，對於前端來講，確定是不能接受的，因此咱們須要對ttf文件進行打包操做，只引用用到的文字，這裏咱們稱靜態文字，後面會介紹動態文字的解決方案。

font-spider

font-spider是一個npm庫，能夠解析html用到特殊字體的文字，按需打包，替換原來的ttf文件，而且在ttf文件目錄下生成一個.font-spider文件夾存放原來總的ttf文件。使用下面命令可進行打包操做：

sudo font-spider --debug src/**/index.html
複製代碼

--debug命令能夠查看解析過程。

結合webpack

若是你是傳統的多頁面應用，這樣的打包方式是沒問題。可是現代前端工程化以後，前端只會有一個index.html入口文件，且css文件是經過js引入的，font-spider沒法解析js裏的css文件，因此那些引用font-family: "fashion";字體的文字都會失效。這裏提供兩個解決方案：

1.在html裏引入絕對路徑的css文件，https://www.baidu.com/index.css。

2.採用相對路徑，基於網站根目錄。通常狀況下webpack工程下都會在項目根目錄下建一個static目錄存放靜態文件。路徑以下：

<link rel="stylesheet" href="./static/mgday2018/font/font.css" type="text/css">
複製代碼

這裏有一點須要注意，打包的時候，font-spider是根據index.html檢索css所對應的相對目錄，好比項目中有多個html文件，因此他們所對應的字體文件的位置須要根據html所在的位置。並且你使用字體的方式，不是在使用的地方上加font-family: "fashion";樣式，而是經過class的方式引入（如class="fashion-font"），這樣打包的時候才能被依賴。

<link rel="stylesheet" href="./static/mgday2018/font/font.css" type="text/css">
  <!-- 下面的地址是爲了兼容font-spider的打包地址 -->
  <link rel="stylesheet" href="../../../static/mgday2018/font/font.css" type="text/css">
複製代碼

最終實現效果

動態文字

有些人會說你這是靜態文字啊，有些文字是經過後端接口返回的，咱們沒法提早打包啊。這裏提供三個解決方案：

1.利用fontmin.js

fontmin.js容許你提早將須要的問題，提早打包，即便文字不在html裏。但這其實這只是解決文字不在html裏，仍是沒解決後端接口返回的文字的問題。參考連接： 移動端引入的字體文件過大處理方法。

2.實時打包

原理：搭建一個node中間層，每次接口返回的時候，先調用node服務fontmin，打包接口中用到的文字，而後返回一個靜態地址給前端，前端拿到接口數據和一個靜態css地址，先加載css地址，再加載文字。可是這會形成很大的資源浪費，且每次生成一個字體文件。這裏再提供一種思路，node中間層每次獲取接口文字，從新編譯頁面中全部須要用到的文字（這裏會有緩存對比，若是文字都已經包含，則不從新打包），再把css地址和數據返回給前端。但不管如何，只能針對幾個接口開放實時打包，不然再大的服務器也抗不住這種壓力。

3.引入整個字體文件

回到老問題，引入整個字體文件。首屏所須要用到的字體文件先單獨打包，先加載首屏須要用的字體文件，再經過延遲加載和cdn，加載整個字體文件。這樣能比較好的實現動態文字的問題。

總結

可見很明顯，動態的文字其實不適合特殊字體，不管怎麼優化，都會浪費不少資源，性能也是一個問題。因此咱們只能指望未來某一天，網速飛快了，幾M的文件能瞬間加載了，這個問題就迎刃而解了。

---

寫做時間：20181118