前端代碼是怎樣智能生成的 - 語義化篇

做爲阿里經濟體前端委員會四大技術方向之一，前端智能化項目經歷了 2019 雙十一的階段性考驗，交出了不錯的答卷，天貓淘寶雙十一會場新增模塊 79.34% 的線上代碼由前端智能化項目自動生成。在此期間研發小組經歷了許多困難與思考，本次 《前端代碼是怎樣智能生成的》 系列分享，將與你們分享前端智能化項目中技術與思考的點點滴滴。

---

文/卡狸

概述

imgcook 是以各類設計稿圖像（Sketch/PSD/靜態圖片）爲原材料烹飪的匠心大廚，經過智能化手段將各類原始設計稿一鍵生成可維護的 UI 試圖代碼和邏輯代碼。

語義化是什麼？

語義 主要研究符號標記，以及他們所表明的事物之間的關係，語言學中主要研究符號所表達的意思，而在 web 前端開發領域中，語義化 指編寫 HTML 的過程當中「用最恰當語義的 html 標籤和 class 類名等內容，讓頁面具備良好的結構與含義，從而讓人和機器都能快速理解網頁內容」。語義化的 web 頁面一方面可讓機器（搜索引擎、爬蟲、屏幕閱讀器）在更少的人類干預下收集並研究網頁的信息，從而能夠讀懂網頁內容，收集彙總信息進行分析；另外一方面它可讓開發人員讀懂結構，快速理解頁面各區塊功能，便於二次維護。 簡單來講就是利於 SEO，便於閱讀維護理解。

傳統語義化包含了 html 標籤的語義和 class 類名的語義。

先說 html 標籤語義，在 HTML 5 出現以前，咱們只能用沒有語義的 div 來表示頁面章節。如今，經過使用 HTML5 語義元素標籤，如 body、article、nav、aside、section、header、footer、hgroup等，咱們能夠經過讀取 html 結構就瞭解頁面的佈局結構。在 react-native、rax 等跨端 UI 體系下，標籤一般被各類組件替代，標籤語義化也就轉換成了「組件語義化」，在合適的場景下使用合適的組件名便可實現結構可讀。

class 類名語義化指用易於理解的名稱對 html 標籤附加的 class 或 id 命名。class 屬性本意用來描述元素樣式內容的，通過前端領域多年的演變，已經不只侷限於作 HTML 和 CSS 的銜接，而是一個集樣式定義、函數鉤子、組件類型等多層意義的複雜屬性。 本文將專一於 class 類名語義化這個問題，嘗試運用 D2C 的能力完全解決，

所在分層

在總體架構中，語義化層負責對佈局算法生成的視圖進行語義推測，用較爲人性化的類名替換初始值，從而達到接近前端本身命名的效果。

(D2C 技術能力分層)

制定 class 類名命名原則

業界規範

BEM（Block，Element，Modifier）
**
BEM 是塊（block）、元素（element）、修飾符（modifier）的簡寫，由 Yandex 團隊提出的一種前端 CSS 命名方法論。用中劃線、雙下劃線、單下劃線來作單詞間的連接記號，經過將頁面分解爲一個個小小的可重複使用組件來解決複雜項目的命名問題。好比：.block {}、.block__element {}、.block--modifier {}，都是典型的 BEM 命名模式，他們的命名規範、可讀性高，經過組件的修飾符就能夠了解組件的形態。

NEC（nice easy css）

國內的網易團隊指定的前端樣式規範。經過指定的單字母前端來作功能劃分，大致上有如下功能：重置和默認（reset + base）、佈局（g-）、模塊（m-）、元件（u-）、功能（f-）、皮膚（s-）、狀態（z-）、js 鉤子（j-）等。基於上述單字母命名，再使用簡約而不失語義的後代選擇器名稱追加其後。典型的 NEC 命名如m-list、u-btn-hover等。

AliceUi

