国产在视频线精品视频www666 ,亚洲国产精品综合久久久,亚洲国产精品精华素

上一篇《萬字干貨！可能是最全面的UI 設計師文件命名規范（一）》我們討論了 UI設計中文件命名的規范和要點，這一部分我們要討論的是關于切圖的命名、圖層命名、版本管理的問題。

一、切圖的部分

切圖是什么，很多新人可能還是比較懵懂。簡單講解，任何 UI 類的設計圖，要通過代碼還原成軟件界面時，沒辦法通過代碼寫出來的圖形，就需要設計師導出對應的圖形文件，給代碼做補充。

比如你現在用手機看這篇文章所在的瀏覽器或 APP，上方任何圖標都要通過導出的切圖顯示。

而一個完整的應用要導出的切圖是有很多種類型的。從圖形本身的含義或者是文件的格式。首先說圖形的類型，包含有背景圖、插畫素材、動畫素材、序列幀、圖標、LOGO 等等。

所以了解怎么命名之前，我們先要知道切圖的基本屬性和規則。

1. 切圖分類

圖形種類不少，而且切圖的數量可能比較龐大，所以大家一定要先認同一個觀點，只依靠命名的方式就能解決所有檢索問題的可能性幾乎為零。我們還是要依靠文件夾的層級劃分進行協助。

比如數量最多的圖標、序列幀，勢必要單獨為它們創建一個文件夾，不能混合到一個目錄中。如果有其它某種類型的圖形數量也較多，那么都應該先為它們創建一個獨立的文件夾。

例如我以前某項目中的切圖文件夾劃分是這樣的：

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

而最需要我們重點講解的就是圖標部分，因為這里涉及到的下級分類最多也最復雜。比如我們看下面的這個案例：

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

從右上角到中間的分類底部的導航，出現了好幾種不同的圖標類型。這是我們在設計一套 APP 時經常會發生的情況，即一套圖標規格沒有辦法滿足我們的視覺場景需要。于是，這套項目就出現了多套圖標的規格。

再看看下面支付寶服務類型界面，圖標數量多，如「搜索」、「設置」這類功能圖標有非常大的差別，把它們放到一個文件夾下面明顯是不合適的。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

所以文件的劃分上，就要清晰。如果是以尺寸劃分的，那么就用尺寸來命名文件夾，如果是類型的，那就按類型劃分。比如下面的兩種分類：

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

這些都比較好理解，但是，在所有細節從屬上，還有一個優先級更高的問題，就是我們切圖面向的手機系統。如果使用了兩個平臺獨立的設計，或是針對平臺導出矢量格式文件時，那么在最頂層就應該劃分出 iOS 和 Android 兩個文件夾，把文件分開導出，便于不同的前端工程師檢索。

這里我們集中在只使用一套設計，并且只導出 PNG 的狀態，不可能避免的要面對分辨率倍數的問題，即 @1x、@2x、@3x 的文件名后綴。我的結論就是不建議大家再為它們創建獨立的文件夾。

iOS 開發中，是直接選取同一個文件的3種分辨率，拖進 Xcode 中即可，那么分文件夾就要多次跳轉非常影響效率，如下圖所示。而 Android 開發中，雖然程序目錄會劃分出 hdpi、xhdpi、xxhpi 等文件夾，但這個操作不需要設計師來做，程序員會自己復制出三種分辨率然后改名再置入開發的項目文件夾中。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

根據以上的說明，完成切圖的分類，那么就可以為我們后續的具體命名提供基礎環境了。

2. 切圖命名

前面之所以鋪墊這么多現在才提分類，就是因為設計師導出的切圖命名有個最重要的標準——說人話。

網上最常見完整的切圖命名模式大致是這樣的：模塊_頁面_下級頁面_類型_狀態，而且會給出一堆英語的常用單詞供大家使用，那么最后的效果一般是這樣的：

Community_PostList_ DiscussPage_ShareIcon_Defult@1x.png

