從 0到1:如何快速地將設計稿生成代碼
導讀:今年雲棲大會期間,阿里雲 Hands on Labs 動手實驗室推出有獎體驗活動,立即參加體驗從設計稿自動生成 H5 應用的神奇。
本文字數:3960,閱讀時長大約:6分鐘
https://yunqi.aliyun.com/2020/hol
作者:Imgcook
文末有驚喜,不要忘了去文末看哦~
什麼是 imgCook?
imgcook 可以使用 Sketch、PSD、靜態圖片等形式作為輸入,通過智能化技術一鍵生成可維護的前端代碼,包含視圖代碼、數據欄位綁定、組件代碼、部分業務邏輯代碼等。
Img Cook 期望能夠利用智能化手段,讓自己成為一位前端工程師,在對設計稿輕約束的前提下實現高度還原,釋放前端生產力,助力前端與設計師高效協作,讓工程師們專註於更具挑戰性的工作!
設計稿生成代碼的難點
視圖代碼研發,一般是根據視覺稿編寫 HTML 和 CSS 代碼。如何提效,當面對 UI 視圖開發重複性的工作時,自然想到組件化、模塊化等封裝復用物料的解決方案,基於此解決方案會有各種 UI 庫的沉澱,甚至是可視化拼裝搭建的更高階的產品化封裝,但復用的物料不能解決所有場景問題。個性化業務、個性化視圖遍地開花,直面問題本身,直接生成可用的 HTML 和 CSS 代碼是否可行?
這是業界一直在不斷嘗試的命題,通過設計工具的開發插件可以導出圖層的基本信息,但這裡的主要難點還是對設計稿的要求高、生成代碼可維護性差,這是核心問題,我們來繼續拆解。
設計稿要求高
對設計稿的要求高,會導致設計師的成本加大,相當於前端的工作量轉嫁給了設計師,導致推廣難度會非常大。一種可行的辦法是採用 CV(ComputerVision, 計算機視覺) 結合導出圖層信息的方式,以去除設計稿的約束,當然對設計稿的要求最好是直接導出一張圖片,那樣對設計師沒有任何要求,也是我們夢寐以求的方案,我們也一直在嘗試從靜態圖片中分離出各個適合的圖層,但目前在生產環境可用度不夠(小目標識別精準度問題、複雜背景提取問題仍待解決),畢竟設計稿自帶的元信息,比一張圖片提取處理的元信息要更多更精準。
代碼可維護性
生成的代碼結構一般都會面臨可維護性方面的挑戰:
?合理布局嵌套:包括絕對定位轉相對定位、冗餘節點刪除、合理分組、循環判斷等方面;
?元素自適應:元素本身擴展性、元素間對齊關係、元素最大寬高容錯性;
?語義化:類名的多級語義化;
?樣式 CSS 表達:背景色、圓角、線條等能用 CV 等方式分析提取樣式,儘可能用 CSS 表達樣式代替使用圖片;
問題如何解決?
基於上述的概述和問題分解後,我們對現有的 D2C(Design 2 Code) 智能化技術體系做了能力概述分層,主要分為以下三部分:
?識別能力:即對設計稿的識別能力。智能從設計稿分析出包含的圖層、基礎組件、業務組件、布局、語義化、數據欄位、業務邏輯等多維度的信息。如果智能識別不準,就可視化人工干預補充糾正,一方面是為了可視化低成本干預生成高可用代碼,另一方面這些干預後的數據就是標註樣本,反哺提升智能識別的準確率。
?表達能力:主要做數據輸出以及對工程部分接入:a)通過 DSL 適配將標準的結構化描述做 Schema2Code;b)通過 IDE 插件能力做工程接入。
?演算法工程:為了更好的支撐 D2C 需要的智能化能力,將高頻能力服務化,主要包含數據生成處理、模型服務部分:
??樣本生成:主要處理各渠道來源樣本數據並生成樣本
??模型服務:主要提供模型 API 封裝服務以及數據迴流
(前端智能化 D2C 能力概要分層)
在整個方案里,我們用同一套**數據協議規範(D2C Schema)**來連接各層的能力,確保其中的識別能夠映射到具體對應的欄位上,在表達階段也能正確地通過出碼引擎等方案生成代碼。
智能識別技術分層
在整個 D2C 項目中,最核心的是上述識別能力部分的機器智能識別部分,這層的具體再分解如下:
?物料識別層:主要通過圖像識別能力識別圖像中的物料(模塊識別、原子模塊識別、基礎組件識別、業務組件識別)。
?圖層處理層:主要將設計稿或者圖像中圖層進行分離處理,並結合上一層的識別結果,整理好圖層元信息。
?圖層再加工層:對圖層處理層的圖層數據做進一步的規範化處理。
?布局演算法層:轉換二維中的絕對定點陣圖層布局為相對定位和 Flex 布局。
?語義化層:通過圖層的多維特徵對圖層在生成代碼端做語義化表達。
?欄位綁定層:對圖層里的靜態數據結合數據介面做介面動態數據欄位綁定映射。
?業務邏輯層:對已配置的業務邏輯通過業務邏輯識別和表達器來生成業務邏輯代碼協議。
?出碼引擎層:最後輸出經過各層智能化處理好的代碼協議,經過表達能力(協議轉代碼的引擎)輸出各種 DSL 代碼。
(D2C 識別能力技術分層)
技術痛點
當然,這其中的識別不全面、識別準確度不高一直是 D2C 老生常談的話題,也是 imgcook 的核心技術痛點。我們嘗試從這幾個角度來分析引起這個問題的因素:
?識別問題定義不準確:問題定義不準確是影響模型識別不準的首要因素,很多人認為樣本和模型是主要因素,但在這之前,可能一開始的對問題的定義就出現了問題,我們需要判斷我們的識別訴求模型是否合適做,如果合適那該怎麼定義清楚這裡面的規則等。
?高質量的數據集樣本缺乏:我們在識別層的各個機器智能識別能力需要依賴不同的樣本,那我們的樣本能覆蓋多少前端開發場景,各個場景的樣本數據質量怎麼樣,數據標準是否統一,特徵工程處理是否統一,樣本是否存在二義性,互通性如何,這是我們當下所面臨的問題。
?模型召回低、存在誤判:我們往往會在樣本里堆積許多不同場景下不同種類的樣本作為訓練,期望通過一個模型來解決所有的識別問題,但這卻往往會讓模型的部分分類召回率低,對於一些有二義性的分類也會存在誤判。
如何使用 imgCook 將設計稿變為前端代碼
在了解了 imgcook 大致思路之後,那麼為什麼會選擇在雲開發平台上集成 imgcook 呢?那就是 imgcook 和雲開發平台通過彼此的打通,將能夠為雙方解決彼此的痛點,無論是為雲上開發者,還是 imgcook 開發者都提供了全新的用戶體驗。
對於 imgcook 開發者來說,其中一個痛點就來自於對於設計稿的管理,以及前後端交互的邏輯,然而通過雲開發平台,開發者不再需要在本地安裝 Sketch,通過雲開發平台直接上傳設計稿即可開始生成代碼,真正做到了0成本一鍵生成。
另外雲開發平台上直接提供了Midway Serverless框架,我們通過雲開發平台的插件定製化,可以讓開發者直接選擇某個頁面所使用的函數(Function),這樣就節省掉編寫一些前後端交互的基礎邏輯或請求代碼。
對於雲開發平台的開發者來說,最想得到的便是極速的上線體驗和更加便捷的開發體驗,imgcook 可以降低雲開發平台的使用門檻,比如一位 FaaS 應用工程師不再需要學習如何切圖,如何寫 CSS,而只需要編寫 FaaS 函數的邏輯即可,剩下的前端邏輯代碼都可以通過 imgcook 插件在開發平台內即可完成,這是多麼棒的體驗啊!
那麼,接下來就看看如何快速地從 0 到 1 生成代碼吧。
首先需要先打開雲開發平台創建應用,選擇 imgcook 創建應用:
然後在應用的 WebIDE 中通過右鍵打開 imgcook 雲插件,就可以正式開始使用了。
第一步,在插件中選擇「導入」,打開上傳設計稿界面:
第二步,imgcook 可視化編輯器:
第三步,生成代碼:
第四步,導出代碼到應用:
第五步,上線應用:
啟動成功後通過命令行的地址打開頁面效果如下,是不是很簡單呢?
總結
本文通過介紹前端智能化的背景,imgcook 的問題定義以及技術方案,以及如何在雲開發平台上使用 imgcook 開始智能開發,總的來說,還是希望讓業內的前端工程師們從使用 imgcook 開始,將日常工作中的一些繁瑣、耗時的工作交給 AI 來完成,這樣能關注工程師本身更感興趣,也更有價值的事情,也相信不久的將來,前端工程師將藉助於 AI 能更加快樂與從容地工作!
一場腦洞實驗
今年雲棲大會期間,阿里雲 Hands on Labs 動手實驗室推出有獎體驗活動,立即參加體驗從設計稿自動生成 H5 應用的神奇。
同時,由 Hands-on Labs 發起的萬人云上 Hello World 實驗上線
??這是一場腦洞實驗,想邀請 10000 名開發者雲上 Hello World。希望你願意來見證這場實驗;
??每一位參與實驗的開發者都會收到一張電子榮譽證書,不為別的,和另外 9999 人紀念一下可好?
??每一位成功參與實驗的開發者都有機會參與每天一次的錦鯉程序員抽獎活動,哪怕可能性只有萬分之一,來都來了,參與一下唄;
??感謝中國國內技術社區們的大力支持,有你們的情懷在,才有這場腦洞實驗從發起到落地。
※Linux 黑話解釋:什麼是顯示伺服器,用來做什麼?
※新聞拍一拍#Debian 項目曾討論永久禁止 Linus Torvalds 出席會議