用扁平化的方式劃分爲不一樣層級。基於 - 符號作命名空間隔離，第一個前綴一般是通用業務標識，各業務線選取本身的前綴，後面依次用組件名、組件狀態等填充。組件名必選，且要求表意，模塊內部類名需繼承上層名稱。ui-name-status、ui-page-item-info都是典型的 AliceUi 命名方式。

業界的 class 類名規範的目的都是解決大規模項目下的樣式命名問題，且由於遵循了各類層級結構關係和私有約定，編寫出的類名廣泛較長、在不瞭解規範的人眼中須要有必定的適應過程。不是特別適合 D2C 主打的移動端輕量級的模塊開發場景。

從實際場景推導

爲了尋求適合的場景，咱們分析了內部的前端工程師在導購開發業務下真實代碼的樣式命名。下圖是咱們對淘系導購頁面的真實詞頻統計結果，左圖是樣式全名詞頻，右圖是拆分以後的原子結果：

(前端樣式詞頻分析)

圖中樣式命名有以下特色：

• 和 BEM 、NEC  等規範的風格不一樣，實際開發場景中的命名相對簡潔
• 準確表達語義，且和節點業務特徵強關聯
• 單詞爲主，複合詞採用駝峯命名，長度一般不超過 3
• 輔助性的修飾詞如： wrap 、 ctn 、 empty 、 desc 等高頻出現
• 可以使用通俗易懂的簡寫單詞

制定命名原則

D2C 但願優先解決淘系移動業務的問題，整體上以實際場景爲主，業界規範爲輔，最終肯定了以表意爲主要原則的樣式命名策略：

• 表意：樣式名需準確表達節點意義，選擇上優先從移動端業務真實類名中獲取
• 簡潔：以單個詞爲主，全部詞都使用不超過三個原子詞組合
• 規範：以駝峯爲主，同時在代碼轉化層面保留了轉化爲連字符的能力
• 工整：從模塊根節點開始，採用 佈局信息 + 區塊語義 + 語義輔助 的總體命名策略

類名策略樹

命名原則肯定後，咱們至關於定義了一個樹的最終葉子節點形態，接下來須要構建從枝幹一點點按圖索驥到這些最終節點的過程，最終構建出咱們的類名策略樹。

判別維度

在實際對節點類名命名的過程當中，咱們要考慮的規則每每是多個維度的：

(樣式判別維度)

imgcook 對淘系多達幾百的模塊進行規則提取，根據真實書寫習慣，將上述規則作了權重，通常來講咱們但願功能類別優先於樣式特徵，即一個按鈕播放器按鈕命名爲 playBtn 而不是 circleIcon。 其餘的規則做爲輔助決策，在整個樹中左右走向。

基於節點樣式、內容、層級、特徵、權重、佈局、全局計數對組件節點作了多方位多種類型的鑑別。同時藉助阿里內部 sqi 平臺和 D2C 自身的智能化能力，實現對一些經驗規則解決不了的節點類名的鑑別。

(D2C 樣式命名選型)

策略定型

在建設完成阿里內部業務專屬的類名專家系統後，結合智能化算法，咱們升級了策略判別的流程，並整合出了下面這個最終的策略樹。從根節點出發，大部分節點均可以經過此策略樹概括到一個具體語義結果上。

(D2C 樣式策略樹)

類名識別服務

核心實現

在實現上述樣式命名策略樹的過程當中，咱們產出了一個專用於推測 imgcook 模塊佈局類名的服務：

(語義化 Semantic Service 結構圖)

semantic-core 提供總體的節點樹遍歷流程控制，分爲前置和後置兩個處理過程。
預處理過程會向組件節點追加檢索索引，同時會檢索組件樹中符合條件、須要調用 iconFont  識別服務的圖片統一聚合發送請求。後置處理中會對各個語義項處理的結果標記進行排序、應用前綴類名、執行組件索引清理等。

semnatic-text 、 semantic-pic 、 semantic-view 、 semantic-layout  是 imgcook 內置的語義算法。分別分析 文字、圖片、容器 和 佈局相關的信息。

