使用TensorFlow搭建智能開發系統，自動生成App UI代碼

首先，我們作為一個移動平台產品，必須解決的是讓工程師更加容易的開展工作，「知識工作者智能化」是我們探索的方向，讓移動開發工程師先用起AI，也是我們的期望。

針對我們的移動開發工程師，我們的主要的工作概括說有三件事：

了解需求

拿到UI設計

研發

我們期望的是，基於機器學習（ML）的移動平台，最終能夠：

讓初級開發人員具備專家80%的能力

讓AI輔助移動App的研發工作。

對於AI，BAT有著不同的看法，馬雲的數據論，李彥宏的技術論，以及馬化騰的場景論，我個人馬化騰的論調跟我們不謀而合，我們認為切入點很重要。

我們的切入點是：從設計稿（或者App 截圖）到App 前端代碼，這也是我今天分享的方向。

二、我們的初級探索與建議

為了，我們在實踐的前期，進行了一些探索並總結了一些建議，希望能夠給大家一些啟發。

正如大家所知道的基於機器學習工程話的過程，需要數據、演算法、算力以及工程話的配合，是一個不小的工程，我們的初步想法，是否借力SaaS的服務能力，於是我們進行了公有雲服務的嘗試。

我們找了一張狗狗的圖，實際的效果非常的贊。

準確識別狗，並且能夠識別到品種；（潛台詞：能夠識別不同設計就好了）

有「鼻子」有眼的，看上去很美，（潛台詞：能夠識別設計里的UI控制項就夠了）

於是，我們抱有很大期望的用設計稿作為嘗試，效果大致如下：

實際上效果如上圖，無法準確的認知這是一個設計圖，更不用說是什麼類型的UI以及UI內有哪些控制項，於是我們嘗試了另外一家。

實際上效果，依舊無法使用。

經過公有雲不成功的嘗試我們總結了一下的結論：

於是，我們進行了私有雲的建設，使用了已有的模型。

普遍的目標檢測都是無嵌套結構的認知

而App 的UI是一個結構化數據，存在嵌套關係、層級關係

上圖中的目標檢測對於生成代碼沒有任何幫助

三、智能開發系統的自建之路

於是我們走向了智能開發系統的自建之路

在前期的初級探索中，我們已經非常明確的知道：訓練的方向，決定了結果。而我們的方式是：

專註：訓練一個只懂移動UI的程序員

學習移動App UI 的設計稿或者截圖

不學習Web UI 或者GUI的設計稿

堅決不學習常規事物 

上面的原則主要的目標是為了訓練的專註性，我們調戲一把。

同樣的這隻狗，在公有雲的服務中都能夠準確的認知，而我們的系統把它當成了歡迎頁（0.72）而不是狗。

來看一小段視頻：

視頻說明：

右二窗口：是設計稿或者截圖（支持：jpg、PNG等常見格式）

左上窗口：以命令行式的方式觸發智能開發系統

左下窗口：普元移動平台的IDE，生成的代碼會自動同步到IDE中。

右一窗口：手機實時投屏，生成的代碼運行的效果將會在這裡呈現

大致效果已經看到了，我們如何針對這個系統進行自建的呢？

既然為工程師服務，我們先回頭看一下，工程師一般是如何工作的吧。

拿到設計，先判斷一下是個什麼類型界面

大概由幾部分組成，什麼都有哪些控制項

編寫代碼

微調代碼，調試，根據與設計圖的差距進行調整

針對第一步，我們可以採用分類的方式，確定界面類型。

這裡主要採用的演算法是CNN+softmax

大致的效果如下：

在分類上我們的一些工作主要有以下的內容：

遷移學習 CNN（Inception V3 or VGG 16）：模型微調，應用到我們的數據集上

分類器的選擇：Softmax更適合，放棄Logistic

數據集：數據集的積累，並考慮結構的依賴，大量引入灰度圖片

應用：採用原色及灰度兩種，二者取其高

低概率：引入人工干預，每個使用者都是監督者

閉環：數據集及分類的積累

其中遷移學習重要採用的是基於已有的CNN網路，微調數據模型，應用到我們的數據集上，我們嘗試過Inception V3 和 VGG 16，效果都還不錯。具體的工作如下：

選用CNN模型，前面各層的參數都不變，而只訓練最後一層。

將自己的訓練集中的每張圖像輸入到CNN網路中，得到2048個維度的向量特徵。

利用這些特徵來訓練softmax的多分類器

關於數據集的準備，必須為是基於移動的UI或者設計，這樣才能保證訓練后的方向和效果。

這裡通過移動平台在各個項目組的實施，收集到各類移動界面圖片，我們利用這些圖片作為移動的數據集。

在數據集的訓練中，我們發現，針對在很多分類下，色彩可能是一種干擾，而有些分類下，色彩卻對特徵值影響很大，所以我們採用了同源灰圖訓練，以提高正確率。

通過上圖，可以看出，結合同源灰圖，這個UI的識別率從0.748上升到0.911。究其原因，對於有些UI的分類，結構比色彩更重要。

為此，在應用過程中，在使用者上傳了一張設計圖的時候，我們將會處理成一張原圖、一張灰圖，進行分類，並選取較高概率的使用。

當然並不是所有的，我們都會有高命中，在無法準確判斷分類的時候，我們會讓「每一個使用者都成為機器學習的監督者」，讓使用者自行選擇適合的分類，如下圖所示：

