凹凸技術揭祕 · Deco 智能代碼 · 開啓產研效率革命

做者：凹凸曼

一、背景介紹

近幾年中臺的興起，團隊圍繞業務中臺化這個場景，將咱們已有的諸多能力進行解構、重組、積木化，但願能將拆解後的積木進行體系化地串聯，從而達到降本增效的目的。

對於電商平臺來講，每一年都須要面臨大量的大促活動頁面需求，對於如何提升頁面產出效率，你們都不約而同採用「頁面可視化搭建」解決方案。對應的，咱們也構建了「羚瓏可視化頁面搭建平臺」。但近兩年大促活動定製化需求井噴，平臺有限的組件模塊已沒法知足產品運營需求，前端工程師也沒法再用「複用」的思想簡單地解決問題。當業務發展到必定程度，有限的人力以及冗長的開發流程更是沒法知足蓬勃發展的業務需求。

咱們須要「求變」，傳統的人力密集型研發沒法解決的問題，是否能用智能化的思想來解決呢？順着這個方向，咱們把目標瞄準了「前端智能化」，但願藉助 AI 和機器學習的能力拓展前端能力圈，打通設計與研發的工做流程，實現規模化生產。

二、項目介紹

Deco 智能代碼項目是團隊在「前端智能化」方向上的探索，咱們嘗試從設計稿生成代碼（DesignToCode）這個切入點入手，對現有的設計到研發這一環節進行能力補全，進而提高產研效率。

在一個平常需求開發流程中，每每須要遵循固定的一套工做流程，產品提交需求 PRD，交互設計師根據 PRD 輸出交互稿，再由視覺設計師輸出產品視覺稿，接着再進入前端開發工做流。對於前端工程師來講，輸入源是視覺稿 + PRD，輸出結果是可上線的頁面代碼。

Deco 指望解決的是上述流程中，對於前端工程師而已相對低價值，以及可用複用思想處理的工做：

• UI 視覺稿還原，即頁面重構，編寫 HTML + CSS；
• 可複用的業務邏輯綁定；

以「設計稿生成代碼」爲切入點，咱們須要用智能化的解決方案來替代傳統的人工頁面重構（分析圖層樣式+切圖等），指望能從視覺稿原始信息中提取結構化的數據描述，進而再與智能佈局等算法結合，輸出可維護的頁面代碼。

三、技術方案

設計稿智能生成代碼能力的核心是如何生成一份「結構化的數據描述」信息，這份數據稱爲 D2C Schema。

<div style="text-align: center;" >

<img width="800" src="https://img12.360buyimg.com/img/s1920x1080_jfs/t1/161330/8/303/162801/5fed8bcaE5fc5d350/a4303b6d7968896a.jpg" />

</div>

Deco 設計稿智能生成代碼主要作了兩件事情：

1. 從視覺稿中提取「結構化的數據描述」；
2. 將「結構化的數據描述」表達成代碼；

本質上，Deco 智能代碼是經過設計工具插件從視覺稿原始信息中提取結構化的數據描述（D2C Schema），而後結合規則系統、計算機視覺、智能佈局、深度學習等技術對 D2C Schema 進行處理，轉換爲佈局合理且語義化的 D2C Schema JSON 數據，最後再借助 DSL 解析器轉換爲多端代碼。

Deco 智能代碼的核心鏈路構成了團隊「前端智能化」探索的核心技術體系，圍繞產研流程的體系化建設，結合 Cloud IDE、Taro 多端統一解決方案、設計研發資產平臺，以及羚瓏智能設計等能力，實現一個良性的產研閉環，爲總體的工程鏈路降本提效。

四、智能代碼技術分層

Deco 智能代碼核心鏈路現階段主要包含組件識別、圖層處理、佈局算法以及語義化處理四大分層，下面會圍繞這些細分的分層展開內部實現原理的剖析。

4.1 組件識別層

組件識別層負責識別設計稿圖片中的元素，包括業務組件識別、基礎組件識別以及區塊識別。
經過識別能力，輸出設計稿中與現有組件庫組件匹配的部分，進行組件推薦與複用，並輔助後續處理層處理，好比語義處理層等根據組件屬性進行語義化命名，提升生成代碼的可用性。

