要 - 面向用戶的軟件開發人員通常將圖形用戶界面（GUI）的模型轉換為代碼。因為 GUI 的變化與時俱進，這個過程既發生在應用程序啟動時，也發生在演化環境中。麻煩的是，這種做法既具有挑戰性又耗時。在本文中，我們提出了一種自動化的方法通過以下三個任務實現 GUI 的準確原型制作，從而實現了這一過程：檢測，分類和組裝。一，邏輯組件使用計算機視覺技術或模型元數據從模型工件中檢測出 GUI 的數量。然后，軟件庫挖掘，自動動態分析和深度卷積神經網絡可將 GUI 組件準確分類為特定于域的類型（例如，切換按鈕）。最后，數據驅動的 K 最近鄰算法生成合適的分層 GUI 可以自動組裝原型應用程序的結構。我們在系統中為 Android 實現了這種方法稱為 ReDraw。我們的評估表明，ReDraw 的平均 GUI 組件分類精度達到 91％，并且組裝了原型應用程序，這些應用程序在視覺親和力方面緊密地鏡像目標模型，同時展示合理的代碼結構體。與行業從業人員的訪談說明了 ReDraw 在改善實際開發工作流程方面的潛力。

索引詞 - GUI，CNN，移動，原型，機器學習，挖掘軟件存儲庫。

1.簡介

大多數面向客戶的現代軟件以 GUI 為中心，依賴有吸引力的用戶界面（UI）和直觀的用戶體驗（UX）來吸引客戶，促進有效完成計算任務。麻煩或美觀的軟件令人不快的用戶界面成功的可能性很小，尤其是公司希望將自己的應用與具有類似功能的競爭對手。這種現象可以在移動應用市場中很容易觀察到作為 App Store 或 Google Play，其中許多提供類似功能的競爭應用程序（也稱為應用程序）功能（例如任務管理器，天氣應用）通過 UI/UX 來區分自己。因此，重要的是正在開發任何基于 GUI 的應用程序的第一步和原型設計模型，這有助于 UI 的實例化和實驗，以便進行評估或證明抽象設計概念。在工業環境中對于較大的團隊，此過程通常由擁有特定領域專業知識的敬業設計師使用圖像編輯軟件制作引人入勝的直觀 GUI 軟件，例如 Photoshop 或 Sketch。這些團隊是通常負責表達一致的設計語言在公司數字化業務的許多方面，包括網站，軟件應用程序和數字市場緊縮材料。此設計過程的某些組件也傾向于延續到較小的獨立發展通過創作實踐設計或原型制作流程的團隊吃線框或模型來判斷設計思路之前承諾花費發展資源實施-給他們。這些初始設計稿創建后，至關重要的是，它們如實地被翻譯成代碼讓最終用戶體驗設計和用戶界面以其預期的形式。自動化原型制作過程 GUI 是一項艱巨的任務。這個困難的核心是需要彌合巨大的抽象差距從任一像素推理出準確的用戶界面代碼基于圖形用戶界面或數字設計的圖形表示草圖。

我們提出一種方法，將原型制作過程構造為以下任務：檢測，分類和組裝。第一項任務涉及檢測-原子元素的邊界框（例如 GUI-用戶無法進一步分解的組件）實體模型設計工件（例如基于像素）的界面圖片。可以通過以下方法解決此挑戰：關于表示 GUI 組件的對象的形成直接從模型工件（例如，解析導出的元來自 Photoshop 的數據），或使用 CV 技術進行推斷對象。一旦來自設計工件的 GUI 組件已被識別，需要將其分類為特定于域的正確類型（例如，按鈕，下拉菜單，進度條）。本質上，這是圖像分類任務，并且對該主題的研究已顯示出巨大的近年來的進步，主要是由于深卷積神經網絡（CNN）。但是，由于 CNN 是一種監督式學習技術，他們通常需要大量的訓練有效數據，例如 ILSVRC 數據集。我們主張對應用程序進行自動動態分析從軟件存儲庫中提取的信息可用于收集屏幕截圖和 GUI 元數據，可用于自動最終得出帶標簽的訓練數據。使用此數據，可以有效地訓練 CNN 來對 GUI 實體模型中的組件（使用檢測到的組件進行提取邊界框）放入其特定于域的 GUI 組件類型。但是，組件的分類圖像不是足以匯編有效的 GUI 代碼。GUI 通常是在代碼中表示為層次樹，其中邏輯組組件捆綁在一起放在容器中。我們使用迭代 K 最近鄰（KNN）算法和 CV 技術在挖出的 GUI 元數據上運行，以及屏幕截圖可以構建現實的 GUI 層次結構，被翻譯成代碼。 我們已經實現了上述方法在適用于 Android 平臺的名為 ReDraw 的系統中。我們從 Google Play 提取了 8,878 個最受好評的應用，使用全自動輸入生成了這些應用程序從我們先前的工作中得出的方法（例如 GUI 抓取）關于移動測試。在自動應用程式執行期間，從每個應用程序中提取最受歡迎的屏幕瀏覽 GUI 層次結構。然后，我們在最受歡迎的原生 Android GUI 組件類型為在防雷屏上觀察到。ReDraw 使用此分類器與迭代 KNN 算法和 addi-傳統的簡歷技術來翻譯不同類型的模擬將工件放入原型 Android 應用中。我們執行了一整套三項評估 ReDraw 的研究旨在測量（i）基于 CNN 的分類的準確性-分隔符（根據基線特征描述符和基于支持向量機的技術），（ii）相似度生成的應用程序到實體模型（在視覺上和在結構上），以及（iii）的潛在工業適用性我們的系統，通過對手機進行半結構化采訪 Google，華為和 Facebook 的設計師和開發人員。我們的結果表明，我們基于 CNN 的 GUI 組件分類-sifier 的前 1 個平均精度達到 91％（即 CNN 預測的頂級類別是正確的），我們生成了應用程序與其模型具有高度的視覺相似性工件，生成的應用程序的代碼結構相似到實際應用，ReDraw 有潛力改善并促進原型開發一些實用擴展的移動應用程序。我們的評估該部分還說明了 ReDraw 如何勝過其他相關移動應用程序原型開發一些實用擴展的移動應用程序。