比如有的個人設置的UI，系統會在List 和Setting 兩個分類上糾結不止，那就讓使用者協助我們做個選擇，這樣我們就將數據加入到數據集上，讓系統能夠更加準確的進行。我們稱之為閉環。

閉環更為重要的是，當我們能夠發現分類的不足，讓用戶自行創建分類。

對於設計稿中的UI控制項，其自身特點是嵌套的，為此我們採用多級目標檢測的方式，確定其UI類型以及層次關係。

主要的演算法採用的是Faster-RCNN，除了效果外，採用Faster-RCNN的原因是算力問題，這個演算法在RCNN里，算是比較高效的了。 以下為監測效果：

可以看出通過訓練后的目標檢測，已經能夠相對較為準確的識別。

左圖是微信里的AED分佈（推廣一下，這個對於急救非常重要，建議大家都可以了解一下）的截圖 。

右圖是採用了一個設計圖 。在上圖中不僅僅包括目標檢測后的常規結果，我們還將坐標輸出，這為後續代碼生成時候的布局非常重要。

在目標檢測上我們做了以下的一些工作。

多級Faster-RCNN，避免單一的Faster-RCNN導致目標檢測結果

疊加閥門（0.8）控制退出，組件優先。

加大數據集的積累，避免天窗效果（傳統的目標檢測沒有這個問題）。

參數的調整：eg. ANCHOR_SCALES（無須太小） 、BATCH_SIZE（與數據集數量匹配，不易過大過小）、RPN_NMS_THRSH（模型訓練越好，越可以提高，但不易過高）等等

這裡需要說明一下什麼叫做天窗效果，就是說，在整個設計圖中我們有一部分的UI區域，沒有識別出來。我們採用的方式是通過其他識別出來的區域，計算出相關區域的位置及大小，留好相關的空間，具體可以參照視頻中第三個例子。

在代碼生成部分，我們採用了基於DSL語言，生成的方式，主要考慮的因素有一下三點，第四點是一個小tips。

我們先看一下，原生語言的代碼複雜度吧。

為了實現這個設計圖，如果採用未經封裝的原生代碼，大概需要幾百行代碼，你可以自己看一下右圖最右側的滾動狀態就知道。

所以，我們採用了我們普元移動平台的DSL層進行生成，實際上大概一兩屏的代碼就可以了。具體可以參見視頻中的第二個例子。

這裡要補充一點，在之前關於移動前端技術的分享中有人為我為什麼一定要用DSL層，我說了一些原因，但因為這個分享還沒有做，所以沒有提及這一點。

那在看一下，天窗的處理吧，我們採用了佔位的方式。

左圖是生成的代碼，右圖是生成代碼運行后的效果，對於未識別的區域，我們採用了佔位，並加以提示：」對不起，我暫時不認識「，讓使用系統的工程師能夠直觀的了解到，哪些部分AI沒有幫助到他，他需要自行完善。

針對生成的代碼並結合運行的效果，我們採用強化學習（RL）的方式對於代碼進行微調。

主要的工作為：

Actons 只針對component屬性調整，不對代碼結構調整

評分系統依賴原有輸入（設計稿或者截圖）

Environment採用生成代碼后的運行截屏

結合區域性評分（結合Faster-RCNN過程的切圖）

暫時只針對位置、字體大小等

這一部分，由於時間原因，就不再展開了。

說了這麼多，讓我們一起看一下，這個系統的總體結構吧。

當一張設計圖被傳入系統的時候，首先基於CNN+Softmax的分類系統會將其分類處理（框架層代碼在這一層次生成）。

對於設計稿中沒有多級層次的設計，會直接進入Faster-RCNN進行一次目標檢測，識別對應的Basic Component，結合之前的代碼，生成新的代碼片段。

對於複雜的設計，會進入多次Faster-RCNN進行下一層次的目標檢測，直至可以進行代碼生成。

當生成代碼后，系統會自動編譯代碼，並將代碼Run起來，這時候就可以進行截圖，進行強化學習，對代碼進行微調。

上述就是這個系統的主要的技術分享，這個系統也不斷在完善中，我們後續也會繼續完善。

四、未完待續

首先，對於文字的處理，可以看到，我們並沒有直接生成，而是採用了「文字」來代替，主要的原因是文字的處理，屬於另外一個範疇的人工智慧，我們主要的思路是直接對接成熟的OCR或者雲服務，不會自己去做的。

關於圖片和icon的處理，可以看到，我們採用的是默認的圖片，而非設計稿中的圖片，這一點，我們會繼續進行。

方案大致是：

一種是設計師提供設計圖，並有小的切圖，這個處理比較簡單。

另外一種是無原圖或者需要對接圖庫的（圖庫規模不大的情況下），擬採用CNN+Softmax做一次分類，每一張圖片一張分類 。

同時，我認為AI將會繼續賦能移動，在AI結合移動，我們也在其他的方向進行了實踐：

智能化的CUI（Conversational UI）

智能推薦及輔助決策

由於時間和篇幅的原因，可能會沒有講明白，歡迎從事相關研究的同仁，添加作者微信一起探討。

郝振明

普元移動產品線總負責人，十多年 IT 從業經驗，一直專註於企業信息化的工作，近五年間一直從事企業移動信息化、移動互聯網化的諮詢、產品工作，曾主持參與了 Primeton Mobile 產品研發、聯通集團、廣東農信、諾亞財富、中信重工、索菲亞等公司的移動信息化工作。近兩年來，致力於基於 React Native 工程化能力的提升、降低實施難度，以及智能化移動平台的產品研發，在移動開發智能化的路上不斷進行探索。

關於EAWorld