设计稿生成代码与 Serverless 的前世今生与未来!
一場腦洞實驗
云棲大會云上 Hello World 活動火熱進行中!每位參與者都可收獲一份阿里云出品的全球唯一序列號紀念證書!
作為阿里經濟體前端委員會的四大技術方向之一,前端智能化方向一被提及,就不免有人好奇:前端結合機器學習能做些什么,怎么做,未來會不會對前端產生很大的沖擊等等。本文以「設計稿自動生成代碼」場景為例,細述我們的思考及過程實踐。
前端智能化與云 IDE 的結合,通過后者打通的各種服務與接口,再加上設計稿生成代碼的能力,可以進一步地提升前端開發者的開發體驗,由原來的設計稿生成代碼,轉變為生成可隨時可部署的應用/頁面,因此本文最后會介紹如何在阿里云云開發平臺使用 imgcook 插件,一鍵完成設計稿稿生成應用,開啟您的智能開發之旅。
前端智能化背景
業界機器學習之勢如火如荼,「AI 是未來的共識」頻頻出現在各大媒體上。李開復老師也在《AI · 未來》指出,將近 50% 的人類工作將在 15 年內被人工智能所取代,尤其是簡單的、重復性的工作。并且,白領比藍領的工作更容易被取代;因為藍領的工作可能還需要機器人和軟硬件相關技術都突破才能被取代,而白領工作一般只需要軟件技術突破就可以被取代,那我們前端這個“白領”工作會不會被取代,什么時候能被取代多少?
回看 2010 年,軟件幾乎吞噬了所有行業,帶來近幾年軟件行業的繁榮;而到了 2019 年,軟件開發行業本身卻又在被 AI 所吞噬。你看:DBA 領域出現了 Question-to-SQL,針對某個領域只要問問題就可以生成 SQL 語句;基于機器學習的源碼分析工具 TabNine 可以輔助代碼生成;設計師行業也出了 P5 Banner 智能設計師“鹿班”,測試領域的智能化結合也精彩紛呈。那前端領域呢?
那就不得不提一個我們再熟悉不過的場景了,它就是設計稿自動生成代碼(Design2Code,以下簡稱 D2C),阿里經濟體前端委員會 - 前端智能化方向當前階段,就是聚焦在如何讓 AI 助力前端這個職能角色提效升級,杜絕簡單重復性工作,讓前端工程師專注更有挑戰性的工作內容!
imgcook 是什么?
imgcook 使用 Sketch、PSD、靜態圖片等形式作為輸入,通過智能化技術一鍵生成可維護的前端代碼,包含視圖代碼、數據字段綁定、組件代碼、部分業務邏輯代碼等。
它期望能夠利用智能化手段,讓自己成為一位前端工程師,在對設計稿輕約束的前提下實現高度還原,釋放前端生產力,助力前端與設計師高效協作,讓工程師們專注于更具挑戰性的工作!
設計稿生成代碼的目標是讓 AI 助力前端這個職能角色提效升級,杜絕簡單重復性工作內容。那我們先來分析下,“常規”前端尤其是面向 C 端業務的同學,一般的工作流程日常工作內容大致如下:
“常規”前端一般的開發工作量,主要集中在視圖代碼、邏輯代碼和數據聯調這幾大塊,接下來,我們逐塊拆解分析。
1. 問題定義
視圖代碼研發,一般是根據視覺稿編寫 HTML 和 CSS 代碼。如何提效?當面對 UI 視圖開發重復性的工作時,自然想到組件化、模塊化等封裝復用物料的解決方案,基于此解決方案會有各種 UI 庫的沉淀,甚至是可視化拼裝搭建的更高階的產品化封裝,但復用的物料不能解決所有場景問題。個性化業務、個性化視圖遍地開花,直面問題本身,直接生成可用的 HTML 和 CSS 代碼是否可行?
這是業界一直在不斷嘗試的命題,通過設計工具的開發插件可以導出圖層的基本信息,但這里的主要難點還是對設計稿的要求高、生成代碼可維護性差,這是核心問題,我們來繼續拆解。
1)設計稿要求高
對設計稿的要求高,會導致設計師的成本加大,相當于前端的工作量轉嫁給了設計師,導致推廣難度會非常大。
一種可行的辦法是采用 CV(ComputerVision, 計算機視覺) 結合導出圖層信息的方式,以去除設計稿的約束,當然對設計稿的要求最好是直接導出一張圖片,那樣對設計師沒有任何要求,也是我們夢寐以求的方案,我們也一直在嘗試從靜態圖片中分離出各個適合的圖層,但目前在生產環境可用度不夠(小目標識別精準度問題、復雜背景提取問題仍待解決),畢竟設計稿自帶的元信息,比一張圖片提取處理的元信息要更多更精準。
2)代碼可維護性
生成的代碼結構一般都會面臨可維護性方面的挑戰:
- 合理布局嵌套:包括絕對定位轉相對定位、冗余節點刪除、合理分組、循環判斷等方面;
- 元素自適應:元素本身擴展性、元素間對齊關系、元素最大寬高容錯性;
- 語義化:類名的多級語義化;
- 樣式 CSS 表達:背景色、圓角、線條等能用 CV 等方式分析提取樣式,盡可能用 CSS 表達樣式代替使用圖片。
將這些問題拆解后,分門別類專項解決,解決起來看似沒完沒了,但好在目前發現的大類問題基本解決。
很多人質疑道:這部分能力的實現看起來和智能化一點關系都沒有,頂多算個布局算法相關的專家規則系統。沒錯,現階段這部分比較適合規則系統,對用戶而言布局算法需要接近 100% 的可用度,另外這里涉及的大部分是無數屬性值組合問題,當前用規則更可控。如果非要使用模型,那這個可被定義為多分類問題。同時,任何深度學習模型的應用都是需要先有清晰的問題定義過程,把問題規則定義清楚本就是必備過程。
但在規則解決起來麻煩的情況下,可以使用模型來輔助解決。比如 合理分組(如下圖) 和 循環項 的判斷,實踐中我們發現,在各種情況下還是誤判不斷,算法規則難以枚舉,這里需要跨元素間的上下文語義識別,這也是接下來正在用模型解決的重點問題。
2. 技術方案
基于上述的概述和問題分解后,我們對現有的 D2C 智能化技術體系做了能力概述分層,主要分為以下三部分:
-
識別能力:即對設計稿的識別能力,智能從設計稿分析出包含的圖層、基礎組件、業務組件、布局、語義化、數據字段、業務邏輯等多維度的信息;如果智能識別不準,就可視化人工干預補充糾正,一方面是為了可視化低成本干預生成高可用代碼,另一方面這些干預后的數據就是標注樣本,反哺提升智能識別的準確率;
-
表達能力:主要做數據輸出以及對工程部分接入:a)通過 DSL 適配將標準的結構化描述做 Schema2Code;b)通過 IDE 插件能力做工程接入;
-
算法工程:為了更好的支撐 D2C 需要的智能化能力,將高頻能力服務化,主要包含數據生成處理、模型服務部分:
- 樣本生成:主要處理各渠道來源樣本數據并生成樣本;
- 模型服務:主要提供模型 API 封裝服務以及數據回流。
(前端智能化 D2C 能力概要分層)
在整個方案里,我們用同一套數據協議規范(D2C Schema)來連接各層的能力,確保其中的識別能夠映射到具體對應的字段上,在表達階段也能正確地通過出碼引擎等方案生成代碼。
1)智能識別技術分層
在整個 D2C 項目中,最核心的是上述識別能力部分的機器智能識別部分,這層的具體再分解如下:
-
物料識別層:主要通過圖像識別能力識別圖像中的物料(模塊識別、原子模塊識別、基礎組件識別、業務組件識別);
-
圖層處理層:主要將設計稿或者圖像中圖層進行分離處理,并結合上一層的識別結果,整理好圖層元信息;
-
圖層再加工層:對圖層處理層的圖層數據做進一步的規范化處理;
-
布局算法層:轉換二維中的絕對定位圖層布局為相對定位和 Flex 布局;
-
語義化層:通過圖層的多維特征對圖層在生成代碼端做語義化表達;
-
字段綁定層:對圖層里的靜態數據結合數據接口做接口動態數據字段綁定映射;
-
業務邏輯層:對已配置的業務邏輯通過業務邏輯識別和表達器來生成業務邏輯代碼協議;
-
出碼引擎層:最后輸出經過各層智能化處理好的代碼協議,經過表達能力(協議轉代碼的引擎)輸出各種 DSL 代碼。
(D2C 識別能力技術分層)
2)技術痛點
當然,這其中的識別不全面、識別準確度不高一直是 D2C 老生常談的話題,也是 imgcook 的核心技術痛點。我們嘗試從這幾個角度來分析引起這個問題的因素:
-
識別問題定義不準確:問題定義不準確是影響模型識別不準的首要因素,很多人認為樣本和模型是主要因素,但在這之前,可能一開始對問題的定義就出現了問題,我們需要判斷我們的識別訴求模型是否合適做,如果合適那該怎么定義清楚這里面的規則等;
-
高質量的數據集樣本缺乏:我們在識別層的各個機器智能識別能力需要依賴不同的樣本,那我們的樣本能覆蓋多少前端開發場景,各個場景的樣本數據質量怎么樣,數據標準是否統一,特征工程處理是否統一,樣本是否存在二義性,互通性如何,這是我們當下所面臨的問題;
-
模型召回低、存在誤判:我們往往會在樣本里堆積許多不同場景下不同種類的樣本作為訓練,期望通過一個模型來解決所有的識別問題,但這卻往往會讓模型的部分分類召回率低,對于一些有二義性的分類也會存在誤判。
【問題定義】
深度學習里的計算機視覺類模型目前比較適合解決的是分類問題和目標檢測問題,我們判斷一個識別問題是否該使用深度模型的前提是——我們自己是否能夠判斷和理解,這類問題是否有二義性等,如果人也無法準確地判斷,那么這個識別問題可能就不太合適。
假如判斷適合用深度學習的分類來做,那就需要繼續定義清楚所有的分類,這些分類之間需要嚴謹、有排他性、可完整枚舉。比如在做圖片的語義化這個命題的時候,一般圖片的 ClassName 通用常規命名有哪些,舉個例子,其分析過程如下:
-
第一步:盡可能多地找出相關的設計稿,一個個枚舉里面的圖片類型;
-
第二步:對圖片類型進行合理歸納歸類,這是最容易有爭論的地方,定義不好有二義性會導致最有模型準確度問題;
-
第三步:分析每類圖片的特征,這些特征是否典型,是否是最核心的特征點,因為關系到后續模型的推理泛化能力;
-
第四步:每類圖片的數據樣本來源是否有,沒有的話能否自動造;如果數據樣本無法有,那就不適合用模型,可以改用算法規則等方式替代先看效果。
D2C 項目中很多這樣的問題,問題本身的定義需要非常精準,并且需要有科學的參考依據,這一點本身就比較難,因為沒有可借鑒的先例,只能先用已知的經驗先試用,用戶測試有問題后再修正,這是一個需要持續迭代持續完善的痛點。
【樣本質量】
針對樣本問題,我們需要對這部分數據集建立標準規范,分場景構建多維度的數據集,將收集的數據做統一的處理和提供,并以此期望能建立一套規范的數據體系。
在這套體系中,我們使用統一的樣本數據存儲格式,提供統一的針對不同問題(分類、目標檢測)的樣本評估工具來評估各項數據集的質量,針對部分特定模型可采取效果較好的特征工程(歸一化、邊緣放大等)來處理,同類問題的樣本也期望能在后續不同的模型里能夠流通作比較,來評估不同模型的準確度和效率。
(數據樣本工程體系)
【模型】
針對模型的召回和誤判問題,我們嘗試收斂場景來提高準確度。往往不同場景下的樣本會存在一些特征上的相似點或者影響部分分類局部關鍵特征點,導致產生誤判、召回低,我們期望能夠通過收斂場景來做模式化的識別,提高模型準確度。
我們把場景收斂到如下三個場景:無線 C 端營銷頻道場景、小程序場景以及 PC 中后臺場景。這里面幾個場景的設計模式都有自己的特色,針對各個場景來設計垂直的識別模型可以高效地提高單一場景的識別準確度。
(D2C 場景)
3)思考與解法
總的來說,既然使用了深度模型,有一個比較現實的問題是,模型的泛化能力不夠,識別的準確率必然不能 100% 讓用戶滿意,除了能夠在后續不斷地補充這批識別不到的樣本數據外,在這之前我們能做什么?
在 D2C 的整個還原鏈路里,對于識別模型,我們還遵守一個方法論,即設計一套協議或者規則能通過其他方式來兜底深度模型的識別效果,保障在模型識別不準確的情況下用戶仍可完成訴求:手動約定 > 規則策略 > 機器學習 > 深度模型。舉個例子比如需要識別設計稿里的一個循環體:
- 初期,我們可以在設計稿里手動約定循環體的協議來達成;
- 根據圖層的上下文信息可做一些規則的判斷,來判斷是否是循環體;
- 利用機器學習的圖層特征,可嘗試做規則策略的更上游的策略優化;
- 生成循環體的一些正負樣本來通過深度模型進行學習。
其中手動約定的設計稿協議解析優先級最高,這樣也能確保后續的流程不受阻塞和錯誤識別的干擾。
imgcook x 云開發平臺
了解前端智能化和 imgcook 大致思路之后,那么為什么會選擇在云開發平臺上集成 imgcook 呢?那就是 imgcook 和云開發平臺通過彼此的打通,將能夠為雙方解決彼此的痛點,無論是為云上開發者,還是 imgcook 開發者都提供了全新的用戶體驗。
對于 imgcook 開發者來說,其中一個痛點就來自于對于設計稿的管理,以及前后端交互的邏輯,然而通過云開發平臺,開發者不再需要在本地安裝 Sketch,通過云開發平臺直接上傳設計稿即可開始生成代碼,真正做到了0成本一鍵生成。
另外云開發平臺上直接提供了Midway Serverless 框架,我們通過云開發平臺的插件定制化,可以讓開發者直接選擇某個頁面所使用的函數(Function),這樣就節省掉編寫一些前后端交互的基礎邏輯或請求代碼。
對于云開發平臺的開發者來說,最想得到的便是極速的上線體驗和更加便捷的開發體驗,imgcook 可以降低云開發平臺的使用門檻,比如一位 FaaS 應用工程師不再需要學習如何切圖,如何寫 CSS,而只需要編寫 FaaS 函數的邏輯即可,剩下的前端邏輯代碼都可以通過 imgcook 插件在開發平臺內即可完成,這是多么棒的體驗啊!
那么,接下來就看看如何快速地從0到1生成代碼吧。
首先需要先打開云開發平臺創建應用,選擇 imgcook 創建應用:
然后在應用的 WebIDE 中通過右鍵打開 imgcook 云插件,就可以正式開始使用了。
第一步,在插件中選擇“導入”,打開上傳設計稿界面:
第二步,imgcook 可視化編輯器:
第三步,生成代碼:
第四步,導出代碼到應用:
第五步,上線應用:
$ npm install $ npm run dev 正在啟動,請稍后... --------------------------------------- 開發服務器已成功啟動 請打開 >>> http://*****-3000.xide.aliyun.com/ --------------------------------------- 感謝使用 Midway Serverless,歡迎 Star! https://github.com/midwayjs/midway ---------------------------------------啟動成功后通過命令行的地址打開頁面效果如下,是不是很簡單呢?
總結
本文通過介紹前端智能化的背景,imgcook 的問題定義以及技術方案,以及如何在云開發平臺上使用 imgcook 開始智能開發,總的來說,還是希望讓業內的前端工程師們從使用 imgcook 開始,將日常工作中的一些繁瑣、耗時的工作交給 AI 來完成,這樣能關注工程師本身更感興趣,也更有價值的事情,也相信不久的將來,前端工程師將借助于 AI 能更加快樂與從容地工作!
點擊鏈接立即體驗:https://yunqi.aliyun.com/2020/hol
“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐,做最懂云原生開發者的公眾號。”
總結
以上是生活随笔為你收集整理的设计稿生成代码与 Serverless 的前世今生与未来!的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 写在 Dubbo go 的第五年
- 下一篇: 阿里巴巴成立云原生技术委员会,云原生升级