相信大家已經發現問題了，這種命名實在太長了。不止是層級太多，且英文的字數難以控制。雖然很多時候有一些廣泛應用的元素如導航、標題、背景之類的都有簡寫 (Nav、Tit、Bg)，但至少會有一半的詞匯你會發現它們是沒有簡寫方式的。

而且，英語不是我們的母語，大多數人英語好點也就4、6級水平。如果一個抽象、不常見的詞語，如「拼團」、「發紅包」、「種草」、「拔草」，確定你們詞典查的英語詞組是合理的嗎，這些東西簡寫就更看不懂。

再者，開發命名之所以使用英語，是因為在代碼里不能使用中文，如果直接用拼音的也太不敬業了。我們的標注是沒有必要給自己框定這樣的限制的，或者強行認為只有標注英文看起來才專業。強行英文的結果就是導致你自己以后看不懂，別人也看不懂。

有的人可能還會講，命名就是要根據開發的習慣來。這里再解釋一件事，就是除非切圖命名這個規范是經團隊商議，由開發整理給你的，不然不要企圖認為自己的英文命名具有普適性。

多數開發人員有自己命名的習慣，你的習慣和他的不可能完全匹配上，所以正常項目中程序員會根據他們自己或開發團隊的習慣命名，那就有另一套體系，我們的命名只是為了讓他們能快速找到指定的文件而已。

所以，前面的文件夾分類就是幫助我們分割不同類型的圖標，讓我們的命名可以更簡潔精準，邏輯更連貫，降低查找圖標所需要的檢索成本。這時在每個文件夾中，切圖的命名就可以只用3級以內搞定。即：

模塊_名稱_狀態

在真實環境下，使用的名稱基本就是：

設置_錢包_高亮@1x.png
動態_評論_默認@1x.png
登錄按鈕_點擊@2x.png

緊跟交流中使用的習慣來制定，這樣的命名才是簡單易懂易用。只是純形式化又復雜的命名規范，只會倒逼程序員通過放大切圖縮略圖來查找指定的圖形。

二、圖層的部分

圖層命名放到切圖后面來說，就是因為我們對圖層的命名首先要根據切圖的需要制定，養成保證導出的時候不需要對切圖文件有額外的命名修改，圖層命名直接可用。

雖然大家都推崇在設計文件中命名要細致，恨不得每個圖層都寫上清楚的圖層命名，但我要在這邊給出不同的意見。

1. PS的圖層命名

先講使用 PS ，命名是非常的。原因和 PS 的操作邏輯有非常大的關系，難以用鼠標直接在畫布中選中指定的內容。比如下圖這種比較常見的 PS合成場景。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

這種場景起碼有幾百個圖層組合而成，而這么多圖層中，還有大量的光影效果層覆蓋在手表上方。如果我要用鼠標直接在畫布中選定手表，那基本只會選擇到手表上方的高光層，還不清楚是哪層高光。所以，選中和調整 PS 圖層內容都要直接從圖層列表中查找。

而這種情況不把圖層命名清楚，那源文件只會是大型車禍現場。隨著圖層堆疊的數量增加，到后面你每做一個改動都會非常艱難。刪除無效圖層、修改前后關系、對某個部分的所有圖層進行調色處理……

所以在 PS 中命名多細致都不過分，因為這樣自己才能看的懂，別人才明白怎么修改你的源文件。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

2. Sketch / Adobe XD 圖層

但是，在現在新的 UI設計工具中，環境就發生了變化。需要我們進行細致命名的絕對條件已經不存在了。

UI 的設計沒有那么多不可見并堆疊的圖層，按住 Ctrl 或 Command鍵，你幾乎可以選中任何看的見的圖層，這時候對圖層列表的依賴也就遠遠沒有 PS 那么深。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

而且，一個 UI 項目的頁面和零碎的元素實在是太多了，如果真以細致到每個圖層都不會出現默認新建圖層字樣的地步，需要耗費極其龐大的精力去維護，而這個維護的結果可以增加的團隊效率并不顯著。

