![]()
Tech
導讀
在這次雙11的個性化會場我們大規模使用Deco進行研發，帶來了48%左右的效率提升，本文將爲大家揭祕Deco提效之祕。
研發效能的提升一直是我們追求的主題，從最初的工具化到工程化，工程師們盡其所能去實現更快速地書寫代碼，來應對不斷增長的業務需求，而後，小程序等各類平臺的崛起，工程師們又開始研究多端統一開發的解決方案，讓我們可以一次性寫出跨端運行的代碼，進一步提升效率。但個性化的業務依然還在爆發式增長，那我們不禁要發出疑問，我們要如何繼續進行革新，來提升我們的研發效率。
我們思考「求變」，在智能化思想愈來愈熱的當下，傳統的研發提效方式遭遇瓶頸，那我們是否能用智能化的思想來解決呢？我們思索着，既然更快地寫代碼這條路看似已經走得差不多了，那我們能否基於 AI 手段來實現代碼生成，讓我們寫更少的代碼，於是，我們探索的方向就轉向了「前端」+「智能化」，希望藉助 AI 和機器學習的能力拓展前端能力圈，打通設計與研發的工作流程，實現規模化生產。
Deco 智能代碼項目是我們團隊在「前端智能化」方向上的探索，我們嘗試從設計稿生成代碼（Design To Code）這個切入點入手，對現有的設計到研發這一環節進行能力補全，進而提升產研效率。
圖1 傳統研發流程
Deco 期望解決的是上述流程中，對於前端工程師而已相對低價值，以及可用複用思想處理的工作：
UI 視覺稿還原，即頁面重構，編寫 HTML + CSS；
可複用的業務邏輯綁定；
設計稿中已有組件的識別與替換
圖2 使用智能代碼的研發流程
以「設計稿生成代碼」爲切入點，我們探索利用智能化的解決方案來替代傳統的人工頁面重構（分析圖層樣式+切圖等），期望能從視覺稿原始信息中提取結構化的數據描述，進而再與各類智能算法結合，輸出可維護的頁面代碼。
Deco 經過 618 大促的初步驗證，隨後不斷升級打磨，在正在火熱進行的雙 11 個性化會場研發中已經廣泛投入使用，覆蓋 90% 左右的大促樓層模塊，爲業務研發帶來 48% 左右的效率提升。
圖3 雙11部分個性化會場及模塊
03
如何實現一個設計稿生成代碼方案
1、生成靜態代碼
設計稿智能生成代碼的第一步是生成靜態化的代碼，而這一步的核心是如何根據設計稿生成一份「結構化的數據描述」信息，這份數據稱爲 D2C Schema。
1、生成靜態代碼
設計稿智能生成代碼的第一步是生成靜態化的代碼，而這一步的核心是如何根據設計稿生成一份「結構化的數據描述」信息，這份數據稱爲 D2C Schema。
圖4 設計稿數據表達
Deco 設計稿智能生成靜態 代碼主要做了兩件事情：
從視覺稿中提取「結構化的數據描述」；
將「結構化的數據描述」表達成代碼；
本質上，Deco 智能代碼是通過設計工具插件從視覺稿原始信息中提取 D2C Schema，然後結合規則系統、計算機視覺、智能佈局、深度學習等技術對 D2C Schema 進行處理，轉換爲佈局合理且語義化的 D2C Schema JSON 數據，最後再借助 DSL 解析器轉換爲多端代碼。
（1）處理設計稿
一份 Sketch 文稿是由若干圖層元信息（分爲 Document 和 Pages 等）和資源文件（主要是圖片）組成的一個壓縮文檔（文件後綴爲 ".sketch"），我們需要通過對圖層元信息進行加工處理後得到一份供佈局算法服務處理的數據。
通過開發 Sketch 插件，使用 Sketch 提供的 API 來幫助我們去操作 Sketch 文稿，拿到圖層信息後，對這些數據加工、篩選等處理。圖層信息的處理主要是分爲兩層：
設計稿加工層：將設計稿中的 Symbol 解耦成實際圖層，然後再對圖層進行各類處理，如過濾不可見圖層，合併必要圖層，處理蒙層等等；
圖層信息處理層：提取圖層中有用信息，將信息進行轉換，同時去除掉無用圖層，打平圖層信息等等。
圖5 設計稿數據處理過程
除了對圖層信息的基礎處理之外，我們建立了一系列的數據導出的優化規則，用於增加布局以及語義的合理性。比如在一些大促設計稿上，複雜背景圖的設計可能是在一個圖層組下由若干個矢量圖形組成（如下圖），如果原封不動地將這些圖層導出，會給佈局帶來很多複雜度和不確定性。
圖6 設計稿
在合圖的這一流程中，針對一個圖層組下所有圖層都是矢量圖形的情況，我們會將它合成爲一張圖片，這樣會大大減輕佈局的困難度。最終合圖效果如下圖：
圖7 背景圖
當然，上面提到的這些優化規則並不能滿足所有的情況，畢竟設計師是自由的。爲了提高佈局和語義的合理性，我們對入參的設計稿提供了一些規範協議供設計師以及開發者使用。
（2）通過佈局算法還原設計稿
設計稿插件處理好的數據需要經過佈局算法處理，來獲得視覺還原度良好、佈局結構合理的代碼結構表達數據。
經過插件導出的元素數據，都是以左上角 (0, 0) 爲座標原點座標的絕對定位爲基礎的元素信息，並且在一般情況下（無主動編組、無AI識別等等情況 ）元素都是扁平化的，也就是元素間沒有從屬關係。
圖8 元素座標示意
在前端開發過程中，絕對定位佈局無論是擴展性、可讀性都達不到開發要求，那麼如果不解決，就成爲 一次性代碼 。因此，需要佈局算法來提高生成代碼的擴展性、可讀性，供後續二次開發使用。
佈局算法層的操作流程包含三大步驟：數據結構轉換、佈局推導、樣式計算。
圖9 佈局算法處理流程
數據結構轉換是將 Schema JSON 數據轉換爲類似 DOM 樹的結構，可以進行節點插入、刪除、查找操作。
在數據轉換處理之後需要進行佈局推導，在這一步進行行列分割推導，總體上包含：空間佈局算法、投影佈局算法、背景圖佈局算法、特徵檢測佈局算法、座標推導算法、背景圖層及冗餘圖層檢測算法等等。在佈局推導之後，Layout 結構已經有了明晰的層級關係及相鄰關係，我們就能獲得分割良好、成組合理，結構化的節點結構。
圖10 空間佈局算法
圖11 投影佈局算法
處理好佈局結構生成之後需要進行樣式計算，是對經過佈局推導層得到的結果進行一系列的計算，例如，基於層級關係，可以通過座標計算得出 Flexbox 主軸、側軸；基於相鄰關係，可以計算出相鄰之間的 margin 等等樣式。Deco 樣式大部分佈局採用 Flexbox，有些特殊情況需要使用絕對定位。
經過佈局算法處理之後，我們就能獲得還原性良好，結構合理的 Schema JSON 數據。
（3）生成語義化的代碼
當設計稿數據經過佈局算法處理後我們就能獲得結構較爲良好的代碼，但此時我們會發現由於節點元素缺乏相應的語義化類名，代碼依然不具備很好的可讀性。爲了最終能得到可以二次開發的代碼，我們需要在佈局算法之後加入語義化處理來讓代碼擁有良好的語義性。
語義化首要解決的問題就是如何爲元素節點加上具有語義化的類名。
爲了實現這一目標，我們可以先回顧一下在我們開發的時候是如何給元素節點加上類名的，以如下的單個商品圖爲例。
圖12 單商品示意圖
上圖是一個商品圖的示例，我們會通過圖片、價格、圖片下方文案等因素來判斷出這是一個商品，然後我們就可以給這一個區域賦予類名 goods ，而區域內的節點，比如圖片可以賦予類名 goods_pic ，圖片下方文案可以賦予類名 goods_tit ，價格可以賦予類名 price ，這就是我們爲元素節點添加類名的一般邏輯。
可以看出，通常我們去確定一個區域，一個組件的語義時，我們需要依據區域內節點的語義組合才能進行判定，比如上面的商品組件，需要依靠內部的圖片、價格、文案等元素才能確定語義，從而確定類名。因此，語義化的處理方式，就是從容器元素的子節點出發，先確定子節點的語義，然後再推斷出容器元素的語義，一層層往上進行推斷，最終推斷出整棵節點樹完整的語義。
在語義化處理中，我們主要的處理對象就是經過佈局算法處理後的 JSON Schema 數據，我們稱之爲佈局樹，此時佈局樹已經具備了良好的結構，我們可以對它進行語義化推斷操作。推斷的流程就是從樹的葉子節點出發，一層層向上冒泡到枝節點，最後再冒泡到根節點。
圖13 節點語義推斷
目前我們進行推斷的依據主要是節點的位置、樣式、大小、兄弟節點等因素，同時會結合不同節點的類型，組合一些智能化手段進行輔助推斷。例如，最小葉子節點一般可能爲圖片、文本兩種類型，針對文本我們可以通過 NLP 的方式去分析文本的詞性、語義；針對部分圖片，我們可以使用圖片分類或識別的方式確定圖片分類或者提取圖片上的關鍵信息進行圖片的語義判定。
爲了確定每個節點的語義，我們需要組合一系列的規則對現有的事實（樣式、位置等信息）進行推理，而同時，經過一些規則推理後又會得到新的事實，又需要經過其他規則推理之後才能得到最後確定的結果。所以，這是一個基於規則推理的推理系統，我們可以通過實現一個正向鏈的推理引擎，來幫助我們進行推理決策。
圖14 正向推理引擎
例如，推斷上述商品組件的過程，首先我們先找到具備價格因素的文本節點，命名爲 price ，然後我們找到 price 附近，在樹中所處層級相近的圖片節點，並且該圖片節點符合商品圖大小的要求，這樣我們就能基本確定同時包含價格和符合商品圖特徵的容器爲商品容器，再根據容器中元素個數，圖片附近是否有一段文本，以及對文本的 NER 分析，我們就能確定這段文本是否是商品名，從而確定其語義化類名。
在整個語義化處理中，上述的判定規則只是冰山一角，我們結合整個電商場景，分析了大量設計稿與線上案例後總結了大量的判定規則來幫助我們進行合理化語義命名，同時在語義化過程中採用 NLP 分析、圖片分類及識別等 AI 手段，來協助獲得更加精準的語義化名。
圖15 語義化處理流程
（4）生成 DSL
經過前面幾步處理之後我們就能進行代碼生成了，爲了支持生成不同 DSL 的代碼，我們將語義化處理後的數據統一抽象成類 Virtual DOM 的節點描述數據，然後再將節點描述數據處理成各類 DSL 代碼，同時預留好接口，支持拓展新的 DSL。
圖16 DSL生成
圖17代碼生成示意
2、讓代碼擁有靈魂
在實現生成靜態代碼之後，我們會發現有些時候設計稿中會出現已有的組件，最好的方式是我們能夠識別出設計稿中已有的組件，然後在生成代碼的時候進行復用。
爲了解決這一問題，我們將目光投向了深度學習，利用深度學習中的目標檢測與分類算法，我們就能對設計稿中的已有組件進行識別、定位，並最終映射爲組件庫中的組件，實現組件複用的目的。
圖18 組件識別映射
組件識別映射整體處理流程是，針對輸入的設計稿圖片，先基於視覺算法進行合理切割，在對切割後的圖片識別出圖片中包含的 UI 區塊，然後將 UI 區塊映射到 Schema JSON 中的節點信息中去，而後再對區塊通過分類算法識別出最有可能的組件類型，再將識別信息寫入到 Schema JSON 的節點中，從而最終實現組件識別映射。
圖19 組件識別映射效果
目前，我們已經完成了大促業務組件庫的訓練，可以精準地識別定位設計稿中的大促組件。但我們發現，如果我們想讓其他業務來接入組件識別映射方案時存在諸多困難，其他業務團隊不具備 AI 處理能力，如果都讓我們來進行組件訓練則會極大地增加我們團隊的工作量，爲了解決這些問題，我們思考如何將 Deco 已經沉澱的 AI 能力進行共享，於是設計了 AI 開放平臺。
圖20 AI開放平臺組成
AI 開放平臺爲開發者提供了零門檻接入的圖片分類、目標識別等 AI 能力，開發者可以在 AI 開放平臺上進行自定義數據集創建管理，選用預設算法模型後就能直接進行模型訓練與預覽評估，這樣的話，如果有新組件庫需要訓練，就可以交給業務團隊通過 AI 開放平臺來自行操作。
圖21 AI開放平臺使用流程
3、在業務中進行落地
行文至此，我們已經具備了設計稿生成代碼的整體方案，但離方案進行落地實踐還有一段距離，我們需要有一個平臺來承載我們的方案，當設計稿生成靜態代碼出現誤差時，我們可以通過可視化編輯器進行二次調整，同時在獲得靜態代碼的同時，我們也可以再加上組件化、字段綁定、生命週期等邏輯處理。
（1）組件化
我們可以通過「組件標記」功能，將某一個節點標記爲一個組件，標記爲組件之後將可以進行設置組件內的狀態和數據、設置組件入參、設置組件生命週期等操作，並在最終生成代碼的時候以組件形式生成。
圖22 組件化
（2）數據定義
我們可以根據需要自行定義頁面全局數據或者組件內部數據，同時也可以通過設置 React context 來進行共享數據定義。
9圖23 數據定義
（3）異步數據請求
針對最常見的異步數據請求的場景，Deco 提供了一個可視化表單，僅需通過簡單的配置，即可快速生成異步數據請求的代碼。
圖24 異步請求界面
（4）事件綁定
Deco 提供了包括點擊事件在內的多種節點事件，以及組件的生命週期等事件的定義，用戶可以在事件中編輯邏輯代碼。
圖25 事件綁定
（5）屬性編輯及數據綁定
此外，Deco 已經提供組件映射的能力，在這基礎上，開放了組件的屬性編輯和數據綁定能力，實現頁面與動態數據的對接。
圖26 屬性編輯及數據綁定
04
未來展望
如今看來，智能代碼是一條非常值得探索的道路，它是一粒種子，也許它此時剛剛發芽，但我們對它期許頗多，我們希望通過 Deco 來探索前端智能化的道路，探索 AI 與前端結合的各種可能性，更重要的是，我們希望能夠通過 Deco 開啓產研的效率革命，在各種前端工程化、平臺、方法論趨於完善的當下，探索爲業務降本增效的另一種方式。
同時，我們一直在智能化上苦下功夫，也許在未來，我們可以直接實現設計即交付，那對業界來說無疑又是一場革新。
路漫漫其修遠兮，需要技術人上下而求索。
本文分享自微信公衆號 - 凹凸實驗室（AOTULabs）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。