前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >使用TensorFlow搭建智能开发系统,自动生成App UI代码

使用TensorFlow搭建智能开发系统,自动生成App UI代码

作者头像
yuanyi928
发布2018-03-30 16:35:05
1.6K0
发布2018-03-30 16:35:05
举报
文章被收录于专栏:EAWorldEAWorld

本文目录:

一、我们的现状与期望

二、我们的初级探索及建议

三、智能开发系统的自建之路

四、未完待续

一、我们的现状与期望

首先,我们作为一个移动平台产品,必须解决的是让工程师更加容易的开展工作,“知识工作者智能化”是我们探索的方向,让移动开发工程师先用起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 工程化能力的提升、降低实施难度,以及智能化移动平台的产品研发,在移动开发智能化的路上不断进行探索。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-06-22,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 EAWorld 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档