京東科技設計稿轉程式碼平臺介紹

架構師修行手冊發表於2024-01-25


來源:京東技術導讀

本文將介紹京東推出的設計稿轉程式碼平臺。這個平臺旨在透過智慧化工具將設計稿自動轉換為程式碼,極大提升前端開發效率。本文會探索該平臺如何利用人工智慧技術識別設計元素並生成可用程式碼,以及它對設計師與開發者工作流程的影響。




01 
前言


在今年的敏捷團隊建設中,我透過Suite執行器實現了一鍵自動化單元測試。Juint除了Suite執行器還有哪些執行器呢?由此我的Runner探索之旅開始了!

隨著金融App業務的不斷髮展,為了滿足不同場景下的使用者體驗及豐富的業務訴求,業務產品層面最直接體現就是大量新功能的上線及老業務的升級,隨之也給研發帶來了巨大的壓力,所以研發效率的提升就是當前亟需解決的問題,今天本文帶讀者來看下設計稿轉程式碼平臺是如何幫助前端研發同學提效的。



02 
  前端開發流程概述  


理解,首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板,當獲取到模板後進行模板載入,載入階段會將產物轉換為檢視樹的結構,轉換完成後將透過表示式引擎解析表示式並取得正確的值,透過事件解析引擎解析使用者自定義事件並完成事件的繫結,完成解析賦值以及事件繫結後進行檢視的渲染,最終將目標頁面展示到螢幕。

在討論之前,先看下前端開發流程,下圖是一個典型的場景:

京東科技設計稿轉程式碼平臺介紹圖 1.

透過上圖可以發現,前端開發主要分為“UI還原”和“業務邏輯實現”兩個階段,其中UI還原階段需要透過編寫程式碼對設計稿進行1:1畫素級還原,業務邏輯實現階段主要包括資料繫結及互動效果實現。

“UI還原”階段,研發通常需要藉助設計平臺的“標註”功能,對設計稿中每一個元素進測量,包括字型、間距、顏色、圓角等,一個普通的樓層通常包含幾十個元素,此階段包含了大量低效、重複、繁瑣的工作;

“業務邏輯實現”階段一般是根據具體的產品需求,進行資料的載入、繫結和互動效果的開發,如鑑權、點選事件的新增、動效實現、埋點的上報等,不同的需求在此階段的訴求差異較大,可複用性也比較低,通常需要針對每個需求進行定製開發。

可以發現“UI還原”階段特點是“低效、重複、繁瑣”,且佔用了整個研發階段的30%左右,甚至在一些弱互動的場景下,可能會佔用整個開發流程的50%以上,所以有沒有一種方式可以直接將設計稿轉換成前端程式碼,提高研發在此階段的效率?


03 
  什麼是設計稿轉程式碼(D2C)  


理解,首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板,當獲取到模板後進行模板載入,載入階段會將產物轉換為檢視樹的結構,轉換完成後將透過表示式引擎解析表示式並取得正確的值,透過事件解析引擎解析使用者自定義事件並完成事件的繫結,完成解析賦值以及事件繫結後進行檢視的渲染,最終將目標頁面展示到螢幕。

設計稿轉程式碼(Design To Code)便是解決此問題的技術,其核心思想是透過解析設計師交付的設計稿源件(Sketch、Figma、XD等),讀取出設計稿中元素的位置、樣式、圖層關係等,並透過一系列的演算法處理,最終轉換為前端程式碼。

京東科技設計稿轉程式碼平臺介紹圖 2.
D2C本質上屬於UI2Code範疇,UI常見展現形式主要分為2種,一種是以圖片(點陣圖)的方式展示,如jpg、png等,另外一種是以向量的方式展示,此種方式通常需要配合具體的設計軟體來檢視和編輯,如Sketch、XD等。所以UI轉程式碼的實現方式也主要分為兩種,即“Image To Code”和“Design To Code”。
由於圖片是點陣圖,即圖片是由一個個“畫素點”組成的,所以圖片轉程式碼通常需要藉助計算機視覺+AI的方式來實現,實現成本巨大,且受限於圖片所承載資訊的侷限性及準確性,圖片轉程式碼的方案目前還沒有特別成熟能用於生產環境的產品。
相較於圖片,設計稿所承載的資訊就非常豐富了,透過解析設計稿檔案可以讀取到準確的字型、字號、字重、色號、間距、元素關係等資訊,基於此便可以設計一系列的演算法、策略、規範,然後配合少量低成本AI演算法來實現從設計稿到前端程式碼的轉換。

3.1  D2C能做什麼?


    
透過前面的介紹可以發現,D2C的目的是將設計稿自動轉換成前端程式碼,所以D2C基本可以覆蓋所有需要將UI轉換為前端程式碼的場景。另外由於設計稿中包含了幾乎所有UI層面的資源,如圖片、切圖等資訊,D2C平臺在前端工程上也可以自動化一些操作,比如自動切圖、自動將圖片上傳到CDN等。

3.2  D2C不能做什麼?


    
雖然設計稿中包含了UI層面的很多資訊,但完整的需求通常還包含互動、動效、業務邏輯等,此部分資訊是設計稿中所不能表達的,所以此部分功能還是需要研發手動處理。

另外,D2C目前在增量需求的使用上效果比較好,因為增量需求通常需要從0到1的UI還原,不會涉及太多存量邏輯,但增量需求場景下,比如對線上樓層的改版,因為存量需求已包含大量互動、業務邏輯等,此時如果使用D2C,還需要將原有的邏輯遷移到新的UI程式碼上,在業務邏輯複雜的情況下,有點得不償失。