每一個語義項執行過程以下：

• 判斷是否命中語義策略，未命中則結束此語義執行（語義策略下面會有詳解）
• 判斷是否會影響父元素，是則檢索父元素，追加當前語義項的標記
• 判斷是否會影響兄弟元素，是則檢索兄弟元素，追加當前語義項的標記
• 判斷當前命中的語義策略置信度是否可靠，是則爲當前節點追加數據推薦標記
• 最終，一個節點會獲得不少不一樣置信度的語義項標記結果。經過統一篩選，獲得此節點最後生效的類名

(語義項執行流程)

細節實現

在向各個策略葉子節點的推導過程當中，咱們會使用最適合的能力實現需求，好比爲了解決「鑑別小圖標」這個語義判別過程當中咱們部署了 IconFont 服務來實現，具體流程以下：

1. 從iconfont網站上獲取iconfont的圖標文件，並轉成png格式，以下圖
2. 使用一個自編碼器把圖片編碼到特徵空間
3. 使用t-SNE映射到二維平面上看看效果
4. 在特徵空間上使用聚類算法將相似的icon聚到一塊兒
5. 手工剔除質量較差的版本，而後將一個類簇中的命名根據已有名稱進行選舉

(IconFont 識別服務執行流程)

iconFont 服務用於解決小圖標命名問題，至今仍然在持續優化中。

展望將來

典型應用

imgcook 語義化能力自從方案上線以來已支持了一年多的線上業務。如下是2019年雙11的模塊倉庫中找到的，可驗收語義化成果的一個模塊：

(語義識別結果)

從該模塊的還原效果中可見，依次命中了 佈局邏輯、圖片分類、IconFont分類、翻譯、店鋪名、樣式特徵、價格判斷等內置策略。大部分節點都有語義項命中，其中識別較爲準確且貼近語義的節點佔比 60%+。

衍生方向

語義化本質是推測節點特徵的過程，在識別準確度沒有要求時能夠做爲 class 名使用。對於識別準確度極高的預測結果，咱們認爲節點和數據也有映射成功的可能性。

由於咱們但願 D2C 能推測出節點綁定字段並實如今業務中落地，因此基於語義化的思路， D2C 孵化出了目的性更強、對準確度要求更高的節點數據字段推測服務。

感興趣的同窗能夠移步本系列的「字段綁定」文章繼續深刻了解。

---

更多推薦：

• imgcook 官網  體驗一鍵智能生成代碼
• imgcook 知乎專欄  爲你帶來前端智能化前沿資訊
• imgcook 掘金專欄  設計稿智能生成代碼
• 釘釘交流

---

招聘

咱們是頻道與D2C智能團隊，致力於探尋智能與前端的鏈接點，研發前端智能化。團隊成員業務涉及機器學習、算法、規模化智能會場設計。

咱們的工做:

主要負責阿里巴巴前端委員會智能化方向核心技術設計落地、imgcook.com 平臺建設及開放和開源，部分參與淘寶天貓的核心業務研發。

• 直接對接谷歌 tensorflow 團隊，推進 tensorflow.js 在前端的應用。
• 利用 Faas 構建更適合前端的 Serverless 服務。
• 支撐天貓、聚划算、淘寶等大流量業務。

咱們須要你：

• 對主流前端技術棧有全面、升入的理解
• 對 W3C、TC39 等國際標準化組織在前端領域和瀏覽器領域的標準有全面的瞭解。
• 對本身的成長路徑有清晰明確的職業生涯規劃和技術提高目標。
• 英語據說寫能力優秀者優先。

咱們的目標:

• 幫助前端邁進智能化時代。
• 藉助人工智能和機器學習打造前端零研發解決方案。
• 用前端邊緣計算理解用戶定義下一代交互體驗。

更多請查看：阿里巴巴招聘官網 JD

若是你不想錯過人工智能這個時代風口，對 前端和 AI 結合 相關感興趣，簡歷請投遞： miaojing@taobao.com 或者 釘釘聯繫 妙淨。