(切圖仔)前端開發者一大重要的職責就是將 UI
畫稿轉化爲實際可用的頁面,效果圖的還原度在至關大的程度上決定了 UI
和 PM
的滿意度html
通常狀況下,拿到設計稿後,懶散點的可能直接看圖軟件打開,肉眼測距就開搞了,負責點的會打開 PS
或者更正規的 Photoshop
,力圖精確到 px
,這兩種方法各有利弊,前者的還原度大機率堪憂,後者耗時耗力,能把眼睛看瞎,最後都不必定能過得了設計師的像素眼前端
鄙人不才,剛好熱衷並擅長於肉眼測距,只要不是苛刻到死盯像素級的差別,那麼徹底足夠交差,然而天有不測風雲,公司的設計部近來加大了對設計稿還原度的較真勁頭,致使我與設計師之間擺頭的頻率直線拉昇,一來二去以後筋疲力盡,細細想來,不是長久之計,因而決定着手從根源上解決這個問題webpack
肉眼測距與 PS
測量各有利弊,最好能摒棄糟粕並把這兩個的優勢結合到一塊兒,肉眼測距的優勢是短平快,缺點是不夠精確,PS
測距的優勢是夠精確,缺點是太慢了,碰上趕進度的需求根原本不及,因此須要作到既快又準git
那麼,若是把還原稿從 PS
中移到正在開發的頁面上,再加上一些必要的輔助能力,好比測距,這不就能解決上面的問題了嗎?github
通常狀況下,不管開發 PC
端的頁面仍是移動端的頁面,咱們都是習慣於在 PC
的瀏覽器上進行調試,既然是瀏覽器,那麼我首先就想到瀏覽器擴展插件了web
這個插件最好具有如下幾個功能:chrome
PS
的標尺,方便調節0.5
的像素混合重疊後,合成後的顏色將變爲灰色,這是一個很直觀的斷定像素是否相同的因素因而,能夠先上效果圖了:npm
需求點有了,設計稿有了,實現就很簡單了canvas
此 chrome
擴展插件,主要分爲三個部分瀏覽器
也就是上面那個圖,鼠標點瀏覽器的右上角擴展插件圖標後出現的頁面
這個頁面就是個展現層,整合上面所說的那幾個功能點,響應用戶的操做,主要就是頁面繪製與事件註冊
注入到實際開發頁面上的代碼,用於響應 popup
的動做
前端操做圖片最方便的就是 canvas
了,經過將設計稿繪製到 canvas
上,能夠很輕易地實現上面說的那幾個功能點
此腳本會向頁面上追加一個 canvas
元素,設計稿的承載以及功能點的實現,例如反相、透明等都在這個 canvas
上實現
此腳本是做爲一個數據緩存庫來用的,由於 popup
的生命週期很短,展示了就是生成,消失了就是銷燬,沒法長時間地保存變量值,須要經過此腳原本間接保存
插件的運行就是依靠這三部分相互通訊完成,核心代碼很簡單,我就很少說了,感興趣的能夠本身看下,源碼地址
因爲 uipx-chrome-plugin
是一個 chrome
的擴展插件,沒法在移動端使用,而移動端幾乎又是我現今開發的所有場景,有些不太方便,雖然通常而言也都是在 chrome
的模擬移動設備下完成移動端開發,但不實際弄到真機上總感受不得勁,因而在小夥伴的啓發下,決定將 uipx-chrome-plugin
改形成一個 webpack
插件,表現形式就直接(抄)參考 vconsole-webpack-plugin
具體原理基本上和 uipx-chrome-plugin
差很少,只不過是平臺 API
差別罷了,另外,此插件徹底是經過 js
注入的,因此也不像 uipx-chrome-plugin
那樣能夠直接寫 html
,不過這都很容易解決
此插件已經發布到 npm 了,能夠直接下載使用,源代碼也已經上傳到 Github 感興趣的能夠下載使用
這兩個插件代碼層面上沒什麼難度,但確實又能夠解決實際問題,這種輪子仍是能夠造一造的,另外,輪子的代碼和平時業務代碼的差別仍是比較大的,更能體現出一我的的編碼水平和風格,沒有業務的桎梏,在寫代碼的時候有更大的發揮空間,不失爲自省吾身的一種途徑