整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
evExtreme擁有高性能的HTML5 / JavaScript小部件集合，使您可以利用現代Web開發堆棧（包括React，Angular，ASP.NET Core，jQuery，Knockout等）構建交互式的Web應用程序，該套件附帶功能齊全的數據網格、交互式圖表小部件、數據編輯器等。
本文介紹自定義基于HTML的UI組件的方法。
DevExtreme Complete Subscription官方最新版免費下載試用，歷史版本下載，在線文檔和幫助文件下載-慧都網
官方建議使用UI組件的API來自定義它，與CSS類不同，API很少被更改。如果發生更改，UI組件將用警告填充瀏覽器控制臺，幫助開發人員修復代碼。
每個UI組件都有一個在UI組件的API參考部分中描述的API，例如開發人員可以通過相應的屬性指定UI組件的寬度。在下面的例子中，這個屬性是為List UI組件設置的。
jQuery
JavaScript
$(function() {
$("#listContainer").dxList({
width: 600
});
});ASP.NET MVC控件
Razor C#
@(Html.DevExtreme().List()
.Width(600)
)如果頁面包含同一個UI組件的多個實例，開發人員可以使用defaultOptions(rule) 方法在一個地方為所有這些組件指定默認配置，相同的方法允許開發者為不同的設備指定不同的默認配置。
此外，UI組件提供了可以用于更深入自定義的模板。
由于DevExtreme組件包含標準的HTML元素（<div>, <td>, <tr>等），所以開發人員可以使用CSS來自定義它們。
文檔中記錄了許多類，但是在大多數情況下，開發人員需要檢查HTML標記來確定和覆蓋應用的CSS類。
可以像往常一樣使用class屬性將類添加到標記中的UI組件元素中，如果不可能更改標記，則使用UI組件的elementAttr屬性來實現相同的目的。
注意：CSS內部結構可能在不同版本之間更改而不另行通知。考慮到這一點，我們建議在可能的情況下使用它們的API替代CSS來自定義UI組件。因為如果API發生了更改，開發人員將收到通知。
在自定義過程中，建議通過響應式設計模式查看UI組件頁面再不同設備上的外觀。
Web領域的一些基本概念。
Web（World Wide Web）叫全球廣域網，俗稱萬維網（www）。
W3C（World Wide Web Consortium）叫萬維網聯盟，是國際最著名的標準化組織，制定了web標準。
一個網頁包含了html元素 Css JavaScript，Html元素決定了網頁結構，Css進行了修飾美化，JavaScript控制了交互行為和動態效果。
web標準包含了下面三個方面：
Html不是一種編程語言，而是描述性的標記語言，主要作用是定義內容的結構。
2014年10月萬維網聯盟（W3C）完成了HTML5標準制定，是目前最新的HTM版本。
HTML5的出世，標志著web進入一個富客戶端（具有很強的交互性和體驗的客戶端程序）時代，像APP網頁，小程序都是HTML5的應用場景。
Html5新特性：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8"> <!--字符集-->
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
<meta name="Author" content="">
<meta name="Keywords" content="關鍵詞" />
<meta name="Description" content="頁面描述" />
<title>頁面標題</title>
</head>
<body>
</body>
</html>viewport用戶網頁的可視區域，一個針對移動網頁優化的頁面 viewport meta 標簽如下：
<meta name="viewport" content="width=device-width, initial-scale=1.0">head區域元素：
meta title style link script base。
body區域元素：
塊級元素：每個元素都是獨占一行
行內元素：元素在同一行水平排列
inline-block：元素可以排列在同一行顯示，并且可以設置一些塊元素屬性
通過Css：display:inline-block 改變元素。
很多元素都自帶了默認樣式，不同瀏覽器下默認樣式表現不一致，為了統一或者滿足一些需求我們需求將所有默認樣式清空，這種處理方式又稱為 Css Reset，比如：
*{
margin: 0;
padding: 0;
}另外一種方案使用normalize.css，它將不同瀏覽器下的默認樣式進行了統一，
https://github.com/necolas/normalize.css
html中的單位是像素px
絕對單位
相對單位
屬性：字體、行高、顏色、大小、背景、邊框、滾動、換行、修飾屬性（粗體、斜體、下劃線）
p{
font-size: 20px; /*字體大小*/
line-height: 30px; /*行高*/
font-family: PingFang SC; /*字體類型：顯示PingFang SC，沒有就顯示默認*/
font-style: italic ; /*italic表示斜體，normal表示不傾斜*/
font-weight: bold; /*粗體或寫（400｜500｜600）*/
font-variant: small-caps; /*小寫變大寫*/
}行高（line-height）
一般約定行高、字號都是偶數，這樣保證它們的差一定偶數除2得到整數，如下圖所示：
line-height
文本垂直居中
對于單行文本可以設置行高=盒子高度。
對于多行元素的垂直對齊，我們可以使用vertical-align: middle屬性，不過vertical-align 僅適用inline、inline-block 和 table-cell 元素。
vertical-align
vertical-align: baseline;
vertical-align: sub;
vertical-align: super;
vertical-align: text-top;
vertical-align: text-bottom;
vertical-align: middle;
vertical-align: top;
vertical-align: bottom;
/* 指定長度值 */
vertical-align: 10em;
vertical-align: 4px;
/* 使用百分比 */
vertical-align: 20%;
/* 全局值 */
vertical-align: inherit;
vertical-align: initial;
vertical-align: revert;
vertical-align: unset;內容溢出處理
filter:gray()理解優先級很重要，有助于我們排查一些問題。瀏覽器將優先級分為兩部分：HTML的行內樣式和選擇器的樣式。
行內樣式
行內樣式是直接作用在元素，它的優先級高于選擇器樣式，使用！important可以提高樣式表的優先級。
<div style="font-size:16px">
</div>選擇器樣式
<style type="text/css">
p{
font-size: 16px;
}
</style>
<link rel="stylesheet" href="style/app.css">優先級規則如下：
優先級
我們通過下圖這種標記方式，就可以判斷出選擇器的優先級。
優先級
兩條經驗法則
由多個基礎選擇器組合成的復雜選擇器。
多個基礎選擇器連起來（中間沒有空格）組成一個復合選擇器（如：ul.nav）。復合選擇器選中的元素將匹配其全部基礎選擇器，.box.nav 可以選中 class="box nav" ，但是不能選中 class="box"。
用于選中某種特定狀態的元素，優先級（0，1，0）。
:nth-child(an+b)
更多參考：https://developer.mozilla.org/zh-CN/docs/Web/CSS
偽元素選擇器可以向HTML標記中未定義的地方插入內容，優先級（0，0，1）。
屬性選擇器用于根據HTML屬性進行匹配元素，優先級（0，1，0）。
本文要點回顧，歡迎留言交流。
賣UI一致性項目是外賣UI設計團隊與研發團隊共建的項目，目的是改善用戶端體驗的一致性，提升多技術方案間組件的通用性和復用率，降低整體視覺改版帶來的研發成本。外賣技術團隊通過在實踐中不斷總結經驗，開發了一套完整的UI一致性解決方案，目前已經取得了一些成果，本文系實踐經驗分享。
1.1 行業現狀與問題
很多技術同學都知道，移動端往往比較側重業務開發，這會導致人員規模不斷擴大，項目復雜度也會持續增長。而為了滿足業務的快速上線，很難去落實統一的設計規范，在開發過程中由于UI缺乏標準導致的問題不斷凸顯，具體體現在以下4個層面：
1.2 外賣移動端UI一致性情況
近來年，美團外賣業務開始由發展期走入成熟期，這更要求對細分場景的快速迭代。目前，外賣平臺承載了餐飲、商超、閃購、跑腿、藥品等多個業務品類，用戶入口則覆蓋了美團App外賣頻道、外賣App、大眾點評外賣頻道等多個獨立應用。由于前期側重需求的快速上線，設計層面缺乏標準化的規范約束，UI設計風格不統一，也存在多次開發的情況，目前的維護成本較高，在開發過程中逐漸暴露出一些問題，主要體現在以下三個層面。
指標一：移動端UI問題統計
在Ones（美團內部研發需求管理工具）中，單個版本的UI適配問題占比超過總Bug數的11.82%，亟待優化；交互適配問題在絕大多數版本中均有出現，一定程度上反映了其發生的普遍性。
指標二：需求承接率數據統計
用戶側UI需求吞吐率達18.3%，目前用戶側UI需求吞吐率較低，亟待解決。
指標三：需求入版情況統計
目前各版本UI同學都會提出一定數量的視覺優化需求，但實際入版量僅為三分之一左右，未上線的原因均為RD開發時間不足。
從長遠角度來看，隨著固有業務滲透率的不斷飽和，未來一段時間內，美團外賣還有開拓新業務、進入新市場的需求，如國際化App、閃購App等，需要移動端能夠高效地組建新業務App。在此背景下，移動端具備快速調整適應的UI展現能力是重中之重。為了達到上述目標，需要PM/UI/RD共同維護一套設計規范，在產品上統一風格，在源頭上做到統一設計，并在代碼中統一進行實現。
1.3 UI一致性項目
基于上述開發工作中的切實痛點，以及未來可預見的移動端能力需求，迫切需要一套統一的UI設計規范，以此沉淀設計風格，建立統一的UI設計標準。
UI一致性項目自2019年5月份被提出，是外賣UI設計團隊與研發團隊的共建項目，該項目是為了改善用戶端體驗一致性，提升多技術方案間組件的通用性和復用率，降低整體視覺改版的研發成本。通過抽離成熟的業務場景，建立可提供高質量、可擴展、可統一配置的基于Android/iOS/MRN的組件代碼庫，使之具備支持多業務高層次的代碼復用能力，進而提高UI業務中臺能力，使項目保持高度一致性。
為了幫助團隊提升產研效率，外賣技術成立了袋鼠UI共建項目組，將門戶建設、工具鏈建設以及組件建設統一管理統一規劃，并將工具鏈的品牌確定為“積木”，此前我們已經寫過兩篇文章《積木Sketch Plugin：設計同學的貼心搭檔》、《積木Sketch插件進階開發指南》介紹過積木相關的內容，本文主要介紹UI一致性。
UI一致性是絕大部分研發團隊面臨的共性問題，大家對落地設計規范，提高UI中臺能力，提升產研效率具有強烈的訴求。通過UI一致性的建設，不僅可以在品牌上實現體驗升級，更可以全面提高產研效率，為業務的快速迭代提供有力支持和有效保障。
統一的品牌符號、品牌特征，有助于加深產品在用戶心目中的印象。統一的用戶界面和交互形式，能幫助用戶加深對產品的熟悉感和信任感。而一個好的設計語言可以在體驗上為產品加分，也能夠更好的創造一致性體驗。
為了幫助更多的業務部門定制符合一致性原則的專屬設計風格，外賣技術部在實踐中不斷總結經驗，開發了一套通用的UI一致性解決方案。該方案通過UI一致性工具鏈落地項目建設，并打造一整套的閉環UI開發流程，目前已經取得了一定的成果，以下系具體方案的介紹。
2.1 方案全景
外賣UI一致性套件由積木工具鏈、代碼組件庫、定制化設計云協作平臺以及文檔化說明（官網）四部分組成。
外賣UI一致性解決方案
2.2 接入指南
UI一致性協作流程閉環
2.3 方案落地
雖然UI一致性在落地上會增加開發同學不少的工作量，推進一致性建設也是一個艱難的工作，由于成本較高，且無法量化評估收益，很多團隊最終未達到預期效果，但一旦有效運作起來后，團隊將獲得豐厚的回報。UI一致性的建設需要設計者對現有狀態有足夠的認識，對業務有充分理解，以及優秀的設計能力，同時還要不斷地進行實踐和優化。為了保證一致性項目的成功落地，避免“半途而廢”，我們制定了一系列的推進措施：
2.4 一致性成果
經過一段時間的UI一致性建設，在資源一致性方面，外賣App團隊已經完成了近百個Iconfont的替換工作，有效減小了安裝包的體積。在組件代碼庫建設方面，完成組件替換三十多處，中等業務需求平均節約3pd人力；在工具鏈方面，根據UI/UE提供的數據，對于強依賴設計資源的需求，在使用積木Sketch插件后，提效能夠達到30%以上，對于UI資源依賴不強的流程需求，平均提效可以達到50%以上。
細化來看，UI一致性整體方案主要分為兩個部分，一個是設計體系建設，另一個則是工具鏈建設。設計體系建設是基礎，主要是設計師沉淀設計風格，建立統一的UI設計標準的工作，而工具鏈建設則是支撐，是開發人員通過開發一系列的工具將開發過程閉環，實現設計體系落地。
3.1 外賣DPL
DPL（Design Pattern Library）是一份面向UED設計人員的文檔化說明，描述了設計模式庫的規范以及應用場景等，外賣DPL主要包括組件搭建規范以及資源一致性兩部分。DPL的背面是技術實現，一般體現在Android/iOS/RN代碼框架中，比如阿里的FusionDesign庫、騰訊的QMUI庫等，這些封裝好的代碼組件面向程序開發人員。在未建立DPL模型之前，開發同學拿到設計稿進行視覺還原后，需要修改多次，才能最終通過設計師的驗證，極大影響了開發效率，還降低了需求吞吐率。
未建立外賣DPL模型之前開發流程
而通過DPL實現設計-開發流程的閉環，UI同學由于設計規范的標準化，可使出稿效率、走查效率顯著提升，重復組件甚至無需走查；對于RD同學來說，組件庫中的組件在配置正確的情況下，由于已經經過了歷史版本的檢驗，適配問題出現較少，無需重復進行視覺的修正；對于設計團隊來說，優秀的設計體系具有包容性且充滿生命力，好的設計模式庫能夠幫助實現規范化，從而減輕界面開發的工作量，提高一致性；而對于設計師來說，建立DPL有助于減少誤用、濫用以及無效的創新。
3.2 組件搭建
在長期的版本迭代中，隨著功能的不斷增加以及UI的持續改版，新舊樣式混雜，維護極為困難。設計師通過將頁面走查結果歸納梳理，制定設計規范，從而選取復用性高的組件進行組件庫搭建。通過搭建組件庫可以進行規范控制，避免控件的隨意組合，減少頁面之間的差異；組件庫中組件滿足業務特色，同時可以應對不斷變化的環境，具有云端動態調整能力，可以在規范更新時進行統一調整。
在不影響需求實現以及設計效果的前提下，只有在方案設計中盡可能使用組件，提升組件設計稿中的覆蓋度，才可能真正通過組件庫來提效。而除了在新的需求中使用組件，還需要將已有頁面內容盡量替換成組件，才能避免頁面升級時的重復修改問題，真正提高產研效率。在進行組件庫建設時要注意以下幾點。
選擇合適粒度
組件的粒度選擇曾是困擾我們很久的一個問題，雖然有構建設計系統的核心理論——原子設計理論為指導，即按照“原子、分子、組織、模板、頁面”五個層面進行頁面設計。這一理論對于從零開發新應用沒有任何問題，但進行一致性改造的App，往往已經暴露出很多設計問題，已經存在數百個成熟的線上頁面，改造存在非常大的困難，必須根據具體業務選擇合適粒度。在進行組件制作前，項目同學對外賣的近百個頁面進行了梳理，對使用到的組件進行了分類，并根據組件的使用頻率進行排序，制定了逐步替換計劃。從而避免了組件庫做的很全、花費了很多的人力，但實際很多組件都用不上，或者開發的組件過少，覆蓋場景不足等問題。
我們將走查結果與設計師反復交流，發現復用性較高的組件大體可以分為兩類：第一類“基礎控件”，也就是類似于標簽、按鈕、開關等具備基礎功能的元素，對應原子理論中的原子；第二類“業務組件”，類似于商品卡片等，是由“基礎控件”組成（比如商品卡片由“標簽控件”與“圖片控件”組成），同時“業務組件”還能相互組合，成為更高階的“復雜組件”，類似于原子理論中的分子。“業務組件”的組合又是千變萬化的，不同樣式的業務組件可以組成類似“商家列表”、“菜品列表”等“模板”，而“模板”與“基本控件”組合在一起，就成為了“頁面”。
外賣DPL模型建立
具備拓展性
組件必須具備一定的可配置屬性才能提升適用場景。可配置屬性體現在三個方面：組件支持局部元素展示隱藏，例如商品卡片的標題、說明、價格可根據接口數據控制展示邏輯；組件支持多種樣式，例如商品卡片的左圖右文排列、上圖下文排列；組件支持業務方配置主題，如調整高亮色、調整對齊方式等。
組件應具有拓展性
支持統一管理
組件管理功能對外賣UI一致性起著至關重要的作用，這主要體現在兩方面：首先是設計風格沉淀，目前袋鼠UI已經形成了自己的獨特風格，外賣設計團隊根據設計規范，對符合UI一致性外賣業務場景的組件不斷進行抽象及建設，沉淀出越來越多的通用業務組件，這些組件需要及時擴充到Library中，供團隊成員使用；另外一個作用則是保持團隊使用的均為最新組件。由于各種原因，組件的設計元素（色彩、字體、圓角等屬性）可能會發生變更，需要及時提醒團隊成員更新組件，從而保持所有頁面的一致性。
3.3 資源一致性
UI設計語言與自身業務關聯性很強，美團很多業務包括外賣、酒旅、團購等都有一套自己的設計系統。“通用”意味著無法滿足具有業務特色的需求，不同業務的組件、色彩系統、動效、字體樣式等千差萬別，其中任意一環的缺失都會導致一致性被破壞。
設計語言并不是一個抽象的概念，大家提到美團就想起美團黃，想到袋鼠，想到菜品卡片列表，想到騎著摩托車穿著印有“美團外賣”衣服的騎手，通過設計語言可以傳達品牌主張和設計理念。目前，袋鼠UI已經形成了一套屬于自己的獨特風格，對于一致性元素處理有了一套自己的標準，對于產品的設計者而言，必須將這種風格化延續，才能使我們整個項目具備高度的一致性，才能保持“袋鼠特色“，保證吸引力。
3.3.1 圖片
建立插畫庫
插圖作為一種視覺語言，是品牌識別度的關鍵核心元素，與單純的文案信息不同，圖形化在直觀描述固有信息的同時，也在塑造情感背景，使用戶更具沉浸感和共情性。插畫在提升產品用戶體驗的同時完成商業目標，在表達效果及生產效率上有獨特的優勢，在追求效率的互聯網產品中被大量地運用。
由于之前產品中的插圖未經系統整合，而插畫師的個人風格明顯，不同的設計師在圖形化的工作協同中，風格很難復現，而單純由一名設計師去完成整體業務的插畫建設工作也存在一定風險。不同設計師之前畫過的元素無法互通，造成很多元素重復設計、風格不統一，缺乏系統性地創作和整理，無法最大化地提升生產效率，并且影響產品的品質感。所以插圖體系在保持品牌一致性、提升工作效率以及規避風險上尤為重要。
插畫規范示例
使用Iconfont
Iconfont可譯為圖標字體，顧名思義就是用字體文件取代圖片文件來展示圖標、特殊字體等元素的一種方法。簡單來說，Iconfont就是把多個圖標文件打包為ttf字體文件，注冊到系統中，App可以像使用字體一樣使用圖標。其原理可以簡單理解為通過ttf字體文件維護一個Unicode碼與圖形的映射關系。當使用Iconfont為項目助力的時候，配置多個圖標不再需要去下載數個PNG文件，僅需要維護一套ttf字體文件即可。
Iconfont不僅具有矢量性、可自由變化大小的特點，而且支持任意改變顏色。從項目角度來看，由于無需針對不同手機分辨率內置多張圖片，可以一定程度減小包體積，而且方便UI同學對圖標進行統一管理，為無用icon和相似icon檢測做基礎。
使用iconfont替換項目中的圖片
歸檔圖片文件
當App發展到一定階段，必然面臨著包體積會越來越大，無用圖片與相似圖片也會越來越多的問題。同時，由于開拓新業務而不斷涌現的新場景，又不可避免地新增大量的圖片。總結來看，圖片文件在一致性項目中需要解決兩個問題，即存量圖片的處理以及新增圖片的管理。
對于存量圖片，必須判斷其合理性，項目中存在大量相似圖片，這些圖片可能僅是padding不同，或者顏色尺寸存在微小差異，可以通過腳本掃描相似圖片，根據圖片的特征Hash判斷圖片的相似度，相似度高的圖片根據UI建議，保留一張即可。那如何防止新增圖片“重蹈覆轍”呢？通過建立圖片管理后臺，將圖片按場景分類，標準圖片需從組件代碼庫中選取，新增圖片執行PR策略，需相關負責人審核，可有效防止相似圖片的堆積問題。
一致性項目實施前項目中的相似圖片
3.3.2 動效
動效是指那些那些能夠為產品賦予生機的動態界面元素及視覺效果，這些交互效果通常與特定的響應行為相關，甚至包括那些與交互行為沒有直接關聯的臨時狀態。精細而恰當的動畫效果可以傳達狀態，增強用戶對于直接操縱的感知，通過視覺化的方式向用戶呈現操作結果。
隨著外賣業務的不斷增加，動效的使用比重在不斷增加，重要性日漸凸顯，也是增強用戶體驗與競品拉開差距的重要因素，因此，統一規范的使用動效尤為重要。通過動效庫建設，UI層面可以承載品牌、傳遞情感，加深用戶對App的印象，讓用戶放松、愉悅；RD層面同一組件可在多場景直接復用，還降低了研發成本。
動效
3.3.3 顏色
顏色可以起到傳遞品牌信息、區分信息的所屬關系、標明控件的選中狀態以及對內容的信息進行分層級展示等功能。重要的信息需要在頁面中被突出展示。系統級色彩體系主要定義了外賣的主要顏色、文字顏色、輔助顏色以及標準漸變色，顏色在一定時期內不再支持新增。通過將標準色板內置于積木Sketch插件中，限制UI繪制設計稿時的使用范圍，而RD同學僅可通過代碼組件庫中選取顏色，保證色值的準確性，也便于進行主題定制。
定義顏色使用場景
3.3.4 字體
字體是體系化界面設計中最基本的構成之一。用戶通過文本來理解內容和完成工作，科學的字體系統將大大提升用戶的閱讀體驗及工作效率。設計師在字體設計過程中需要關注非常多的方面，比如字體family、字距、行高、段落等等。如何讓文字看起來更自然，是設計師團隊一直探尋的答案，UI同學根據文字的層級關系，規定了Headline、Subtitle、Body、Button以及Caption的文字使用規范，根據設計稿中文字的位置，就可確定文字的具體樣式。
定義字體使用規范
要想保持UI一致性，就不能打破規則。外賣UI一致性套件由積木工具鏈、代碼組件庫、定制化設計云協作平臺以及官網四部分組成，通過將這四部分連接起來，形成一個閉環，把整個工作流限制在標準操作以內。
4.1 積木Sketch插件
在之前的文章中，我們已經對積木插件進行了詳細介紹，這里只作簡要概述，介紹其在一致性項目中發揮的作用。從設計階段顏色的選擇、字體的規范、控件的樣式，到RD開發階段代碼的統一管理、API的制定、多端的實現方式都必須遵守一套規則，通過積木Sketch插件落地設計規范，可以保證設計元素均從既定設計標準中獲取，產出符合業務設計語言的設計稿，而各平臺UI代碼庫中也有對應實現，從而使積木插件成為UI一致性的抓手。
積木Sketch Plugin平臺化示意
4.1.1 插件功能
積木Sketch插件經過一段時間的建設，目前已具備Iconfont、標準色板、組件庫、數據填充、文字模板等功能。通過Iconfont可以從公司圖標庫中拉取設計團隊上傳的SVG圖標，并直接應用于設計稿；標準色板可以限定設計師的顏色使用范圍，確保設計稿中的顏色均符合設計規范；組件庫中包含從外賣業務抽離的基本控件與通用組件，具有可復用和標準化的特點，并與不同開發語言組件庫中的代碼一一對應；數據填充庫可以使設計師采用真實數據進行填充，使設計稿更貼近線上環境；文字模板中內置了字體樣式的使用規范，根據設計稿中文字的位置，點擊文字圖層即可直接應用。
積木Sketch Plugin功能演示
4.1.2 物料市場
通過Sketch管理后臺，設計師可以將配色規范、文字規范、話術、Iconfont、組件庫上傳至云端并與整個設計團隊中成員共享，并可實現設計資產的版本管理。通過將Sketch Library存儲在后臺物料市場，設計師可以與團隊成員共享組件（Symbol），Library可以實現“一處更改，處處生效”，即使是關聯了遠程組件庫歷史的設計稿檢測到更新時，也會收到Sketch通知，確保工作中使用的是最新組件。
積木Sketch Plugin 物料管理后臺
4.2 代碼模型建設
為了滿足中小企業的需求，越來越多的開源組件庫誕生，但開源代表著“通用”，無法滿足業務特色的需求，于是很多企業也開始做起了自己的組件庫。通過建立代碼組件庫，能幫助開發同學快速搭建App頁面，減少設計與開發溝通成本，統一體驗規范等。
代碼組件庫模型
4.2.1 代碼庫功能
提高項目可維護性
由于組件庫中的組件職責單一，降低了系統的耦合度，開發人員可以很容易地了解該組件提供的能力。組件可以自由替換、組合為高階組件，在進行組件更新時僅需修改一處。每個項目成員維護一定數量的組件，讓團隊中每個人都能發揮所長，可以最大化團隊的開發效率。
實現文檔化
組件接口有統一的規范，降低新人的上手難度，新成員只需要理解接口和職責即可開發組件代碼，由于代碼的影響范圍僅限于組件內部，對項目的風險控制也非常有幫助。通過對組件統一管理，實現代碼的積累沉淀與有效復用，全面提升了新業務的需求開發效率。
便于單元測試
由于組件職責單一而清晰，對外僅暴露接口，概念上可以把組件當成一個函數，輸入對應著輸出，這讓自動化測試變得更加簡單。
實現無障礙等定制化功能
無障礙功能可以改善殘障人士的用戶體驗，組件庫中的組件資源高內聚，完全由自身控制加載，不與全局或其他組件產生影響。組件的加載、渲染路徑清晰可控，對于組件功能定制，實現類似于無障礙等功能較為方便。
4.2.2 方案設計
統一配置文件
前文也提到，外賣業務入口覆蓋外賣獨立App、美團外賣頻道以及大眾點評外賣頻道等，外賣組件需要在不同的移動端上適配宿主App的UI風格及交互體驗，這就需要組件庫支持主題配置功能。由于主題涉及Android/iOS/MRN多端，需要一套通用的主題配置文件。經過了各端開發同學與設計師的多輪討論，最終確定了包含主題顏色、文字外觀、組件風格等內容的主題描述文件格式。配置文件通過下發，就可以實現全局替換主題的功能。
{
// 主題顏色
"rooBrandColors": {
"rooBrandPrimary": "#FFCC33"
},
// 文本外觀
"rooTextAppearance": {
"rooTextAppearanceHeadline1": {
"fontFamily": "sans-serif-medium", // 字體
"textStyle": "normal", // 風格（normal/bold/italic）
"textSize": 44, // 字號
}
},
// 組件風格
"rooStyle":{
"rooButtonStyle": {
"textAppearance": "?attr/rooTextAppearanceButton",
"backgroundColor": "?attr/rooBrandPrimary",
"cornerRadius": 0,
}
}搭建全平臺組件庫
目前，市面上耳熟能詳的組件庫包括阿里的Antd Desigin、Fusion Design以及美團的Roo Design等，基本都是服務于Web開發的組件庫，通過這些組件庫可以快速搭建一些中后臺系統。
為什么沒有知名的Native開源組件庫呢？因為每個應用的主題、風格以及交互體驗都是不同的，而這些不同恰恰是傳達品牌主張和設計理念的靈魂，因此必須結合業務，針對Android/iOS/MRN三端進行組件庫開發。通過搭建全平臺代碼組件庫，可以保證同一個UI組件在各端表現一致，進行UI升級時降低改錯或遺漏的風險，除此之外，還能降低測試壓力，提高需求的吞吐率。
4.2.3 示例應用
我們針對Android/iOS/MRN三端代碼開發了示例工程，通過示例工程，不僅可以幫助UI同學完成組件驗收，還能幫助開發同學快速查閱可以應用的所有組件，了解其使用方式以及進行代碼調試。
組件庫demo示例
4.3 官網門戶建設
官網相當于項目的門面，一個好的門面才能吸引更多的用戶，才能更好地對項目進行推廣。官網作為設計師與開發同學溝通的媒介，需要兩者共同維護。通過官網可以幫助團隊內設計師沉淀設計風格，建立統一的UI設計規范，幫助RD同學進行組件文檔管理與查閱。
4.3.1 官網功能
當前的官網主要由四部分組成，分別是設計語言、組件庫、插畫庫以及資源下載，分別服務于UI和RD同學。
外賣平臺化官網導航欄
設計語言
UI一致性項目中采取了“原子理論”的構成原理，即從最小的元素開始定義，進而將這些元素按照規則進行組裝，拼接成組件，最后通過這些組件拼接成最終的頁面，這是一個由點到面的過程。設計語言章節主要服務于UI/UE同學，該章節通過視覺、設計模式、動效等三個子章節使得讀者能夠快速了解項目的設計規范，從而快速上手。
組件庫
組件庫是設計模式中各種元素的具體實現，在這個頁面描述了組件的使用方式。
插畫庫
插畫庫中則介紹了插畫的使用場景，插畫的繪制規范以及插畫案例展示。
資源下載
提供積木工具鏈產品下載功能。
外賣平臺化官網
4.3.2 方案設計
由于官網以純粹的圖文展示為主，且迭代頻率較快，因而選擇了當下較為普遍的文檔-網站生成系統，即只需按照一定規范將書寫的Markdown文檔放至相應目錄，前端自動解析后生成導航，并且支持多語種、圖片、文件、視頻等素材。這種方式極大地縮短了官網的開發周期，即便是沒有前端經驗的同學也能快速上手。
為了方便UI同學對官網文檔的修改，我們基于文檔網站生成系統搭建了在線編輯平臺。通過該平臺，相關人員可以直接做到在線編輯、發布，節約了UI同學與RD同學的溝通成本以及發布成本。填充期間，使用者可以實時預覽編輯的內容，修改后只需點擊保存即可立即更新到網站中。
官網支持平臺化功能，不同業務方可以創建屬于自己的文檔站點，一個好的文檔站點對于設計組的方案推廣、外部接入都大有裨益。
外賣平臺化官網錄入后臺
4.4 工具鏈的閉環
當我們信心滿滿的把UI一致性解決方案推廣到日常開發中時，除了聽到可以提升效率的褒獎外，開發同學對項目的吐槽聲也常常傳入我們的耳邊，“怎么才能知道設計稿中的哪個組件已經開發完成了？”，“查詢這個組件的使用方法好麻煩，每次都要去官網檢索”，“規范顏色、圖標的名稱是什么？怎么才能引用到？”
我們無法限制別人的選擇，所以只能讓這套體系變得更好用，如果不去優化整個流程，將其串聯起來形成閉環，后面整個項目可能都會慢慢崩塌，所以我們對項目進行了重新復盤，經過大家集思廣益，終于找到了能將工具鏈體系打通的解決方案：設計稿作為銜接RD與UI的紐帶，可以把官網與代碼倉庫打通。
我們與美團內部的印跡團隊合作開發，然后定制了一個設計云協作平臺，在給RD的設計稿中標注了哪些是代碼組件庫中已有的元素，避免了重復開發，同時關聯了官網上該組件的使用說明，RD同學在開發過程中遇到組件使用問題無需檢索，點擊即可跳轉至使用文檔。后期我們還將顏色、iconfont以及插畫庫中圖片也進行了關聯，真正做到了一致性元素的全覆蓋。
與印跡合作支持組件展示的云協作平臺
UI一致性項目原本只是外賣技術團隊提升UI/RD協作效率的一次嘗試，現在已經作為全面提升產研效率的媒介，承載了越來越多的功能。圍繞設計日常工作，提供高效的設計元素獲取方式，讓工作變得更輕松，是我們的核心目標。如何推動設計規范落地，并且輸出到各個業務系統靈活使用，是我們持續追尋的答案。探尋研發和設計更為高效的協作模式，是我們一直努力的方向。
如你所見，通過UI一致性建設可以幫助設計團隊提升設計效率、沉淀設計語言以及減少走查負擔；讓RD同學面對新項目時可以專注于業務需求，而無需把時間耗費在組件的編寫上；減少QA工作量，保證控件質量無需頻繁的回歸測試；幫助PM提高版本迭代效率及版本需求吞吐量，提供業務的快速拓展能力。當然，我們除了希望制作一流的產品，也希望可以讓大家在繁忙的工作中得以喘息。我們會繼續以設計語言為依托，以工具鏈建設為抓手持續進行UI一致性建設，不斷提高移動端UI業務中臺能力。
如果你也想參與我們的UI一致性項目建設，歡迎加入我們！
感謝曉飛、彥平、杜瑤、冰冰、云鵬對項目的大力支持。
感謝到家優秀設計師淼林、昱翰、冉冉、璟琦、雪美、田園。
感謝用戶平臺組參與UI一致性建設的開發同學王鵬、騰飛、趙炎、瀚陽等，感謝美團印跡開發團隊的支持。
感謝所有參與人的努力與堅持，為外賣DPL建立貢獻力量！
---------- END ----------
招聘信息
美團外賣長期招聘Android、iOS、FE高級/資深工程師和技術專家，歡迎加入外賣App大家庭。感興趣的同學可投遞簡歷至：tech@meituan.com（郵件主題請注明：外賣大前端）。
| 歡迎關注：美團技術團隊微信公眾號（meituantech），我們會定期推送技術干貨、技術沙龍和技術團隊招聘信息。
| 在公眾號菜單欄回復【2019年貨】、【2018年貨】、【2017年貨】、【算法】等關鍵詞，可查看美團技術團隊歷年技術文章合集。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
