“前端智慧化”存在的價值和意義，被不斷拷問。

 

一部分人對“前端智慧化”持擁抱態度，認為這是前端領域的一種革命性技術。

 

另一部分人則認為“前端智慧化”可行性範圍有限，大多是一些Demo性產品，對能否真正應用到業務生產持懷疑態度。

 

其最終目的還是要將產品和技術能力融入業務體系，釋放技術紅利，驅動業務增長。

 

本文將結合阿里雲的業務場景，分析在中後臺領域中，“前端智慧化”如何降低開發成本，提升研發效能，從而創造更深遠的業務價值。

01 讓「前端智慧化」真的運轉起來

什麼是前端智慧化？

和垂直的“端智慧”方向不同，前端智慧化關注的領域更偏向於生產效率的提升。如果更準確的描述，“前端智慧化”應該是“前端開發智慧化”。

透過AI 與前端業務深入結合，基於AI能力提供的豐富預測、推薦資訊，結合研發邏輯積累，打造更加人性化、智慧化的前端程式碼。

當然，並不是機器能生成100%的程式碼去代替前端開發，出發點是讓機器能自動化、智慧化，為前端人員減少開發工作量，代替完成可抽象、可複用、UI編排、國際化等低成本、較為繁瑣的工作，最後產出一份可以二次開發、可維護、高質量的原始碼Procode。

每一套技術方案背後，必然有完整的理論體系和運作機制。

Dumbo平臺能力

阿里雲在怎樣的業務和技術背景下做邊緣雲 “前端智慧化”？

從業務增長上來講：由於雲端計算業務整合及調整，增加了大量的控制檯、中後臺管控等B端業務，在人力基本不變的情況下，團隊如何快速支撐起這部分業務？

從業務特性上來講：主要以ToB端、中後臺為主, 重管控crud、UI編排較統一、研發邏輯相似等，雲控制檯產品的國際化等特性。

前端業務側基於以上特性沉澱了前端技術框架，研發模式是基於元件化、場景化、模組化的方案。

透過這類研發方案，不僅能實現技術成本降低，元件化開發、最佳實踐地積累等，還能透過統一的視覺標準規範，減少視覺溝通成本和溝通成本, 從而大大提高開發效率。

雖然，基於這種方式的研發方案能帶來極大的提效，但在開發過程中也存在一些元件編排複雜、程式碼重複率高、大量無關核心業務邏輯開發的工作。

因此，我們思考如何基於現有研發方案，帶來進一步提效？

首先，明確前端的研發成本。主要包括：UI 元件編排、業務邏輯（互動與資料）、文案國際化、工程鏈路、溝通成本（設計、後端、產品）等。

其次，站在巨人的肩膀上看問題。團隊調研了一些現有的提效方案，主要包括：基於視覺化搭建平臺、基於視覺化物料原始碼開發站、基於AI能力的效能提升平臺等。

在此基礎上，結合自身業務場景、現有研發方案、開發模式、學習成本等綜合因素考慮，決定打造一個“智慧化”的面向阿里雲控制檯、中後臺原始碼開發平臺。

02 Dumbo的智慧化：“智慧識別”

Dumbo「智慧化」是一個利用影像識別演算法，一鍵生成前端程式碼的智慧解決方案。目前已經落地於多個阿里雲控制檯及中後臺專案。

Dumbo的基本鏈路透過對標準化樣本進行生成，基於樣本來進行模型訓練。使用者只要輸入圖片，透過訓練的模型就能識別及最終產出前端所需程式碼。

智慧化的核心之一是“智慧識別”，主要包含：目標檢測演算法、樣本生成、模型訓練及識別。

目標檢測演算法

即輸入一張圖片，輸出圖片中感興趣物體的座標資訊。經典的目標檢測演算法有兩種，one-stage與two-stage。one-stage演算法即只對圖片處理一次，它的速度通常優於two-stage演算法，代表演算法有yolo系列。

而two-stage演算法會對圖片處理兩次，先找到可能存在目標的區域，再對該區域做一次預測。這類演算法速度較慢但準確率更好，代表演算法有Faster R-CNN。

主要使用的目標檢測演算法是SSD300。SSD300是2016年提出的一種目標檢測演算法，它是一種one-stage演算法，同時吸收了yolo和Faster R-CNN的優點，兼具速度和準確率。雖然在最新的目標檢測演算法排名中，SSD已不再具有優勢。