4.1.1 組件識別

組件識別層藉助了AI能力，使用深度學習目標檢測算法來進行識別，輸入設計稿導出的圖片，輸出圖片中的組件類別及組件位置。

<div style="text-align: center;" >

<img width="800" src="https://img12.360buyimg.com/img/s1301x1160_jfs/t1/155620/32/3513/300950/5fed8f0aE683fea36/fbd78d06ce64c921.jpg" />

</div>

4.1.2 數據集

數據集是使用深度學習處理問題的大頭，咱們聚集了羚瓏平臺活動頁數據、大促會場設計稿以及Relay平臺數據，構建了含有2w+樣本的組件識別數據集。其中，引入了自動化標註，經過對使用組件搭建的羚瓏頁面進行Dom結構解析，得到絕對精準的標註數據，減小人工標註成本。

<div style="text-align: center;" >

<img width="600" src="https://img12.360buyimg.com/img/s1194x549_jfs/t1/164331/36/210/54651/5fed8f72E5012ba90/abe749711b40888b.png" />

</div>

爲了進一步地豐富數據集，解決組件之間數量不均衡的問題，採用了自動化樣本生成方案，基於Quark 官方業務組件庫以及大促會場沉澱的 jdcop 大促原子組件庫，支持十類樣本生成。採用組件模版搭配隨機屬性的方式，由組件組成完整的頁面，並在導出的過程當中自動進行標註。

4.1.3 區塊識別

移動端設計稿大部分高寬比過長，有達到 10:1 以上的，且分佈不均，不利於目標檢測識別，由此，首先將頁面劃分爲區塊，區塊識別算法基於傳統圖像處理流程，使用邊緣檢測以及漫水填充算法得到連通區域，設置過濾閾值留下樓層大小的識別框。

<div style="text-align: center;" >

<img width="300" src="https://img12.360buyimg.com/img/s592x835_jfs/t1/156017/39/3504/40455/5fed8f71Ee3aa9831/aa987f8dee9e2bb8.png" />

</div>

區塊識別算法應用於圖層處理層自動成組，優化圖層的嵌套結構，助力於佈局算法產生更合理的組件結構樹。
此外，將未識別區域自動劃分爲新樓層。經過固定高度限制，臨近區塊組合爲一個更大粒度的區塊，達到將不等高度的設計稿劃分爲高度相差不大的幾個區域的效果，再投入目標檢測網絡進行識別。

4.2 圖層處理層

圖層處理層主要將設計稿中的圖層進行分離、合併、提取元信息，同時結合組件識別層智能成組、分類，導出第一份 Deco Schema DSL。Deco 工做流就像軟件工程裏的管道與過濾器設計模式，設計稿就是管道的入參，管道中的流就是每一階段生成的 DSL，管道的輸出是一份語義化代碼。

<div style="text-align: center;" >

<img width="900" src="https://img12.360buyimg.com/img/s1337x423_jfs/t1/152313/16/12717/101193/5fed8f72E0ba12f0d/3c306f3917d5c6f1.jpg" />

</div>

圖層處理層經過藉助組件識別層的 AI 能力，智能識別設計稿每一個區塊，將區塊內的圖層信息合成一個組，再經過區塊匹配算法自動匹配區塊與圖層，實現了設計稿的自動成組，成組數據有利於佈局算法判斷區塊的層級信息和父子關係。

<div style="text-align: center;" >

<img width="800" src="https://img12.360buyimg.com/img/s2036x1748_jfs/t1/163597/18/209/1757805/5fed9002E2bf2f58d/9873efb898135b9d.png" />

</div>

一份 Sketch 文稿是由若干圖層元信息（分爲 Document 和 Pages 等）和資源文件（主要是圖片）組成的一個壓縮文檔（文件後綴爲「.sketch」），咱們經過對圖層元信息進行加工處理後獲得一份供佈局算法服務處理的 DSL。

經過開發 Sketch 插件，使用 Sketch 提供的 API 可以幫助咱們去操做 Sketch 裏的文稿，拿到圖層信息後，對這些數據加工、篩選等處理。圖層信息的處理主要是分爲兩層：