總而言之，我們的論文的貢獻有：

• 引入新穎的原型制作方法植根于多種技術組合的軟件 GUI 來自程序分析，MSR，ML 和 CV；和此方法在稱為的工具中的實現適用于 Android 平臺的 ReDraw；
• 對 ReDraw 的綜合經驗評估，測量以下幾個補充質量指標：與相關工作進行比較，并描述提要-從行業專家那里獲得有關其實用性的反饋；
• 在線附錄展示了以下內容的屏幕截圖：生成的應用程序并研究復制信息；
• 作為實施 ReDraw 的一部分，我們收集了大量包含以下內容的移動應用程序 GUI 數據集屏幕截圖和與 GUI 相關的元數據超過 14k 屏幕和超過 190k GUI 組件；
• ReDraw 的公開開源版本代碼，數據集和訓練有素的 ML 模型。

2.背景和問題陳述

模擬驅動開發實踐的第一個概念我們在本文中引用的是模型工件，即我們定義為：

定義 1-模擬工件：軟件的工件-標明設計準則的標志和開發過程 GUI 及其內容。

定義 2-GUI 組件：原子圖形元素具有預定義的功能，并顯示在軟件的 GUI 中軟件應用。GUI 組件具有以下幾種與域相關的組件之一類型，每種不同的類型都有不同的功能或美學目的。例如，在常見的網絡應用中組件類型包括下拉菜單和檢查盒子，僅舉幾例。

定義 3-GUI 容器：分組的邏輯結構成員 GUI 組件，通常定義空間顯示其成員的屬性。在以 GUI 為中心的現代應用中，GUI 組件很少使用預定義的坐標在屏幕上呈現。在-相反，容器的邏輯分組形成了分層結構（或 GUI 層次結構）。這些層次結構通常定義有關其組成成分的空間信息并在許多情況下會對尺寸的變化做出反應顯示區域。例如，GUI-顯示文本的組件可能會根據到其容器的尺寸。

有了這些定義，我們要解決的問題本文內容如下：

問題陳述：給定一個模型工件，生成一個打字應用程序，非常類似于模擬 GUI 在視覺上，以及在 GUI 層次結構的預期結構方面。

這個問題可以分解分為三個不同的任務，包括檢測分類和 GUI 組件的功能化，以及現實的組裝 GUI 層次結構和相關代碼。在本文的范圍內，我們專注于自動為移動應用生成 GUI 在視覺和結構上都相似（GUI 層次結構）。為此，我們調查了（i）現有應用程序；以及（ii）素描樣機反向從現有的流行應用程序設計而成。我們利用這些類型的工件作為真實模型通常不是適用于開源移動應用，因此無法在我們的研究中使用。應該注意的是兩種本文中使用的模型偽像可能無法捕獲在創建過程中創建的模型中存在某些歧義一個真正的軟件設計過程的過程。我們討論這在第二節中的含義。

3.方法描述

我們將圍繞以下內容描述我們用于 GUI 原型制作的方法：該過程分為三個主要階段：檢測，分類和部件。圖 2 說明了該過程的概述我們將在整個方法說明中參考。在高層次上，我們的方法首先檢測 GUI 組件通過使用 CV 技術或直接從生成的模型工件中解析元數據使用專業的照片編輯軟件。二，分類我們將檢測到的 GUI 組件轉換為適當的類型使用從大規模收集的 GUI 數據訓練 CNN 對提取的應用程序進行自動動態分析挖掘軟件存儲庫。經過訓練的 CNN 隨后可以應用于模型工件以對檢測到的組合進行分類要素。最后，構建合適的 GUI 層次結構（例如，GUI 容器中 GUI 組件的正確分組）我們利用了基于 KNN 的算法，該算法利用了 GUI-大規模動態分析中提取的信息組裝一個現實的 GUI 組件的嵌套層次結構和 GUI 容器。為了說明我們的一般方法，在每個階段，我們首先描述建議的方法，高層設計決策，然后討論實現具體到我們的 ReDraw 實例的詳細說明適用于 Android 平臺。