因為無論是你自己還是別人，修改文件的時候直接用鼠標去選中對應圖層就可以了，你命不命名對操作都沒有太多直接的影響。當然，我們還要有一個好的習慣，就是不要依賴隱藏的圖層，盡量使用一個新的畫布來表現不同的狀態。

基于這樣的性質，在 Sketch 或 XD 的文件中，只建議大家做出適當的命名操作，而不用太糾結于形式的細節，要把每個圖層都想命名的無用強迫癥，應用在對整個項目文件的管理和思考上。

第一，我們要能在畫板根目錄上，編組所有層級最高的模塊/組件，命名這部分的內容。下級中相對重要的模塊文件夾，也可以適當增加命名。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

第二，盡可能的將類似圖標、LOGO這些必然要導出的圖形，制作成 Symbol，并做好清晰的命名。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

第三，Sketch 中如果將一個完整的組件做成了 Symbol，那么要對其中文字圖層的命名做出清晰的排序和命名，這樣才能正常更改其中的內容。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

當然，圖層和命名和前面關于切圖的命名有一樣的要求，就是——說人話。圖層名可以顯示的字符比文件夾列表模式可以顯示得少得多，很多喜歡用英文命名的源文件，經常圖層名長到只顯示了一半就「…」，這樣的命名更沒有意義。

三、版本的管理

最后，就是關于版本管理的問題了，網上有層出不窮的關于怎么管理版本的方法，這里奉勸各位，希望借助外力和工具的版本管理方式，都是不切實際的。

無論是 SVN、GIT 的技術類管理方案，還是使用堅果云、Folio之類的第三方工具，會將本來不是太復雜的問題高度復雜化。這是因為造成我們文件版本變更迭代的事件太多了，使用這些方法不僅要大量精力維護，而且其中會有很多不可控的因素產生，造成混亂。

在我過去的項目經驗里，只推薦一種關于版本管理的方式，那就還是文件夾和命名，簡單的才是管理復雜最有效的方法。

即每次遇到設計文件、文檔需要更新替換，或是大改動（不是只加新的內容進去），那么就在同級目錄中，創建一個版本回收文件夾，復制一份當前的文件進去，再開始修改。

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

每個復制進回收站的文件，命名都要做下修改，方便后面可能的查找。通常命名的格式為——日期_版本簡單說明_，效果如下：

萬字干貨！可能是最全面的UI 設計師文件命名規范（二）

這樣不僅自己操作起來方便，而且其他人也可以很容易的訪問查找你的指定歷史版本。得益于目前 UI 文件體積的精簡，一個 Sketch 文件通常幾十 MB 就能搞定，所以記錄很多版本也無所謂。當然，如果項目出現比較大型的 PSD 或者視頻文件，那么對于版本的管理就盡可能的精簡而不是多多益善，否則會在共享和傳輸上造成極大的壓力。

而除了具體到某個文件的版本管理以外，還要考慮一個更高層級的管理，即項目版本。相信很多人有這樣的經歷，在開始后面的版本時都創建新的文件夾和設計文件，于是在幾個版本過后要反復在幾個項目之間切換查找頁面。

所以，我的方式是設計第一個版本是 v1.0，那么在開始 v2.0 版本時，直接復制一份原版本的文件夾出來。這樣，不僅保留完整的 v1.0 所有項目文件，文件夾層級可以保留下來。

復制完成后，只要再將除了界面設計源文件以外的其它文檔、切圖等文件全部刪除即可。保留設計文件，目的就是要保持最新版本設計文件的集中和唯一性。所有和項目相關的設計文件都集中在一個目錄下，才有利于我們的更新和協作。

要說一個題外話，在我過去的項目中，非常在意設計文件唯一性的標準。當一個產品團隊有幾個設計師，程序員直接查看源文件的標注，如果源文件不具備唯一性，項目調整中每個人電腦上都存了幾個版本，且各自添加了新的內容進去，不能直接覆蓋合并，最后只能演變成一場開發災難。