1. 設計稿加工層：

   1. 複製出一份原樣的設計稿，在這份複製的設計稿上進行各類加工的操做；
   2. Symbol 解耦，將文稿中的 Symbols 解耦爲實際的圖層組；
   3. 篩選不可見圖層，過濾掉設計師隱藏的圖層以及空圖層組；
   4. 圖層合併，將一些特殊的圖層或圖層組合並，並轉爲圖片；
   5. 蒙層處理，蒙層下的圖片若是超出蒙層範圍須要裁剪，同時蒙層下的圖層位置和寬高信息須要重置。

2. 圖層信息處理層：

   1. 提取圖層中有用的信息，好比樣式處理、文字拆分、圖層層級等；
   2. 圖層信息的轉化，好比將圖片的 base64 位字符串數據轉爲 CDN 圖片地址；
   3. 無用圖層檢測，將一些無樣式或透明樣式的圖層去除；
   4. 圖層打平處理，將圖層數據由樹狀的層級打平爲一維的結構；
   5. 成組信息篩選，將未成組的數據經過比對位置和大小將其歸類到已成組的數據中。

下圖是對圖層信息的處理流程：

<div style="text-align: center;" >

<img width="800" src="https://img12.360buyimg.com/img/s1337x644_jfs/t1/157558/3/877/272492/5fed8f71E2ab26855/a9684747e1ffa99f.jpg" />

</div>

除了對圖層信息的基礎處理以外，咱們創建了一系列的數據導出的優化規則，用於增長佈局以及語義的合理性。好比在一些大促設計稿上，複雜背景圖的設計多是在一個圖層組下由若干個矢量圖形組成（以下圖），若是原封不動地將這些圖層導出，會給佈局帶來不少複雜度和不肯定性。

<div style="text-align: center;" >

<img width="700" src="https://img12.360buyimg.com/img/s1896x962_jfs/t1/155724/18/3463/745446/5fed98aaEcef60f1b/d457b5f93367a016.png" />

</div>

在合圖的這一流程中，針對一個圖層組下全部圖層都是矢量圖形的狀況，咱們會將它合成爲一張圖片，這樣會大大減輕佈局的困難度。最終合圖效果以下圖：

<div style="text-align: center;" >

<img width="600" src="https://img12.360buyimg.com/img/s714x132_jfs/t1/169771/39/193/42951/5fed98a9E26e6760d/531f806f0bd5fa80.png" />

</div>

固然，上面提到的這些優化規則並不能知足全部的狀況，畢竟設計師是自由的。爲了提升佈局和語義的合理性，咱們對入參的設計稿提了一些規範協議供設計師以及開發者使用。

4.3 佈局算法層

4.3.1 爲何須要佈局算法

佈局算法是創建在輸入源符合 Deco Schema 規範的數據，該數據規範能夠經過 Deco Sketch 插件對視覺高進行處理，最終會導出設計元素信息。

通過 Deco Sketch 插件導出的元素數據，都是以左上角 (0, 0) 爲座標原點座標的絕對定位爲基礎的元素信息，而且在通常狀況下（無主動編組、無AI識別等等狀況 ）元素都是扁平化的，也就是元素間沒有從屬關係。

<div style="text-align: center;" >

<img width="400" src="https://img12.360buyimg.com/img/s443x377_jfs/t1/169791/20/210/12060/5fed9913E7767b7ba/ef64707e24e847c8.png" />

</div>

在前端開發過程當中，絕對定位佈局不管是擴展性、可讀性都達不到開發要求，那麼若是不解決，就成爲 一次性代碼 。所以，須要佈局算法來提升生成代碼的擴展性、可讀性，供後續二次開發使用。

4.3.2 佈局層核心算法

佈局算法層的設計包含三大層：數據結構轉換層、佈局推導層、樣式計算層。

<div style="text-align: center;" >

<img width="600" src="https://img12.360buyimg.com/img/s609x588_jfs/t1/171357/38/226/85335/5fed9913E71b38017/739bb6e8d89ca65a.jpg" />

</div>

4.3.2.1 數據轉換層