3.1 階段 1-GUI 組件的檢測

GUI 原型方法所需的第一個任務是檢測存在于實體模型中的 GUI 組件 tifact。此階段的主要目標是準確推斷原子 GUI 組件元素的邊界框（在實體模型中基于像素的坐標項）。這樣就可以將 GUI 組件的各個圖像裁剪并提取以便在以后使用原型制作過程的各個階段。此階段可以是通過以下兩種方法之一完成：（i）解析數據從模型工件中提取，或（ii）使用 CV 技術檢測 GUI 組件。在以下小節中，我們將介紹這兩種方法的檢測程序作為我們在 ReDraw 中的特定實現。

3.1.1 從設計模型中解析數據

檢測 GUI 組件的第一種方法是存在于模型工件中。鑒于 UI / UX 在當今時代的重要性面向消費者的軟件，許多設計師和小型團隊開發人員團隊進行專業級圖像編輯 Photoshop 或 Sketch 等軟件來創建 GUI 的線框或像素完美靜態圖像包含模型工件。在此過程中，編輯或設計軟件通常用于創建空白尺寸與目標設備屏幕匹配的畫布，或顯示區域（帶有一些便于縮放的設計軟件到多個屏幕尺寸）。然后，代表 GUI 組件作為可編輯對象放置在此組件的頂部畫布來構建模型。這些工具大多數是能夠以以下格式導出模型工件：編碼有關畫布上對象的空間信息，例如使用“可縮放矢量圖形（.svg）”格式或 html 輸出。有關對象布局的信息，包括這些對象的邊界框，都可以解析從這些輸出格式中獲得高度準確的結果檢測組件。因此，如果此元數據用于可用模型實體，可以對其進行解析以獲得 GUI 組件的非常精確的邊界框存在于模型工件中，然后可用于其余的原型制作過程。

給定在元數據中編碼的空間信息，有時可以在模型制品中使用，有人可能會問：該信息是否也可以用于重建 GUI 組件的分層表示，可以以后有助于代碼轉換過程。不幸，現實的 GUI 層次結構通常無法被可行地解析至少由于以下兩個原因而從此類工件中獲取：（i）設計者使用照片編輯軟件來創建模型，ups 傾向于編碼與層次結構不同的編碼由于設計師缺乏知識，開發人員會關于以編程方式的最佳方式在屏幕上排列 GUI 組件；（ii）限制在照片編輯軟件中可能會禁止創建 pro-語法正確的空間布局。因此，任何分層從此類工件中解析出來的結構很可能是特定的設計師的喜好，或根據容量限制照片編輯軟件的功能，限制了我們的原型場景。例如，設計師可能沒有提供足夠的 GUI 容器來創建有效的反應式移動版式或照片編輯軟件可能不會允許按比例縮放 GUI 組件的相對位置跨不同的屏幕尺寸。

3.1.2 使用 CV 技術進行 GUI 組件檢測

從模型中解析信息會導致高度 GUI 組件的準確邊界框此信息由于以下方面的限制，可能并非始終可用使用的照片編輯軟件或設計不同的照片實踐，例如以數字或物理方式繪制模型使用數位屏，數位板或紙。在這種情況下，偽影可能只包含一張圖片，因此 CV 技術-需要標識相關的 GUI 組件信息的工具。為了支持這些情況，我們的方法建立在中的 CV 技術來檢測 GUI 組件邊界盒子。此過程使用了一系列不同的簡歷技術（圖 2 -1）來推斷對象周圍的邊界框響應圖像中的 GUI 組件。首先，坎尼的邊緣檢測算法用于檢測邊緣圖像中的對象。然后將這些邊緣擴張合并邊緣彼此靠近。最后，那些輪廓邊用于導出原子周圍的邊界框 GUI 組件。合并基于文本的其他啟發式方法使用光學字符識別（OCR）的組件是用于合并文本的邏輯塊的邊界框（例如，與其將每個單詞都檢測為自己的組成部分，句子和文本段落合并在一起）。

3.1.3 ReDraw 實現-GUI 組件檢測

在實施 ReDraw 時，要支持以下情況：可以從適用于 Android 的模型中收集元數據我們針對使用 Marketch 創建的文物的應用程序 Sketch 的插件，可將模型導出為 html 和 javascript 的組合。素描很受歡迎在移動開發人員之間，并提供廣泛的自定義功能大型插件庫中的內容。ReDraw 解析包含在其中的 GUI 組件的邊界框導出的 Marketch 文件。支持與元數據相關的場景實體模型不可用，ReDraw 使用 CV 技術自動推斷組件的邊界框從靜態圖像。因此，GUI 的輸入-ReDraw 的組件檢測階段是屏幕-鏡頭和相應的插銷文件（3 月 ketch 解析程序已應用）或單個屏幕截圖（已應用基于 CV 的技術）。最終結果 GUI 組件檢測過程是一組邊界位于原始輸入屏幕中的框坐標-鏡頭和從原始圖像中裁剪出的圖像集合根據派生的邊界框截圖描述原子 GUI 組件。稍后將提供此信息到 CNN 中分類為 Android 特定組件階段 2.2 中的類型。請注意，只有 GUI-在此過程中檢測到組件。在另一手工 GUI 容器和相應的 GUI 層次結構在第 2 節中描述的組裝階段構造。

