一直以來, 如何從‘視覺稿’精確的還原出 對應的UI側代碼 一直是端側開發同窗工做裏消耗比較大的部分,一方面這部分的工做 比較肯定缺乏技術深度,另外一方面視覺設計師也須要投入大量的走查時間,有大量無謂的溝通和消耗。架構
閒魚團隊 在去年作了一個很特別的黑科技 基於圖片直接翻譯成對應的UI側代碼,具體完成的部分,咱們有一個演示的視頻佈局
不少人會比較好奇,爲何我會堅持使用圖片作爲輸入源,一方面基於 sketch 或者 photoshop 等插件 相對容易拿到肯定性的信息,圖片在某些方面容易丟失一些特徵;另外基於圖片的分析其實挑戰更大。咱們作 這個選擇 有如下緣由,首先圖片做爲最終的產出物,更直觀和肯定性,另外這個鏈路裏對上游不會有約束性。最後也是最重要的一點 基於圖片的應用場景會更普適,相似場景 例如自動化測試能力的支持,基於竟品直接截圖來套用咱們本身的數據源找體感,等場景是其餘的方案作不到的。學習
上面咱們在講項目自己的意義和選型上的一些判斷,後面咱們會簡單介紹下項目的基本流程測試
首先咱們會使用深度學習的方式,來找到對應的 UI單元,包括基礎的UI組件,例如 imgview textview 等,接下來是自定義的BI組件例如 price 等, 最後咱們會尋找已經被實現過的業務組件。下面是一個 常見的業務場景,咱們框選了每一個對應的部分,演示上面的業務邏輯flex
接下來咱們會基於已經檢測出的元素,來作對應的元素提取,這個部分咱們會去分析系統渲染的原理 並使用 opencv 的方法來作對應的功能ui
項目總體的流程,咱們用下面的這個圖來表示google
在整個項目落地的過程當中,咱們遇到不少的技術困難的點,下面我會講2個有意思的點插件
第一個咱們會發現 autoui 的整個流程結構是一個很是典型的上下游的流形式,每一個關鍵的單元都會依賴上游的輸出,而且爲下游提供標準的輸入,咱們在項目的開始時候,由於沒有特別好的去定義切分的關係,常常會出現當一個同窗調整和PUSH代碼後,會對整個鏈路形成很大的影響,因此咱們對架構設計作了一個關鍵的升級咱們定義叫流式的架構,咱們用一個圖讓你們更好的來理解這一塊架構設計
在這個單元裏 咱們定義了 unti,tasks,server三個單元,unit自己是最小粒度的功能切分,tasks是unit的組合,server 會提供具體的服務,每一個部分都會爲上下游 提供輸入和輸出,架構切分的好處是,全部的模塊都有標準的輸入和輸出的部分,咱們能夠經過對模塊的MOCK來解決標準化調試的問題,另外當一些基礎的功能完成後,咱們能夠經過搭積木的方式來組合本身想要的 tasks 和 server ,在咱們作了架構調整後,由於總體的切分更合理,也減小了上下游的依賴,對項目的快速迭代產生了很大的幫助。翻譯
後續 在架構側咱們還作了一個有意思的點,由於 咱們的服務有些是須要跑在服務端,有些是須要跑在客戶端上,因此咱們設計了一個能夠在客戶端和服務端同構的場景,目的是但願開發的人員只須要關係界面和服務的通訊,但並不須要關注具體服務的部署關係
上面咱們講了一個架構的設計,後面咱們但願講一個具體的佈局問題具體解法,把靜態的DSL轉成一個合適的佈局屬性的TREE,在這個部分咱們仍是分析了能產生布局的因素,以下圖所示
這樣一個很是常見的佈局,咱們拆分出了影響佈局的部分,經過元素位置、間距、容器位置分析,咱們參考了 flex 佈局的標準,也參考了 新的 grid 的佈局標準,經過枚舉元素在位置中站位的比例,來得出對應的關係。
可是咱們最後仍是遇到一些Bad Case,如何寫出更貼近人寫出的UI側代碼,咱們仍是須要去參考相似語意的部分,類似度的部分 咱們才能獲得真正合理的佈局,例如上面的 這個例子,若是按照枚舉的佈局去推斷的話,咱們很容易獲得 一個四個橫列的佈局關係,可是經過語意和類似度的部分,咱們會很容易的推斷出一個 gridview 的佈局關係。
去年總體 咱們已經比較好的 讓整個工程在業務側 開始跑起來 開始讓你們能解放出來 作一些更須要思考的事情,並把咱們的項目 展現給了 google團隊,也獲得了不少的關注。
將來,咱們仍是但願經過更好的分析能力(包括 容器識別、複雜的背景識別、精確的語意理解能力),產生出更接近開發人員手寫的代碼,從而徹底取代 ‘切圖’ 這個工做,另外咱們也在看在這個階段咱們已經可以 讓機器來解放開發鏈路的最前面一段,後面 在一些弱交互、強展現的部分,例如導購或者營銷這樣的場景,咱們其實經過數據模型的抽象和識別、甚至固定的PRD的識別 有可能咱們是能真正的解放整段的人力投入,讓你們從偏肯定性的需求實現中解放出來。另外 咱們也開始和 D2C 這樣的項目 一塊兒共建,但願在閒魚裏已經實現的部分,可以解決更多人的問題,解放更多的生產力。
本文做者:閒魚技術-青頁
本文爲雲棲社區原創內容,未經容許不得轉載。