“ 在前端場景的目標檢測中，元件並沒有複雜的特徵形態，演算法不是最重要的因素，樣本集和超引數的設定往往比演算法本身更重要。”

SSD演算法在準確率和速度上都較YOLO有較大提升，SSD演算法在經過一次VGG-16轉換後，得到一個38 38 512的特徵圖，之後的每一次卷積運算的同時都會輸出一次預測結果。

這麼做可以兼顧大目標和小目標的檢測，感受野小的feature map檢測小目標，感受野大的feature map檢測大目標。SSD同時引入了Faster RCNN中的Anchor，提出了相似的Prior box概念，在對樣本做標記時，也是基於Prior box的偏移來做的。

在每一個不同尺寸的feature map中，都預先設定好了多個Prior box，這些先驗框可透過人為規定或統計學方法計算得到。

在對目標做標記時，SSD要求找到與待檢測目標真實框交併比最大的先驗框，由它負責預測該目標，標記的資料為兩個框之間差值。預測的時候也是同理，因此，在SSD中，會多出一步轉換的過程，用來還原真實框的位置資訊。

Dumbo把該套目標檢測演算法透過PAI深度學習訓練來訓練模型，並部署在PAI上的線上模型服務（ESA）,透過函式計算來實現服務呼叫，實現了一套模型訓練服務。

樣本生成

目標檢測的模型訓練，樣本集尤為重要。對於現有場景而言，樣本集就是各種各樣的控制檯頁面截圖。

想要識別的元件，需要在圖片中標註出來，標註格式有多種，常見的格式有xml、json、csv等。根據SSD演算法需要的標準細節，採用了xml格式對元件進行標註。以Button為例，標註資訊包括元件的左上角頂點座標、元件的長度和寬度。

不同的目標檢測演算法需要的資料可能不同，有的需要元件中心點的座標資料，有的則需要元件佔圖片的比例資料。這些資料都可以透過計算相互轉換，本質並沒有發生變化。

將圖片中所有元件都標註完成後，得到了一對樣本圖片與標註檔案的集合，大量這樣的集合便構成了樣本集。

僅使用真實控制檯頁面截圖是遠遠不夠的，並且手動標註費時又容易出錯。對此分別使用了fusion構建了動態樣本資料集。fusion風格樣本主要以阿里雲控制檯標準為主，用於訓練阿里雲控制檯場景模型。

下圖是使用fusion構建的一個隨機控制檯頁面，目前，各型別的元件分佈演算法採用的是圍繞視覺規範為均值的正態分佈，這麼做可以在少量樣本條件下訓練出表現更好的模型。後續將使用更加均勻的分佈演算法改造樣本集，因為在前端領域的目標檢測中，並不適合完全均勻分佈的佈局演算法。

舉個例子，PageHeader元件，位置資訊是其自身的一項特徵，如果在頁面底部出現了一個和PageHeader一模一樣的元件，也不應該將其標註為PageHeader。

元件內部屬性的隨機化，也要遵循一些約束，比如Select元件，邊框、右側的arrow-down Icon是其主要特徵，在使用程式碼生成時，最好不要忽略它們。圓角、邊框顏色等則不是主要特徵，可以儘量隨機化，讓訓練出的模型更具魯棒性。

一個值得思考的特徵是placeholder，“請選擇xxx”，這裡的“請選擇”實際上也是一項重要的特徵，思考一下，如果一個元件，除了右側沒有arrow-down圖示，其他特徵和Select元件一致，那麼，應該將其判斷為Select還是Input？

總結起來，訓練模型的過程，其實是讓模型挖掘到元件的完整特徵資訊，並根據各項特徵的重要程度做權重最佳化的過程。有了樣本圖片，還需要標註資訊。在Dumbo中，使用js方法獲取了每個元件的位置和長寬資料，在透過puppeteer截圖的過程中，自動匯出標註檔案。

基於以上說明，產出樣本生成服務如下：

模型訓練及識別

Dumbo提供了整套的模型訓練服務，可以方便的將已經生成好的樣本檔案進行模型訓練，這塊基於PAI的能力，把整個模型訓練鏈路整合到專案中，下圖為模型訓練的整體鏈路。

透過OSS作為中間集，進行資料和模型部署，實現了整體的模型訓練鏈路。

