本文目錄：
一、我們的現狀與期望
二、我們的初級探索及建議
三、智能開發系統的自建之路
四、未完待續
一、我們的現狀與期望
首先，我們作爲一個移動平臺產品，必須解決的是讓工程師更加容易的開展工作，“知識工作者智能化”是我們探索的方向，讓移動開發工程師先用起AI，也是我們的期望。
針對我們的移動開發工程師，我們的主要的工作概括說有三件事：
-
瞭解需求
-
拿到UI設計
-
研發
我們期望的是，基於機器學習（ML）的移動平臺，最終能夠：
-
讓初級開發人員具備專家80%的能力
-
讓AI輔助移動App的研發工作。
對於AI，BAT有着不同的看法，馬雲的數據論，李彥宏的技術論，以及馬化騰的場景論，我個人馬化騰的論調跟我們不謀而合，我們認爲切入點很重要。
我們的切入點是：從設計稿（或者App 截圖）到App 前端代碼，這也是我今天分享的方向。
二、我們的初級探索與建議
爲了，我們在實踐的前期，進行了一些探索並總結了一些建議，希望能夠給大家一些啓發。
正如大家所知道的基於機器學習工程話的過程，需要數據、算法、算力以及工程話的配合，是一個不小的工程，我們的初步想法，是否借力SaaS的服務能力，於是我們進行了公有云服務的嘗試。
我們找了一張狗狗的圖，實際的效果非常的贊。
-
準確識別狗，並且能夠識別到品種；（潛臺詞：能夠識別不同設計就好了）
-
有“鼻子”有眼的，看上去很美，（潛臺詞：能夠識別設計裏的UI控件就夠了）
於是，我們抱有很大期望的用設計稿作爲嘗試，效果大致如下：
實際上效果如上圖，無法準確的認知這是一個設計圖，更不用說是什麼類型的UI以及UI內有哪些控件，於是我們嘗試了另外一家。
實際上效果，依舊無法使用。
經過公有云不成功的嘗試我們總結了一下的結論：
普遍的目標檢測都是無嵌套結構的認知
而App 的UI是一個結構化數據，存在嵌套關係、層級關係
上圖中的目標檢測對於生成代碼沒有任何幫助
三、智能開發系統的自建之路
於是我們走向了智能開發系統的自建之路
在前期的初級探索中，我們已經非常明確的知道：訓練的方向，決定了結果。而我們的方式是：
-
專注：訓練一個只懂移動UI的程序員
-
學習移動App UI 的設計稿或者截圖
-
不學習Web UI 或者GUI的設計稿
-
堅決不學習常規事物
上面的原則主要的目標是爲了訓練的專注性，我們調戲一把。
同樣的這隻狗，在公有云的服務中都能夠準確的認知，而我們的系統把它當成了歡迎頁（0.72）而不是狗。
來看一小段視頻：
點擊查看視頻：普元AI智能移動平臺
視頻說明：
-
右二窗口：是設計稿或者截圖（支持：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）
由於時間和篇幅的原因，可能會沒有講明白，歡迎從事相關研究的同仁，添加作者微信一起探討。