3.2 階段 2-GUI 組件分類

一旦原子 GUI 組件的邊界框已從實體模型工件中檢測到錯誤，下一個原型制作過程中的步驟是對裁剪后的圖片進行分類特定 GUI 組件的年齡進入其特定領域類型。為此，我們提出了一種基于數據的基于機器學習的方法利用 CNN 的方法。如該圖所示。2-2.1 和圖 2-2.2，此階段包含兩個主要部分：（i）大規模軟件資源庫挖掘和自動動態分析-sis，以及（ii）CNN 的分類訓練和應用 GUI 組件的圖像。在以下小節中我們首先討論的動機和實施之前的資源庫挖掘和動態分析過程討論使用 CNN 的基本原理以及我們的具體 ReDraw 中的體系結構和實現。

3.2.1 2.1 階段-大規模軟件存儲庫挖掘和動態分析

鑒于其受監管的性質和深入的架構，CNN 針對圖像分類任務需要大量訓練數據以實現精確分類。訓練傳統 CNN 圖像分類網絡的數據典型 ic 由大量標有它們的圖像組成對應的類別，其中標簽對應于優先級圖像中的瑪麗主題。傳統上，此類數據集具有人工采購，其中人類費力地標記數據集中的每個圖像。但是，我們建議自動創建標簽火車的方法包含特定 GUI 組件的圖像的數據從完整的屏幕截圖和對應的標簽中裁剪其特定于域的類型（例如，按鈕或微調框 Android）使用全自動動態程序分析。我們對自動化動態分析的關鍵見解過程如下：在自動探索軟從大型存儲庫，平臺特定框架中挖掘的軟件可以用來提取描述 GUI 的元數據，然后可以將其轉換為適合的大標簽訓練集 CNN。如圖 2- 2.1 所示，此過程可以通過挖掘軟件倉庫自動提取可執行文件。然后進行大量有關自動輸入的研究可以使用基于 GUI 的應用程序測試生成通過模擬用戶自動執行挖掘的應用程序-輸入。例如，如果目標是移動應用，則輸入生成技術依賴于基于隨機的策略可以用于此任務。作為應用程序執行后，屏幕截圖和與 GUI 相關的元數據可以為每個觀察到的獨特屏幕自動提取或應用布局。其他類似的自動 GUI 翻錄或爬網方法也可以適用于其他平臺例如網絡。可以使用第三方軟件捕獲屏幕截圖或目標操作系統隨附的實用程序。圖形用戶界面可以從各種來源收集相關的元數據包括可訪問性服務，html DOM 信息-或 UI 框架（例如 uiautomator）。的然后可以使用 GUI 元數據和屏幕截圖提取 GUI 組件的子圖像及其標記的類型從描述每個屏幕的相關元數據中解析。結果數據集的基礎質量與標簽如何很好地描述了 GUI 組件的類型顯示在屏幕上。鑒于許多軟件 UI 框架，可用于挖掘此類數據直接從呈現工具中提取信息屏幕上的應用程序 GUI 組件，此信息可能非常準確。但是，有一些從這些框架中收集信息的情況-作品包含輕微的錯誤或無關的情況。我們討論這些情況和可采取的緩解措施他們在 3.2.4 節。

3.2.2 ReDraw 實施-軟件存儲庫-和自動化動態分析

采購大量 Android 應用來構建我們的我們開采的 CNN 的培訓，驗證和測試語料庫 Google Play 上的免費應用程序。為確保代表提取的應用的情感性和質量，我們提取了截至 2017 年 6 月 Google Play 商店中的所有類別。然后，我們篩選出主要包含游戲，因為游戲傾向于使用非標準類型的 GUI，無法自動提取的組件。這個離開我們共有 39 個類別。然后，我們使用了 Google PlayAPI 庫，可從每個庫下載前 240 個 APK 類別，不包括一個以上存在的重復項類別。這導致了總共 8,878 獨特的 APK 之后解釋跨類別交叉列出的重復項。

要從挖出的 APK 中提取信息，我們會補充了一個大型動態分析引擎，稱為使用系統自動化的執行引擎基于我們先前工作的輸入生成方法 CRASHSCOPE 和 MONKEYLAB 至充實應用程序并提取屏幕截圖和與 GUI 相關的內容有關已訪問屏幕的信息。更具體地說，我們的系統 GUI 探索在以下位置導航目標應用程序的 GUI 以深度優先搜索（DFS）的方式鍛煉可輕敲的內容，可長時間敲擊且可鍵入（例如，能夠接受文本輸入）組件。在系統的探索中，我們使用 Android 的 uiautomator 框架提取與 GUI 相關的信息作為描述層次結構的 xml 文件以及給定顯示的組件的各種屬性屏幕。我們使用 Android screencap 實用程序來收集屏幕截圖。該 uiautomator XML 文件包含各種顯示的每個 GUI 組件的屬性和屬性在 Android 應用程序屏幕上（包括邊界）框（例如，屏幕內的精確位置和區域）和組件類型（例如 EditText，ToggleButton）。這些屬性可為每個 GUI-提供單獨的子圖像顯示在給定屏幕上的要從中提取的組件相應的屏幕截圖并自動標記為帶有適當的類型。