04 
  平臺簡介  


理解,首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板,當獲取到模板後進行模板載入,載入階段會將產物轉換為檢視樹的結構,轉換完成後將透過表示式引擎解析表示式並取得正確的值,透過事件解析引擎解析使用者自定義事件並完成事件的繫結,完成解析賦值以及事件繫結後進行檢視的渲染,最終將目

該平臺是一個功能相對完善、體驗優良的一站式研發平臺,當前核心功能是設計稿轉程式碼,目前支援根據設計稿一鍵生成Jue(金融APP原生主要開發語言)、Vue、React,Taro程式碼,已在金融APP多個團隊落地應用,覆蓋了原生、H5多個業務線,以下是典型的應用場景:

京東科技設計稿轉程式碼平臺介紹圖 3.

另外,平臺還提供了完善功能來幫助研發同學快速理解和調整系統生成的程式碼,如UI和程式碼的聯動、視覺化Dom樹、手動標註,程式碼實時修改和預覽、自動切圖、CDN管理等,主打一個實用、接地氣,下面本文透過一個1分鐘演示來快速瞭解。

平臺的關鍵操作流程為:上傳設計稿->開啟設計稿->框選要生成程式碼的區域->檢視並確認程式碼->下載程式碼,平臺目前只支援sketch設計稿,上傳設計稿的步驟建議由設計師透過Sketch外掛上傳,透過Sketch外掛可以生成準確的切圖並且可自動識別缺失字型,後續體驗會更加絲滑。

框選完要生成程式碼的區域後,可以點選右上角的“檢視程式碼”開啟程式碼區,然後點選右側的“預覽”可以檢視當前生成的程式碼效果。


05 
  高階功能介紹  


理解,首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板,當獲取到模板後進行模板載入,載入階段會將產物轉換為檢視樹的結構,轉換完成後將透過表示式引擎解析表示式並取得正確的值,透過事件解析引擎解析使用者自定義事件並完成事件的繫結,完成解析賦值以及事件繫結後進行檢視的渲染,最終將目

5.1  CSS類名修改


    
平臺目前生成的CSS樣式類名還不夠語義化,為了幫助研發快速理解生成的程式碼並基於程式碼快速二次開發,平臺提供了修改class類名的功能。雙擊Dom結構中的class名稱即可進入編輯狀態,修改完成後回車即可生效。

5.2  列表的識別


    
平臺目前提供了自動識別列表、滾動列表、多行列表的能力,如下所示,針對列表生成的程式碼會自動計算列表寬度、列表項橫向及縱向間距。
針對於滾動列表,會生成語言特定程式碼,如Jue中,滾動會透過scroll標籤實現,標準html中,如vue、react等會透過overflow控制,效果如下所示:

5.3  列表多狀態


    
實際場景中,列表中通常會有多種狀態的樣式,平臺提供了手動建立狀態的功能,如下面示例,tab列表中,分為選中的狀態和未選中的狀態,分為兩種樣式,選中的狀態tab邊框、顏色、背景、字重都與正常狀態有所有區別,此時可以透過“建立狀態”的功能為列表新增狀態,狀態新增完成後,平臺會自動生成針對性的樣式,如下所示:

5.4  標記功能介紹


    
“標記”是一種兜底功能,當平臺生成的程式碼不符合研發的預期時,可透過“標記”功能進行手動打標,如下面示例中的任務列表並沒有自動識別為列表,此時可以透過手動標記的方式,將容器標記為“列表”,這樣平臺則會自動生成帶迴圈列表的程式碼,同時也可以為列表項新增狀態,見下演示:
除了可以將容器標記為列表外,另一種常見的場景為,將容器標記為圖片。下面這個示例中是一個帶圖表的樓層,圖表在UI裡的表達是很複雜的,因此生成的程式碼效果也不夠理想,此外,研發在實現圖表時,通常是藉助圖表庫來實現,如eCharts等,此時只需要在生成的程式碼中佔位即可,研發基於生成的程式碼二次開發時,可自行將對應位置替換成圖表,下面來展示具體的操作:
如上所示,首先將和圖表相關的dom節點透過“編組”的功能放到一個容器裡,然後將容器標記為圖片,此時平臺生成程式碼時會自動將對應的dom轉換成圖片,對應的代裡也只會生成一個img標籤,同時還可以給標記為圖片的容器再編個組,這樣生成的程式碼就是img外套了一層div,更方便二次開發。


06 
  結尾  


理解,首先 MCube 會依據模板快取狀態判斷是否需要網路獲取最新模板,當獲取到模板後進行模板載入,載入階段會將產物轉換為檢視樹的結構,轉換完成後將透過表示式引擎解析表示式並取得正確的值,透過事件解析引擎解析使用者自定義事件並完成事件的繫結,完成解析賦值以及事件繫結後進行檢視的渲染,最終將目

經過持續攻關和最佳化,該平臺已在京東金融APP原生、H5十幾個頁面、幾十個樓層中落地應用。目前該平臺已在內部生產使用階段,後續會進一步最佳化生成的程式碼質量及易用性,比如新增對UI元件的支援,即生成的程式碼自動引入特定的UI元件庫,預計2024年在京東集團內部推廣,後期平臺成熟後會對外開放。

來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/70027824/viewspace-3005059/,如需轉載,請註明出處,否則將追究法律責任。

相關文章