基於以上模型訓練鏈路，在Dumbo的fusion場景中訓練多種模型，包括整頁模型、表單模型、圖表模型、詳情頁模型、Icon模型等多個模型用於識別服務。

識別過程同時採用了遞迴識別和組合識別。這是為了提高小元件的識別準確率。同時將識別任務拆分到多個模型中，可降低各個模型的訓練難度。

03 “智慧出碼”：一鍵生成前端程式碼

透過上述的智慧識別，可以瞭解到Dumbo的全部訓練和識別過程，識別產物非前端程式碼，需要根據邊緣雲前端框架及阿里雲規範，對識別資料進行處理，最終生成前端同學可複用的佈局和邏輯程式碼程式碼，從而提高研發效率。

下圖是具體出碼實現步驟：

影像分析

“目標檢測 + 分類”看似能基本cover控制檯視覺稿的識別，然而理想很美好, 現實不夠理想。

在大量驗證過程中，發現僅透過模型預測的結果精確度偏低，一些情況下預測結果位置資訊存在一些偏差。同時為了模型收斂，也存在主體分類粒度不夠，導致無法更好的完成後續的還原工作。

為了提高識別的準確率及視覺還原度，所以採用深度學習結合傳統影像分析的方式，最佳化AI識別內容，豐富元件識別特徵度，提供給上游鏈路更豐富有效的資料資訊。

➢ 預處理：透過邊界判斷頁面padding情況，是否需要切割和補充padding來規範預測圖片內容、最佳化識別效果。

➢ 資料處理：在資料處理階段做一個初步的去重操作，該操作主要判斷：當兩個元件沒有父子關係且重疊閾值（交併比）大於某個值（這裡根據經驗取的 0.8）， 刪除置信度較低的元件。本步驟主要為了解決AI對同一個物體識別為多個不同標籤的情況。

➢ 位置最佳化：主要透過OpenCV 進行影像分析輪廓識別，在比對輪廓的重疊閥指，收斂輪廓大小使輪廓區域和實際影像更加貼合。處理結果前後對比如下：

➢ 屬性檢測：主要透過OpenCV的顏色判斷，來區分元件的屬性型別，類似分析Message元件背景色，判斷Type值為Success、Error、 Notice、Warning等。透過簡單的CV分析，可以不斷豐富元件識別特徵度，不斷提升還原度。

➢ 關係矯正：對於有父子巢狀關係的元件，識別最佳化無法處理巢狀關係異常的情況，需要加入邏輯判斷。例如radioGroup/radio則為父子關係元件，當有父子關係巢狀不完整時，需要進一步處理判斷radio 的siblings 節點，並糾正父元件的位置，將其siblings 包裹完整。

佈局分析

視覺稿還原的主要目標是：佈局還原準確、減少冗餘重複程式碼，最大程度的貼合人工還原始碼，所以需要對影像分析處理後的資料進行資料分析，增加部分節點資料，方便後續DSL轉換和出碼。

➢ 關係矩陣：分析其位置資訊（x, y, width, height），將其生成一個N維關係矩陣。判斷關係矩陣時，對行列位置進行了的閾值設定，規定在水平垂直等方向xOverlap、yOverlap 重疊閾值小於某個值可忽略重疊部分。具體示意圖如下：

➢ 行列生成：主要目的是將關係矩陣結構轉換成節點樹，同時使用柵格化的方式處理行列結構佈局。用Row節點表示一行， Col節點表示一列，遞迴呼叫transfer2Grid 方法，生成節點樹。注意：此過程需要考慮到基於元件化佈局方式特點。從而定義componentsInline 陣列，包括'Button', 'Radio', 'Checkbox' 等。

➢ 元件設定：在此步驟中，以外掛化的方式判斷不同的類庫包括Fusion樣式屬性，轉換樣式，設定元件屬性及通用樣式類。維護一個config 屬性名稱對映，對節點進行樣式相關屬性檢測及設定，同時根據位置資訊判斷一些浮動、邊距樣式等，設定通用className。這種方式有利於佈局還原始碼可讀性，可維護性。

DSL轉換

智慧識別的資料是一份平面化資料，需要還原為立體、有結構的DSL資料。轉換DSL主要透過識別文字的預處理工作，依賴分析、和各個元件的Adapter組成，最終產出一份結構化的schema資料。

