一直以來， 如何從‘視覺稿’精確的還原出 對應的UI側程式碼 一直是端側開發同學工作裡消耗比較大的部分，一方面這部分的工作 比較確定缺少技術深度，另一方面視覺設計師也需要投入大量的走查時間，有大量無謂的溝通和消耗。

閒魚團隊 在去年做了一個很特別的黑科技 基於圖片直接翻譯成對應的UI側程式碼，具體完成的部分，我們有一個演示的視訊

很多人會比較好奇，為什麼我會堅持使用圖片做為輸入源，一方面基於 sketch 或者 photoshop 等外掛 相對容易拿到確定性的資訊，圖片在某些方面容易丟失一些特徵；另外基於圖片的分析其實挑戰更大。我們做 這個選擇 有以下原因，首先圖片作為最終的產出物，更直觀和確定性，另外這個鏈路裡對上游不會有約束性。最後也是最重要的一點 基於圖片的應用場景會更普適，類似場景 例如自動化測試能力的支援，基於竟品直接截圖來套用我們自己的資料來源找體感，等場景是其他的方案做不到的。

上面我們在講專案本身的意義和選型上的一些判斷，後面我們會簡單介紹下專案的基本流程

首先我們會使用深度學習的方式，來找到對應的 UI單元，包括基礎的UI元件，例如 imgview textview 等，接下來是自定義的BI元件例如 price 等， 最後我們會尋找已經被實現過的業務元件。下面是一個 常見的業務場景，我們框選了每個對應的部分，演示上面的業務邏輯

接下來我們會基於已經檢測出的元素，來做對應的元素提取，這個部分我們會去分析系統渲染的原理 並使用 opencv 的方法來做對應的功能

專案整體的流程，我們用下面的這個圖來表示

在整個專案落地的過程中，我們遇到很多的技術困難的點，下面我會講2個有意思的點

第一個我們會發現 autoui 的整個流程結構是一個非常典型的上下游的流形式，每個關鍵的單元都會依賴上游的輸出，並且為下游提供標準的輸入，我們在專案的開始時候，因為沒有特別好的去定義切分的關係，經常會出現當一個同學調整和PUSH程式碼後，會對整個鏈路造成很大的影響，所以我們對架構設計做了一個關鍵的升級我們定義叫流式的架構，我們用一個圖讓大家更好的來理解這一塊

在這個單元裡 我們定義了 unti,tasks,server三個單元，unit本身是最小粒度的功能切分，tasks是unit的組合，server 會提供具體的服務，每個部分都會為上下游 提供輸入和輸出，架構切分的好處是，所有的模組都有標準的輸入和輸出的部分，我們可以通過對模組的MOCK來解決標準化除錯的問題，另外當一些基礎的功能完成後，我們可以通過搭積木的方式來組合自己想要的 tasks 和 server ，在我們做了架構調整後，因為整體的切分更合理，也減少了上下游的依賴，對專案的快速迭代產生了很大的幫助。

後續 在架構側我們還做了一個有意思的點，因為 我們的服務有些是需要跑在服務端，有些是需要跑在客戶端上，所以我們設計了一個可以在客戶端和服務端同構的場景，目的是希望開發的人員只需要關係介面和服務的通訊，但並不需要關注具體服務的部署關係

上面我們講了一個架構的設計，後面我們希望講一個具體的佈局問題具體解法，把靜態的DSL轉成一個合適的佈局屬性的TREE，在這個部分我們還是分析了能產生布局的因素，如下圖所示

這樣一個非常常見的佈局，我們拆分出了影響佈局的部分，通過元素位置、間距、容器位置分析，我們參考了 flex 佈局的標準，也參考了 新的 grid 的佈局標準，通過列舉元素在位置中站位的比例，來得出對應的關係。

但是我們最後還是遇到一些Bad Case，如何寫出更貼近人寫出的UI側程式碼，我們還是需要去參考類似語意的部分，相似度的部分 我們才能得到真正合理的佈局，例如上面的 這個例子，如果按照列舉的佈局去推斷的話，我們很容易得到 一個四個橫列的佈局關係，但是通過語意和相似度的部分，我們會很容易的推斷出一個 gridview 的佈局關係。

去年整體 我們已經比較好的 讓整個工程在業務側 開始跑起來 開始讓大家能解放出來 做一些更需要思考的事情，並把我們的專案 展示給了 google團隊，也得到了很多的關注。

未來，我們還是希望通過更好的分析能力（包括 容器識別、複雜的背景識別、精確的語意理解能力），產生出更接近開發人員手寫的程式碼，從而完全取代 ‘切圖’ 這個工作，另外我們也在看在這個階段我們已經能夠 讓機器來解放開發鏈路的最前面一段，後面 在一些弱互動、強展示的部分，例如導購或者營銷這樣的場景，我們其實通過資料模型的抽象和識別、甚至固定的PRD的識別 有可能我們是能真正的解放整段的人力投入，讓大家從偏確定性的需求實現中解放出來。另外 我們也開始和 D2C 這樣的專案 一起共建，希望在閒魚裡已經實現的部分，能夠解決更多人的問題，解放更多的生產力。

本文作者：閒魚技術-青頁

原文連結

本文為雲棲社群原創內容，未經