數據結構轉換層是將 Deco Schema JSON 數據轉換爲相似 DOM 樹的結構，能夠進行節點插入、刪除、查找操做。

下面是 LayoutNode 基本數據結構：

LayoutNode {
  ...省略節點屬性
 
  ...部分節點方法
  appendChild (child) {}
  prependChild (child) {}
  insertAfter (insertedChild, afterChild) {}
  insertBefore (insertedChild, beforeChild) {}
  replaceChild (newChild, replacedChild) {}
  removeChild (child) {}
  get x () {}
  get y () {}
  get width () {}
  get height () {}
  get offsetLeft () {}
  get offsetTop () {}
  get previousSibling () {}
  get nextSibling () {}
  intersect (node) {}
  contains (node) {}
  disjoint (node) {}
  tangent (node) {}
  hitTest (node) {
  ...
}

4.3.2.2 佈局推導層

佈局推導層則是進行行列分割推導，整體上包含：空間佈局算法、投影佈局算法、背景圖佈局算法、特徵檢測佈局算法、座標推導算法、背景圖層及冗餘圖層檢測算法等等。

<div style="text-align: center;" >

<img width="500" src="https://img12.360buyimg.com/img/s801x444_jfs/t1/164092/36/228/85278/5fed9913Ee1d027c8/df7337312d3cd820.jpg" />
<span style="color: #888; font-size: 0.9em;">空間佈局算法</span>

</div>

<div style="text-align: center;" >

<img width="500" src="https://img12.360buyimg.com/img/s510x296_jfs/t1/166468/16/224/48801/5fed9913E97706fe1/d3fab3b55e7f022a.jpg" />
<span style="color: #888; font-size: 0.9em;">投影佈局算法</span>

</div>

其中特徵檢測包括標題、列表、Tab 等等一些列常見的佈局檢測。

4.3.2.3 樣式計算層

樣式計算層，是對通過佈局推導層獲得的結果進行一系列的計算，而 Deoc 樣式大部分佈局採用 Flexbox，有些特殊狀況須要使用絕對定位。在佈局推導以後，Layout 結構已經有了明晰的層級關係及相鄰關係。

基於層級關係，能夠經過座標計算得出 Flexbox 主軸、側軸；基於相鄰關係，能夠計算出相鄰之間的 margin 等等樣式。

4.4 語義化層

當設計稿數據通過佈局算法處理後咱們就能得到結構較爲良好的代碼，但此時咱們會發現因爲節點元素缺少相應的語義化類名，代碼依然不具有很好地可讀性。爲了最終能獲得能夠二次開發的代碼，咱們須要在佈局算法層以後加入語義化處理層來讓代碼擁有良好的語義性。

語義化層首要解決的問題就是如何爲元素節點加上具備語義化的類名。

爲了實現這一目標，咱們能夠先回顧一下在咱們開發的時候是如何給元素節點加上類名的，以以下的單個商品圖爲例。

<div style="text-align: center;" >

<img width="180" src="https://img12.360buyimg.com/img/s234x418_jfs/t1/151730/40/12814/49284/5fed997cEb8b7a43b/7211720bcc3dd8c5.png" />

</div>

上圖是一個商品圖的示例，咱們會經過圖片、價格、圖片下方文案等因素來判斷出這是一個商品，而後咱們就能夠給這一個區域賦予類名 goods ，而區域內的節點，好比圖片能夠賦予類名 goods_pic ，圖片下方文案能夠賦予類名 goods_tit ，價格能夠賦予類名 price ，這就是咱們爲元素節點添加類名的通常邏輯。

能夠看出，一般咱們去肯定一個區域，一個組件的語義時，咱們須要依據區域內節點的語義組合才能進行斷定，好比上面的商品組件，須要依靠內部的圖片、價格、文案等元素才能肯定語義，從而肯定類名。所以，語義化的處理方式，就是從容器元素的子節點出發，先肯定子節點的語義，而後再推斷出容器元素的語義，一層層往上進行推斷，最終推斷出整棵節點樹完整的語義。

在語義化層，咱們主要的處理對象就是通過佈局算法層處理後的 JSON Schema 數據，咱們稱之爲佈局樹，此時佈局樹已經具有了良好的結構，咱們能夠對它進行語義化推斷操做。推斷的流程就是從樹的葉子節點出發，一層層向上冒泡到枝節點，最後再冒泡到根節點。

<div style="text-align: center;" >

<img width="800" src="https://img12.360buyimg.com/img/s1734x1266_jfs/t1/155564/31/3555/279527/5fed997cE2facb891/f69f97899b664218.png" />

</div>

目前咱們進行推斷的依據主要是節點的位置、樣式、大小、兄弟節點等因素，同時會結合不一樣節點的類型，組合一些智能化手段進行輔助推斷。例如，最小葉子節點通常可能爲圖片、文本兩種類型，針對文本咱們能夠經過 NLP 的方式去分析文本的詞性、語義；針對部分圖片，咱們可使用圖片分類或識別的方式肯定圖片分類或者提取圖片上的關鍵信息進行圖片的語義斷定。

爲了肯定每一個節點的語義，咱們須要組合一系列的規則對現有的事實（樣式、位置等信息）進行推理，而同時，通過一些規則推理後又會獲得新的事實，又須要通過其餘規則推理以後才能獲得最後肯定的結果。因此，這是一個基於規則推理的推理系統，咱們能夠經過實現一個正向鏈的推理引擎，來幫助咱們進行推理決策。

<div style="text-align: center;" >

<img width="800" src="https://img12.360buyimg.com/img/s2038x886_jfs/t1/151580/21/12727/133368/5fed997cE5f52d2df/c6344c1d9ea40e82.png" />

</div>

例如，推斷上述商品組件的過程，首先咱們先找到具有價格因素的文本節點，命名爲 price ，而後咱們找到 price 附近，在樹中所處層級相近的圖片節點，而且該圖片節點符合商品圖大小的要求，這樣咱們就能基本肯定同時包含價格和符合商品圖特徵的容器爲商品容器，再根據容器中元素個數，圖片附近是否有一段文本，以及對文本的 NER 分析，咱們就能肯定這段文本是不是商品名，從而肯定其語義化類名。

在整個語義化層中，上述的斷定規則只是冰山一角，咱們結合整個電商場景，分析了大量設計稿與線上案例後總結了大量的斷定規則來幫助咱們進行合理化語義命名，同時在語義化過程當中採用 NLP 分析、圖片分類及識別等 AI 手段，咱們將在後續專門撰寫相關文章爲你們進行具體介紹。

固然，獲得節點類名只是語義化先階段初步的成果，在將來咱們將持續挖掘語義化，爲後續字段邏輯綁定等實現打下堅實基礎。

五、階段性成果

目前，在組件識別層、圖層處理層、佈局算法層和語義化層這四大核心模塊咱們已經去取得了關鍵性突破，已經能夠實現對 Sketch 設計稿進行分析，將其轉化成結構良好，具有語義化的，能夠二次開發的代碼，初步實現了設計稿到代碼還原重構的階段。

咱們已經在大量的電商大促設計稿上進行測試，佈局還原程度可達 90% 以上，而最終產出的代碼可用率能夠達到 80%，咱們已經推進在部份內部業務中嘗試進行使用。

六、將來展望

將來，在上述核心模塊完善的同時，咱們將加入線上可視化編輯器，容許開發者對生成的代碼進行人工干預調整，從而獲得更好的代碼，同時咱們也將探索加入字段綁定和邏輯綁定的功能，讓代碼能夠具有業務邏輯，讓 Deco 具有 T3 左右工程師的水平，進一步提高產研的效率。

Deco 是一粒種子，也許它此時剛剛發芽，但咱們對它期許頗多，咱們但願經過 Deco 來探索前端智能化的道路，探索 AI 與前端結合的各類可能性，更重要的是，咱們但願可以經過 Deco 開啓產研的效率革命，在各類前端工程化、平臺、方法論趨於完善的當下，探索爲業務降本增效的另外一種方式。

Deco 的將來，值得期待。

歡迎關注凹凸實驗室博客：aotu.io

或者關注凹凸實驗室公衆號（AOTULabs），不定時推送文章。