DFS 探索策略的實施利用狀態機模型，其中考慮了狀態唯一的應用程序屏幕，如其活動名稱所示并使用以下命令提取顯示的窗口（例如，對話框）在 ADB 殼 dumpsys 窗口命令。考慮到超過 8.8k 個應用中可行的執行時間我們的數據集，同時仍在探索幾個應用程序屏幕，我們將我們的勘探策略限制為每次執行 50 次操作應用程式。先前的研究表明，大多數自動輸入 Android 的生成方法趨于達到峰值覆蓋率（例如，約 20％到 40％的語句覆蓋率）經過 5 分鐘的探索。而不同的輸入生成方法往往表現出不同的數量給定時間單位的操作數，我們過去的工作表明我們的自動輸入生成方法可以實現有競爭力的覆蓋率，以及我們的規定每次 50 次動作的舒適時間超過 5 分鐘應用程式。此外，我們的目標是進行大規模分析不是要完全探索每個應用程序，而是確保各種屏幕和 GUI 組件類型。對于每個應用程序，執行引擎提取 uiautomator 前六個唯一屏幕的文件和屏幕快照對每個應用程序的屏幕數量參觀了。如果給定的數量少于六個屏幕應用程序，然后收集所有屏幕的信息。我們的大型執行引擎以并行方式運行，中央調度員向工人分配工作的地方，每個工作人員都連接到一個物理 Nexus 7 的地方平板電腦，負責協調執行傳入的工作。在動態分析過程中，每個工作包括系統地執行來自我們的數據集。當工人完成工作后，通知調度員，調度員又分配新的工作。此過程在 5 名工人上并行進行，直到所有我們已經研究了數據集中的應用程序。由于廣告在免費應用程序中很受歡迎，通常是動態 WebView 而非本機組件組成，我們使用 Xposed 來阻止應用中的廣告使其他類型的本機組件模糊。

3.2.3 2.2 階段-GUI 組件的 CNN 分類

收集了標記的訓練數據集后，我們需要訓練一種機器學習方法來提取顯著特征從 GUI 組件圖像中進行分類基于這些提取特征的圖像。去完成我們的方法利用了 CNN 的最新進展。的與其他圖像分類相比，CNN 的主要優勢方法是該架構允許自動執行從圖像數據中提取抽象特征的逼近非線性關系的應用原理數據局部性和端到端可訓練的分類建筑。

3.2.4 ReDraw 實現-CNN 分類器

一旦目標實體模型中的 GUI 組件具有使用模型元數據或基于 CV 進行檢測技術，ReDraw 必須有效地將這些組合陣營。為此，ReDraw 實施了 CNN 將 GUI 組件的目標圖像分類為觀察到的 15 種最受歡迎的組件之一在我們的數據集中。在本小節中，我們首先描述數據-用于生成培訓，驗證和測試數據集（示例如圖 4 所示）在描述我們的 CNN 架構和培訓之前我們采用的程序。

數據清理：我們實施了多種類型的預備降低噪音的處理和濾波技術。更多具體來說，我們在三個階段實施了過濾流程不同的粒度級別：（i）應用程序，（ii）屏幕和（iii）GUI 組件級別。

3.3 階段 3-應用程序組裝

原型制作過程的最后任務是組裝應用程序 GUI 代碼，包括三個階段：（i）建立適當的組件和容器層次結構，（ii）從目標實體模型推斷出樣式細節，（iii）組裝應用程序。

3.3.1 推導 GUI 層次結構

為了從的分類集合中推斷出現實的層次結構組件，我們的方法利用了 KNN 技術（方法 1）用于構建 GUI 層次結構。該算法采用表示檢測到的和分類的 GUI 組件的集合作為單個級別樹（InputNodes）中的節點作為輸入。然后，對于我們從自動化收集的數據集中的每個屏幕動態分析，Alg。1 次首先提取一組 TargetNodes 的對應于 InputNodes，它們是算法第一次通過的葉節點里特姆。接下來，將 InputNodes 與每個使用基于以下內容的相似性指標提取（TargetNodes）屏幕所占據的屏幕區域的并集交集（IOU）重疊成分（ALG 的邊界框。1 -line5）。通過選擇一個匹配的屏幕 InputNodes 之間的最高 IOU 組合得分最高和 TargetNodes。然后，父容器組件

3.3.2 推斷樣式并組裝目標應用

為了從模型中推斷出樣式細節，我們的方法采用色彩量化（CQ）的 CV 技術，和顏色直方圖分析（CHA）。對于 GUI 組件其類型不表示他們正在顯示圖像，我們的方法量化了每個圖像的顏色值像素并構建顏色直方圖。最受歡迎顏色值可用于通知樣式屬性生成代碼時的組件。例如，對于顯示文本的組件，最流行的顏色可以是用作背景和第二最普遍的顏色可以用于字體。