預處理：Dumbo的文字識別之後產生的是一個Text節點資料，包含中英文屬性，但是文案中可能會存在一些影響最終展示的特殊符號，比如●、丫等，這些符號的誤識別會導致最終展示上出現不理想的情況，也有可能會出現長文字被截斷成為多個文位元組點的情況，需要把這些文位元組點進行合併處理等。然後對生成的元件進行國際化處理。

Adapter（以Form元件為例子）

首先，進行節點分割，分割為文位元組點和元件節點；

其次，根據Form特性，一般以元件作為FormItem的children，Text作為label屬性，優先進行元件節點判斷，透過遍歷元件節點，並透過相鄰節點函式判斷，獲取到該節點的相鄰的Text, 並根據互動稿規範的相鄰閥值，進行label判斷，由於不確定FormItem的佈局情況，可能存在上下/左右2種佈局形式，所以會同時判斷TopText和LeftText，並分別放入對應的陣列中，之後進行比較。

根據Form表單的特性，一般Form的排列形式比較一致，不是上下/左右，很少存在既有上下，又有左右的形式，所以這塊直接判斷TopText和LeftText的個數來進行佈局確認。

在瞭解佈局之後，可以再次遍歷沒有被命中的文位元組點和元件節點，因為已經確定佈局型別，所以可以直接根據閥值，來判斷是否存在只有文字的FormItem元件，進一步完善元件內容及屬性，並且可以把一部分識別不是很準確的RadioGroup等進行合併處理。

最後，進行元件的FormItem組裝，輸出給一個完成的結構化資料。

依賴分析：識別資料透過Adapter轉換之後，獲取到的Schema並不包含依賴關係，和集團的規範存在出入，依賴提取的後處理部分，就是透過對Schema的遍歷，提取使用到的元件資訊，透過對應的模版依賴庫，載入對應的依賴關係。

在視覺化微調上，基於集團的Low-Code引擎，建立了一套Fusion物料元件，支援識別資料的視覺化微調，進一步提升出碼準確率。

程式碼生成

對於程式碼生成，則主要圍繞著集團最新的搭建協議，透過場景的一系列編排，最終完成一個元件的生成。其結構大體可描述為：

在出碼處主要處理的內容，是將機器遞迴遍歷給出的字串，重進編排整合，使其具有維護的能力。主要解決的問題為：程式碼拆分/整合、狀態管理、國際化、樣式。

首先，對於程式碼的拆分和整合。目前主要根據 DSL 中的節點型別進行拆分。對於 BLOCK 、 Component 節點，直接劃分為通用的場景，以供其他頁面或者模組使用。

其次，是狀態管理。目前開發中，dva 已經成為團隊統一的狀態管理工具，在遍歷過程中會對頁面的 state 、 effects 進行提取，透過對映，完成組裝。

然後，是國際化相關的內容。在集團的搭建協議中，可以看到最新版本的國際化內容已經被替換成如下形式。

整合後的 DSL 中 i18n 的內容會被單獨提取出來，對於呼叫處是一個表示式。而目前團隊的國際化方案更多的是自有風格，所以在處理國際化節點時需要做響應的替換。

最後，是樣式相關。透過之前的佈局分析，透過一系列的計算，最終每個元件節點都被賦予了柵格化的 ClassName 。所以此處只要把佈局所需要的基礎css 檔案作為依賴引入到頁面檔案中即可。

目前來說，“前端智慧化” Dumbo平臺已接入眾多公有云控制檯應用 ，其中新控制檯接入頁面覆蓋率大於50%，研發效率感官提效約30%，在整體識別率、準確率上滿足了業務的基本要求，而在場景覆蓋、智慧化程度、智慧互動等方面，也在探索更多的提升空間。

後續，計劃進一步收斂場景規範、擴大使用場景覆蓋面的同時，不斷豐富資料模型能力，從靈活性、識別特徵度、模型準確率等多維度考慮，提高“智慧化”能力。同時，繼續讓“智慧化”和“低程式碼”進行結合，讓使用者可以透過簡單的介面配置，實現頁面線上執行。

未來的智慧化不止於程式碼，還在向端雲協同方向做更多滲透。

「影片雲技術」你最值得關注的音影片技術公眾號，每週推送來自阿里雲一線的實踐技術文章，在這裡與音影片領域一流工程師交流切磋。公眾號後臺回覆【技術】可加入阿里雲影片雲產品技術交流群，和業內大咖一起探討音影片技術，獲取更多行業最新資訊。