3.3.3 ReDraw 實施-App AssemblyReDraw 使用 KNN 組裝 Android 應用程序 GUI 層次結構構建方法（請參見第 3.3.1 節）和基于 CV 的顏色樣式檢測。輸入到 Alg。1 是來自 CNN 的一組分類的“葉節點”組件，以及輸出為 GUI 層次結構。為提供足夠的數據 KNN 算法，一個語料庫，包括來自從中挖掘的 GUI 層次結構的“清理”屏幕我們構建了大規模的動態分析過程。這個語料庫形成 InputNode 到的數據集 TargetNodes 組件在層次結構構建期間匹配 tion。KNN 為目標生成的 GUI 層次結構然后使用“葉節點”組件來推斷風格細節來自原始的模型工件。更具體地說，每個組件和容器，我們執行 CQ 和 CHA 提取每種成分的主色。對于有文字元素的組件，我們將光學使用開源 Tesseract 進行字符識別（OCR）在原始屏幕快照庫中獲取字符串。

4 實驗結果

4.1 RQ1 結果：CNN 的有效性

ReDraw 基于 CNN 的 GUI 組件分類器能夠獲得較高的平均精度（91%），并優于基線 BOVW 方法的平均精度（65%）。

4.2 RQ2 結果：層次結構構建

ReDraw-Mock Up 能夠生成與真實層次結構相似的 GUI 層次結構，而不是 REMAUI 或 pix2code。這一信號，重新繪制的層次結構可以被開發人員使用的低努力。

4.3 RQ3 結果：視覺相似度

與目標截圖相比，ReDraw 生成的應用程序具有很高的視覺相似性。

4.4 RQ4 結果：工業適用性

ReDraw 有望應用于工業設計和開發工作流程，特別是在進化環境中。然而，模塑最有可能是必須作出適合具體工作流程和原型工具鏈。

致謝

本文由南京大學軟件學院 iSE 實驗室 2020 級碩士研究生張晶翻譯轉述。

者：林間有影落

作為設計師，一個老生常談的話題就是還原度檢查。

還原度檢查：也叫還原度驗證、設計走查、設計驗證。是保證研發實際實現的效果是否和設計稿一致的過程。

借一位建筑設計師寫的話來說，“畫一張效果圖很容易，但項目得以高完成度的還原卻很難。” 如果你的設計不是僅僅停留在紙面，那你就需要面臨最終的設計還原度問題。

在進行還原度檢查中，你是否有聽到過這樣的話：

“我這樣實現也行吧，我覺得比你設計還好點。”
“這里還不對嗎？我已經改了好幾遍了……“
“項目時間太緊了，我們先實現功能吧。”
“不就幾個像素嗎？差不多行了。”
“我覺得是一樣的，你行你上？”

……

這些其實并不是個例。

在設計還原度檢查的過程中，我們常常會遇到這樣或那樣的問題，令這個過程耗費精力無數，最終收效卻并不大。聽聞一位設計師說他們某個項目，最終耗費了 30 人/天的時間去做還原度驗證。

設計的項目還原度如何，是每一位設計師成長的必經之路，也是設計師能力的一種重要體現。說到這里，你可能有點疑問，明明是研發實現的問題，怎么成了能衡量設計師能力的一種體現呢？

誠然，在同等條件下，優秀的研發工程師能夠憑借自身實力和豐富經驗實現更高程度的設計稿還原，同樣的，優秀的設計師也可以憑借著自身實力和豐富經驗，保證自己的設計稿具有更高的還原度，這是一個相互影響的過程。

所以，本質上，設計還原度，還是一個合作問題。

而 B 端+AR，其本質也是一樣，是建立在設計還原度檢查的通用場景上的一個特殊場景。接下來的文章，我分五個部分來進行說明。

要檢查的內容都有哪些呢？

我認為，整個設計還原度檢查可以分為三個部分：

1. 交互內容

交互內容緊扣功能，但和測試不同，主要是以用戶的使用流程來檢查相應功能下的交互邏輯是否完整實現，反饋和提示是否有遺漏，使用時的合理性和可用性是否與設計初衷一致。

AR 中還應多關注各種交互轉換中的相對參照分類是否正確。

2. 視覺內容

前端頁面的靜態效果是否和設計稿一致，包括色彩、布局、排版等細節，這塊內容一直是研發和設計難以達成一致的重災區。

在 AR 應用中，還要包括三維內容的大小、材質等細節。

3. 整體體驗

AR 設計是虛實結合的設計，我們實際設計時雖然只能著眼于虛擬元素，但用戶所體驗到的是結合真實環境的虛實結合界面，所以特定環境下的整體體驗檢查也是必要的。

我做的項目由于一般是一整套系統，通常存在多個終端數據聯動，比如 web 平臺和 AR 應用的聯動，那它們之間的交互是否符合設計需求，是否有遺漏和錯誤，也屬于整體體驗的檢查內容。

什么時候做還原度檢查最適合呢？

為了效率最大化，我推薦是產品提測后再進行設計還原度檢查，如有條件，最好在測試團隊完成第一輪功能測試后再介入。
原因有三個：

• 第一，一般功能性的 bug 會更為緊急，因為它大多會導致產品在該功能上存在完全不可用的狀態，這個時候就算設計師介入去做還原度檢查，也很難檢查到設計本身的問題。
• 第二，在改動功能型 bug 的時候，會使某些已經修改的還原度問題復現，加重了反復查驗的工作量。
• 第三，一些很明顯的交互和視覺問題，其實測試團隊是能夠幫忙測出來的。

檢查到什么程度？

這個其實沒有非常硬性的標準，不同公司、不同項目、不同設計師都可能不一樣。有的認為 95%以上還原度才能達到標準，有的認為 90%甚至 80%就算達到標準。

一般來說，還原度標準：C 端＞B 端＞后臺。

而 AR 應用的還原度即使在 B 端，也應該大于通常的 B 端應用，因為在當前技術水平下，許多 AR 應用首要滿足的是展示目的，交互和視覺的最終效果是非常關鍵的。

常見問題？

在設計還原度檢查中，我們常常遇到這樣或那樣的問題，歸納起來，有下面幾點。

1. 設計輸出有缺失

輸出的缺失主要體現在兩個方面，是一個是內容本身的缺失，一個是附加說明的缺失。

內容本身的缺失，指設計輸出里缺少某些細節交互的說明，界面不同狀態的展示，不同狀態的按鈕或圖標切圖，動效說明等。這個可以靠設計師的細心和對設計的自查來避免。

附加說明的缺失，主要是標注的問題。隨著行業的發展，現在已經有很多自動標注和切圖工具了，但正因為如此，反而容易因為懶，缺失很多需要手動補充的信息標注。

2. 設計處理不規范

設計處理不規范，主要是指自由發揮，完全不考慮研發的實現難度和整個項目的目標。有些設計稿乍一看質量上乘，如果作為停留在紙面上的作品甚至相當優秀，但是 UX 設計畢竟不是純藝術，而是用來解決問題的方案，需要掌握平衡。

3. 研發沒有理解設計的邏輯

由于每個人的角度不一樣，即使輸出的設計文檔在設計師眼里看起來再詳盡，在研發人員的理解下也可能完全不一樣。

4. 研發和設計師優先級認知不一致

如果說沒有理解帶來的現象是研發工程師認真的做了，但沒有做對。那這一點帶來的現象就是他明明可以做好，卻總是不好好做。也就是我們常常吐槽的研發人員“不配合”。這里的不配合，其實就是兩方在優先級認知上不一致，你提出的還原度問題，他覺得沒什么關系。既然無關重要，何必浪費精力？畢竟，哪個研發工程師身上不背幾個 bug。

5. 還原度檢查不完整

該檢查的內容沒有檢查到。原因可能有自己的，也可能有外部的。比如在 AR 設計中，我們經常會遇到很難完美復現 AR 應用真實環境的問題。又比如在某個 To B 項目中，由于 web 平臺的聯動終端是機器人，我很難在某些與機器人強聯動的界面上進行整體的體驗檢查。

怎么做得更好呢？

為了有效保證還原度，我們可以做的事情有很多，我總結了 7 點：

1. 重視設計規范

第一、有規范。第二、符合規范。

有規范，指整個設計有自己的規范定義，同類的元素使用相同的規范來呈現，具有一致性的間距、大小、色值設定等。比如同樣表示“可用”/”不可用“的標簽，在所有的界面，都應該是一致的視覺元素，包括樣式、顏色、文字、間距、大小等。

符合規范，指符合研發語言的基本規范定義，比如可行情況下盡量使用該語言下的常用標準框架，定義最小單元網格（一般 4px，6px，8px 等），切圖或間距等盡量以此為倍數；不要出現奇數等。這些都可以提高研發的效率。

設計規范的好壞，直接影響到后面的設計宣講和設計輸出的好壞。

2. 了解開發思維

了解開發的思維，在做設計稿的時候就可以換個角度看問題，足以讓自己在后面的還原度檢查中更省心省事。

首先是最簡單的盒子模型。

盒子模型是 CSS 語言中的術語， 又稱框模型 (Box Model) ，所有 HTML 元素可以看作盒子，是用來設計和布局時使用。CSS 盒模型本質上是一個盒子，封裝周圍的 HTML 元素，它包括：邊距，邊框，填充，和實際內容。 盒模型允許我們在其它元素和周圍元素邊框之間的空間放置元素。

圖片來自網絡

然后是 AR 設計中常用的 U3D 工具。這款工具可以使用多種語言來開發，它的布局可以分為三種方式：固定像素、根據屏幕大小進行縮放、固定物理距離。

固定像素，忽略屏幕的大小根據 UI 元素的實際像素顯示 ，像素大小始終不變，即一個 100×100 的圖片在任何的分辨率下都占用 100×100 的像素。一般 PC 上會使用這種方式，因為 PC 端分辨率差異并不大。

根據屏幕大小進行縮放，是研發最常用的一種，會根據設備真實分辨率與設計分辨率來對 Canvas 進行縮放。有三種模式：

1. Match Width or Height
2. Expand
3. Shrink

固定物理距離，忽略屏幕大小和分辨率根據 UI 的實際物理大小來顯示。

3. 宣講設計邏輯。

不管是和設計評審一起還是私下對接研發，都要對自己的設計邏輯和輸出內容做講解，講解的內容包括：通用的設計規范、資源圖的命名規則、特別事項的注意等等。

講解的目的就是讓他理解你的設計邏輯。

通過講解，研發人員明白這些設計的內在意義，知道為什么要這樣做，才能夠幫你把設計實現得更好。同樣，宣講設計邏輯的時候一定要要求具體的研發工程師到場，這會提高后面一系列工作的效率。

想一想，當你把自己辛辛苦苦，連幾個像素一點點色差都要糾結半天作品托付給另外一個人，不該囑咐囑咐幾句：“親～這非常重要，值得你好好對待。”

4. 完善設計輸出

完整的設計輸出，應該包含承接產品需求文檔的交互說明、視覺說明（含標注）和相關資源。

交互說明，應該寫明可點擊部分跳轉的界面，不同狀態下的中間過程，特殊情況下的界面處理等等。

視覺說明，應該包含對規范的說明和幫助研發實現界面的標注。

（1）規范的說明，需要設計師梳理通用的內容，讓工程師對項目的前端界面樣式有個整體了解，快速查找和定位到具體頁面的基礎樣式（如：標準色、標準字、按鈕等），也可以讓研發工程師清楚的知道哪些內容我只要兢兢業業的調一遍，就可以復制到其他地方了。

AR 應用主要使用 U3D 研發，不像普通的屏幕 UI 有諸如藍湖、摹客、marketch 這些標注工具自動翻譯，我所遇到的工程師大多傾向于把設計師的效果圖放到正視圖下的狀態，再用切圖的元素一個個界面拼出來，如果研發能知道有些界面通用一套“拼圖法則”，那會省事很多。

（2）標注部分，除了交給自動標注軟件標注的部分，還應該將無法自動標注出來的內容通過手動標注補齊，這些內容包括但不限于：

• 動態內容的標注

圖片來源： https://juejin.cn/post/6844903712331137037 ??微信小程序規范V1.0

比如：絕對位置和相對位置的注明。

上面這張圖，A 類標注就可以用自動標注精確到像素完成，而 B 的標注因為不同屏幕大小不同，其實只要保證兩個 B 相等就可以，那這里就需要手動注明了。

在 AR 應用中，由于涉及到三維空間，相對參考物尤為重要，首先要保證研發知曉當前界面里每個元素的參照對象（關于 AR 界面按參照物的分類），然后，再按照百分比來進行標注。

當然，也可以更為精確的使用當前 Z 軸下的物理尺寸來進行標注，但需要一些轉換會比較難以把握。標注的這個部分，是和了解開發思維相輔相成的，當你了解開發思維后，就能夠標注出更符合研發人員要求的說明。

相關資源，是指研發所需要的視覺元素資源。相關資源按照一定的規范命名，方便研發人員查找使用。

值得注意的是，在 AR 應用的設計中，視覺不僅僅指二維視覺（GUI）的說明和相關資源，還應該包括三維視覺內容的必要說明和相關資源。為了更好的模擬實際研發后的效果，盡量還原用戶可見界面，推薦在視覺設計輸出時添加環境照片。

設計輸出是設計體現的書面形式，是整個設計交付非常重要的一環。好的設計輸出讓你交付研發時可以放心大膽的說一句：“親～你還有不懂的可以看文檔哦，別有事沒事都來煩我如果有問題可以再找我。”

5. 了解檢查目標

前面我們說過，還原度驗證的標準一般 C 端大于 B 端大于內部后臺，AR 應用由于其特殊性，即使交付 B 端的 AR 應用也一般要高于普通 B 端的還原驗收標準，在此基礎上，可以根據項目公司業務和項目實際情況來確定一個基準。

分清輕重緩急，避免體驗問題被擱置，或者好改的體驗問題被改了，而比較重要的體驗問題，反而因為不好改反而遺留下來。

圖片來源： https://www.shangyexinzhi.com/article/4211627.html

6. 選用合適工具

現在市面上已經有一些工具幫助設計師進行還原度檢查，這里簡單的舉例 2 個。

Css Peeper： https://csspeeper.com/

它比瀏覽器自帶的 Css 代碼檢查更適合設計師，不僅可以看到元素的常規屬性，比如顏色、背景、間距；還可以看到元素的盒子模型，可以看到元素的 Padding、Margin…

Copiexl： https://copixel.bytedance.com/

字節出品的一款走查插件。

通過在網頁上放置設計稿圖片檢查設計稿與開發結果是否完全重疊來判斷開發的還原精度，精確到像素實現高質量的項目還原效果。

7. 記錄總結情況

在項目發布之前，很多情況下體驗問題可能得不到全部解決，這個時候，總結現有的設計還原程度，明晰重點問題及可能產生的體驗風險，能夠幫助整個項目快速了解現狀，決策任務優先級。對于其他遺留的問題，也能夠有機會進入下一輪迭代中。

· · ·

還原度的本質是一個合作問題，只有設計質量硬，配套產品全，在與研發合作的過程中活用我們的用戶思維，才能讓我們的設計作品得到更高的還原度。

注：本文來源于網絡，如有侵權請及時聯系我們。