用户界面的制作方法、装置、存储介质及计算机设备

技术领域

本申请涉及计算机技术领域，具体涉及一种用户界面的制作方法、装置、存储介质及计算机设备。

背景技术

在游戏行业中，用户界面(下简称UI)与用户界面的交互逻辑的制作是非常重要的一个部分。在游戏运行过程中，用户需要通过UI与游戏内的虚拟物件进行交互操作。除了交互逻辑外，用户界面还承载着大量的显示逻辑，即将游戏内的数据显示到界面上。因此UI的制作工时会占到游戏开发相当一部分的工时。此外，UI的制作还会涉及多个职能人员之间的相互沟通，其中有程序编写者、交互逻辑的设计者、美术资源产出者、UI结构资源的生产者等，一般会有一个职能人员担任其中一项工作，但某些时候也可能由某个职能人员兼任多项工作。而这些职能人员在制作流程功能时需进行大量沟通，也变成了游戏开发的成本之一。UI相关功能会嵌入到整个游戏流程当中，对于需要体验游戏流程的其他职能人员而言，UI资源/UI代码带来的错误可能会导致其体验流程阻塞。

现有的用户界面制作方法，工作流上的耦合性较高，导致整个界面制作的工作效率低，且各个程序代码资源之间存在代码耦合的情况，增加了UI制作的复杂度。

因此，现有技术存在缺陷，有待改进与发展。

发明内容

本申请实施例提供一种用户界面的制作方法、装置、存储介质及计算机设备，可以减少代码的耦合性，降低UI制作的复杂度以及提升工作效率。

本申请实施例提供了一种用户界面的制作方法，包括：

响应于被触发的提交指令，获取初版UI逻辑文件，其中，所述初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，所述UI配置文件独立于所述UI工程文件和逻辑代码；

将所述初版UI逻辑文件提交至主干程序；

响应于被触发的修改指令，获取所述初版UI逻辑文件对应的修改文件，其中所述修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；

对所述修改文件进行检测；

当所述修改文件满足检测条件时，将所述修改文件提交至所述主干程序，以更新所述主干程序中的初版UI逻辑文件。

本申请实施例还提供一种用户界面的制作装置，包括：

第一获取模块，用于响应于被触发的提交指令，获取初版UI逻辑文件，其中，所述初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，所述UI配置文件独立于所述UI工程文件和逻辑代码；

第一提交模块，用于将所述初版UI逻辑文件提交至主干程序；

第二获取模块，用于响应于被触发的修改指令，获取所述初版UI逻辑文件对应的修改文件，其中所述修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；

检测模块，用于对所述修改文件进行检测；

第二提交模块，用于当所述修改文件满足检测条件时，将所述修改文件提交至所述主干程序，以更新所述主干程序中的初版UI逻辑文件。

本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于处理器进行加载，以执行如上任一实施例所述的用户界面的制作方法中的步骤。

本申请实施例还提供一种计算机设备，所述计算机设备包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器通过调用所述存储器中存储的所述计算机程序，执行如上任一实施例所述的用户界面的制作方法中的步骤。

本申请实施例提供的用户界面的制作方法、装置、存储介质及计算机设备，通过响应于被触发的提交指令，获取初版UI逻辑文件，初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，UI配置文件独立于UI工程文件和逻辑代码；将初版UI逻辑文件提交至主干程序；响应于被触发的修改指令，获取初版UI逻辑文件对应的修改文件，其中修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；对修改文件进行检测；当修改文件满足检测条件时，将修改文件提交至主干程序，以更新主干程序中的初版UI逻辑文件。本申请实施例通过UI配置文件将UI工程文件与逻辑代码进行隔离，可以独立处理逻辑代码、UI工程文件、UI配置文件，减少了代码的耦合性，降低UI制作的复杂度以及提升工作效率。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的用户界面的制作方法的流程示意图。

图2为本申请实施例提供的第一数据结构示意图。

图3为本申请实施例提供的第二数据结构示意图。

图4为本申请实施例提供的第三数据结构示意图。

图5为本申请实施例提供的第四数据结构示意图。

图6为本申请实施例提供的用户界面的制作装置的结构示意图。

图7为本申请实施例提供的计算机设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供一种用户界面的制作方法、装置、存储介质及计算机设备。具体地，本申请实施例的用户界面的制作方法可以由计算机设备执行，其中，该计算机设备可以为终端或者服务器等设备。该终端可以为智能手机、平板电脑、笔记本电脑、触控屏幕、游戏机、个人计算机(Personal Computer，PC)、个人数字助理(Personal Digital Assistant，PDA)等终端设备。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络服务、以及大数据和人工智能平台等基础云计算服务的云服务器，但并不局限于此。

例如，一般的UI制作工作流程为：UI职能的人员负责设计交互设计图；UI人员结合美术人员给出的素材制作UI工程文件，工程文件主要描述了树状的用户界面节点图与节点的动画；然后将工程文件与交互设计图交付给程序人员，程序人员进行交互设计图的解读与素材的使用，以输出逻辑代码；然后将工程文件与逻辑代码提交到开发主干，使得其他职能人员可以从主干进入游戏，体验UI相关功能；职能人员可能对于美术素材、UI工程文件、代码三者进行迭代与提交；进行若干次迭代之后，一个UI界面的功能开发完成。对于现有的UI代码逻辑，UI相关的功能由代码逻辑驱动与事件驱动，即某个函数调用使UI的显示、UI页面内的数据发生变化。某个事件到来后触发某个函数调用，使之改变UI的显示与页面内的数据。现有方案有以下几个缺点：

(1)在职能上有所耦合：现有方案由程序人员负责解读并实施交互设计图的方案，但程序人员对于交互设计图的方案的理解可能产生歧义或者遗漏。因此方案最后需要经过UI交互逻辑的设计者进行验收，而验收过程等于产生了工作的依赖关系，使得总的工作流会变长。

(2)游戏资产上产生耦合：代码属于游戏资产，对于现有方案，UI程序必须将一部分UI工程文件的结构描述在代码内，此时如果UI工程文件结构发生改变，可能需要知会UI程序进行修改(引入耦合)，也可能直接提交资源等待程序修复问题(引入系统风险阻塞其他流程)。

(3)函数驱动的逻辑，给逻辑的复用与迭代带来了麻烦：对于交互方案的设计人员来说，UI的相关逻辑是事件驱动的，而函数驱动的逻辑提高了交互设计人员理解程序方案的成本，同时阻止了将相关逻辑剥离交给交互设计人员进行编辑的可能。

(4)部分可数据化的代码以代码形式存在于代码之中，不利于数据驱动，同时没有很明确的逻辑划分，使得代码容易耦合，增加了系统的复杂度。

(5)视图数据的在线热更新困难：因为没有剥离需要持久化存储的关联视图显示的数据，在视图数据(UI工程文件)文件重载后，可能会导致某些状态的丢失，从而无法实现一个完备的视图数据热更新功能。

其中，本申请实施例重新划分了UI程序逻辑底层框架中UI相关的编码逻辑与数据，相关职能人员在制作相应的文件或代码时，均基于重新划分后的UI程序逻辑底层框架进行相关文件或代码的制作。例如，UI程序逻辑底层框架中UI相关的数据被划分为视图树数据、逻辑树数据和UI数据。其中，视图树数据包括UI工程文件当中的节点结构与相关美术资源；逻辑树数据包括UI节点在程序视角下表现的树状结构；UI数据包括用户交互界面关联的显示数据、逻辑相关的数据等。例如，UI程序逻辑底层框架中UI相关的编码逻辑被划分为了视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层。其中，视图树逻辑表示与实际表现相关的逻辑，视图树逻辑主要是设置视图树节点相关属性；逻辑树逻辑表示UI逻辑在游戏程序中呈现的树状结构上的相关逻辑，例如动态添加或删除逻辑节点；UI数据逻辑表示数据更新时驱动显示改变的相关逻辑；逻辑接口层表示游戏程序逻辑实现的所在，如发生了某个点击之后执行游戏内的某些目标逻辑，比如用户移动摇杆节点时，产生了摇杆移动事件，从而触发了游戏内物体的移动逻辑，而这个移动逻辑则实现在接口层上。

由于重新划分了逻辑框架，在原有UI工程文件(视图树数据)的基础上分离出新的数据(包含逻辑树的树状结构、UI数据字段)，本申请实施例引入一个新的数据类型概念：UI配置文件，用于记录引入的新的数据。

其中，所述UI工程文件的视频树数据用于描述树状的用户界面节点图。所述UI配置文件用于描述目标程序所用到的所述UI工程文件内的所述视频树数据中UI节点图的UI节点的路径。

具体的，所述UI配置文件用于描述所述UI工程文件内的所述视频树数据中UI节点图的节点结构与目标程序所用到的UI节点的对应关系。其中，目标程序可以为被开发的目标用户界面的程序，比如目标程序为被开发的目标用户界面的主干程序。

例如，UI配置文件主要用于描述UI工程文件内的所述视频树数据中UI节点图的节点结构与目标程序所用到的UI节点的对应关系；UI配置文件还用于描述UI数据的数据名、数据类型；UI配置文件还用于描述UI节点的属性与UI数据的对应关系；UI配置文件还用于描述UI事件与UI事件引起的变化关系等数据。

在工作流上，引入了UI配置文件的制作，将部分与程序制作的耦合过程的工程调整到UI配置文件中，使得可并行的工作环节增加，减少总的制作流程长度；同时引入UI配置文件与UI工程文件的检查，UI工程文件在提交之前，需要将其内部的树状结构与UI配置文件内声明的所使用到的树状结构相比对，只有结构完全一致，才允许UI工程文件被提交到主干。

其中，UI程序逻辑底层框架将UI的编码逻辑划分为四部分：视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层，从编程人员编程的角度看，带来了以下好处:(1)逻辑的划分减少了代码层面的耦合性；(2)明确了数据的流向的逻辑，规范了代码的编写、为事件驱动提供了便利；(3)提供了相关的自动化操作，提供了代码自动生成的配套工具，使得编程人员能更加专注于编程业务，同时也规范了代码的编写。

其中，新的UI程序逻辑底层框架中的数据，在原有UI工程数据的基础上新增了UI配置文件，UI配置文件中描述了程序逻辑树树状结构与UI数据这两类数据，这个数据概念的分离将原来散布在代码当中可以被表示成数据的部分抽离了出来，带来了以下好处：(1)减少了代码与UI工程资产的耦合；(2)提供了程序描述与UI工程相检查、UI数据类型检查的机会，防止视图节点因为设置了不正确的类型数据导致的错误；(3)描述了数据与相关显示的绑定关系，为数据驱动提供了便利；(4)视图数据与UI数据的分离，为实现视图数据的热更新提供了便利。

然后，从工作流程上，引入了UI配置文件的制作流程，带来了以下好处：(1)在总工作量不变的情况下，拆分了可并行的工作，使得系统总并行度增加；(2)为其他职能参与UI制作提供了可能，这主要是将本应该由其他职能完成的工作从程序处剥离，减小了系统当中由于沟通产生的成本；(3)增加了流程中的检查步骤，增强了程序系统的健壮性。保证在迭代期提交到主干的代码和资源永远处于同步状态，而不会导致主干处于一个不完整的状态导致游戏流程受阻。

其中，基于程序通用性的考虑，此处对数据资产的相关格式与文件类型不做限定。例如，格式可以包括以下至少一种：json、bson、yaml；文件类型可以包括以下至少一种csb、csd、xml。例如，UI工程文件的文件类型是csb，UI配置文件的文件类型是yaml。上述举例不作为对本申请实施例的限定。

例如，本申请实施例可以仅在客户端上实现。例如，本申请实施例也可以在服务器和客户端上实现，比如需要用户界面显示关联服务器的数据时，可以先将服务器上的数据同步到客户端，然后由客户端来对数据进行相应处理。

其中，UI程序逻辑底层框架对应的代码结构中，所有的UI程序逻辑节点基类(UINode)包括视图类(View)、逻辑树类(UITree)和UI数据类(UIData)。

其中，视图类对应UI程序逻辑底层框架中的视图树逻辑和视图树数据，逻辑树类对应UI程序逻辑底层框架中的逻辑树逻辑和逻辑树数据，UI数据类对应UI程序逻辑底层框架中的UI数据逻辑和UI数据。UI程序逻辑底层框架中的逻辑接口层，实现在继承了UINode的子类里面，UINode本身只提供公共框架的功能。逻辑接口层最主要的功能是提供了以下几类操作：

(1)响应事件:外界的事件触发本节点以及本节点的逻辑子树的节点的相关逻辑；其中程序人员可以直接在UINode上定义事件与响应函数，或者在UI配置文件内定义事件与响应操作，在UIData类初始化时会被导入，然后自动注册到UINode内并响应事件触发；

(2)修改UI数据并驱动视图变化：提供了接口以修改UI的数据，并且自动根据UI数据关联的视图节点，自动只对对应节点进行更新(而非刷新所有节点)。同时如果数据之间产生了依赖关系，也会自动处理依赖关系，会更新所有依赖的字段的值，并刷新对应的视图节点；

(3)数据的预处理：例如预先计算UI数据与对应节点的关联关系；

(4)View的热更新：对视图资源进行卸载与重载，同时根据UIData刷新对应的视图节点状态。

其中，UINode中的View、UITree、UIData分别负责处理各类自身所读取的数据，其中需保证对外接口一致。其中，可以实现多种不同的View类，用于区分不同的视图数据类型、不同的游戏引擎实现。还可以实现不同的UITree类，用于管理不同类型的父子关系存储数据结构，如列表结构或字典结构。还可以实现不同的UIData，用于处理不同的UI配置文件，或者以不同的方式、格式保存UI数据。其中，UI配置文件中包含的逻辑树数据会被逻辑树类读取存储，UI配置文件中包含的UI数据的相关声明会被UI数据类读取存储。

对于游戏业务的开发程序，只需要定义使用哪些View、UITree、UIData，并根据UINode提供的方法进行业务逻辑的实现，而无须关心View、UITree、UIData的底层实现。从而减少了开发程序的负担。

其中，本申请实施例中所使用的UI配置文件文件以yaml格式为例，UI配置文件文件可以包括export_conf字段、const_data字段、output_data_conf字段和node_data_conf字段等。

其中，export_conf字段用于描述UI配置文件的元数据，描述了UI配置文件对应的UI工程文件名、逻辑代码中需要用到的外部库等。

其中，const_data字段用于描述UI配置文件对应的UINode所约定的常量。

其中，output_data_conf字段用于描述UI数据，主要描述数据字段名与对应数据类型，根据数据取值方式的不同，可以将output_data_conf字段分为以下几个字段类型：__ATTR字段类型、__AUTO_FUNC字段类型和__EVENT字段类型。

其中，对于__ATTR字段类型，UI数据的取值来源为根据输入值获取，外部通过UINode设置UI数据的取值时，会将UI数据的取值写入到一个缓存中；而取值时，若检测到该UI数据的取值的类型为__ATTR,则会从缓存中取同名的变量作为返回值返回。例如，用Python举例如下：

ui_node.set_input_data(‘key’,‘value’)，表示在缓存中设置了名称为key的UI数据，其取值为value；

ui_node.get_data(‘key’)，表示假设key被定义为了__ATTR类型，那么返回缓存中key对应的值value；

ui_node.get_data(‘key2’)，表示返回None，无论有无定义__ATTR，(因在缓存中并没有key2对应的值，则返回None)。

其中，对于__AUTO_FUNC字段类型，UI数据的取值可以根据一个函数的计算取得返回值。例如，设定一个函数：

def get_value():

return 123

其中，key2的UI数据被定义为__AUTO_FUNC类型，key2的UI数据绑定的取值函数为get_value，那么有如下代码：

ui_node.set_input_data(‘key’,‘value’)，表示在缓存中设置了名称为key的UI数据，其取值为value；

ui_node.get_data(‘key’)，表示假设key被定义为了__ATTR类型，那么返回缓存中key对应的值value；

ui_node.get_data(‘key2’)表示返回123，因为__AUTO_FUNC类型不依赖缓存中的值，只依赖于函数执行的结构。

其中，__AUTO_FUNC字段类型中还包含有一些拓展字段，允许绑定的计算函数依赖某些缓存中的值，或者依赖某个事件到达时触发一次计算，并自动更新对应关联的视图节点。例如，拓展字段的细节如下：

STATIC_INPUT：为绑定函数，声明静态入参；

ATTR_NAME：为绑定函数，声明一些从缓存中取的值作为入参；特别的，这些缓存中的值发生更新时会触发该__AUTO_FUNC对应的UI数据的更新；

EVENT_NAME：指定了某些事件到达时触发该__AUTO_FUNC对应的UI数据的更新；

FUNC_NAME：指定了所绑定的计算函数的函数名。

其中，对于__EVENT字段类型，该字段主要用于自动化为UINode声明事件，并声明事件到来时自动触发一些行为，__EVENT字段类型下的结构如下：

事件名：表示同个UINode下唯一的事件名称，下有若干该事件发生时进行的自动化操作；

COND：表示满足某个条件时，才响应该事件；

TRIGGER_ANIM_BEFORE：表示进行动画的播放/停止操作，可以根据条件判断是否进行该操作；

SET_VAL：表示把数据缓存中某些字段的值改变；

FUNC_NAME：表示调用某个响应函数；

TRIGGER_ANIM_AFTER：表示进行动画的播放/停止操作，可以根据条件判断是否进行该操作，与BEFORE的区别是在整个事件执行流程后进行相应操作。

其中，UI配置文件用于描述目标程序所用到的所述UI工程文件内的视频树数据中UI节点图的UI节点的路径。具体的，UI配置文件用于描述UI工程文件内的视频树数据中UI节点图的节点结构与目标程序所用到的UI节点的对应关系。例如，UI配置文件中的node_data_conf字段用于描述程序所用到的UI工程文件内的UI节点的路径。

例如，UI工程文件的视图树状结构如下：

对于上述举例的UI工程文件的视图树状结构，程序真正使用的UI工程文件的UI节点只有text_node1，picture_node1；因此在UI配置文件文件的node_data_conf字段内，会设置与UI工程文件同样的一个树状结构，但node_data_conf字段只保留text_node1与picture_node1节点。因为其他节点的改动并不会影响程序的运行，即程序代码里根本没用到其他节点，因此在检查时只需比对这两个节点是否存在。

其中，可以在每个节点下声明节点对应的python类类型与相关的参数，代码举例如下：

对于上述举例的代码，声明了节点所使用的python类的类名为text和image，同时指定了节点的数据来源，比如text_node1节点，其文本内容取自UIData中key字段对应的值，而picture_node1节点读取的图片路径取自UIData中key2字段对应的值。

其中，在实际应用中，每个节点会有各种各样不同的属性设置，属性设置具体取决于type对应的python类的接口，不同的属性对应于不同的函数调用。

请参阅图1至图5，图1为本申请实施例提供的用户界面的制作方法的流程示意图，图2至图5均为本申请实施例提供的数据结构示意图。本申请实施例提供了一种用户界面的制作方法，该方法可以由任意执行用户界面的制作方法的装置来执行，该装置可以通过软件和/或硬件实现，该装置可以集成在计算机设备中。如图1所示，该方法的具体流程可以如下：

步骤101，响应于被触发的提交指令，获取初版UI逻辑文件，其中，所述初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，所述UI配置文件独立于所述UI工程文件和逻辑代码。

具体的，所述响应于被触发的提交指令，获取初版UI逻辑文件，包括：

响应于被触发的第一提交指令，获取所述UI工程文件，所述UI工程文件为针对交互设计图预先制作并提交的文件；

响应于被触发的第二提交指令，获取所述逻辑代码，所述逻辑代码为针对所述交互设计图预先制作并提交的代码；

响应于被触发的第三提交指令，获取所述UI配置文件，所述UI配置文件为根据所述交互设计图和所述UI工程文件预先制作并提交的文件；

根据所述UI工程文件、逻辑代码和UI配置文件生成所述初版UI逻辑文件。

可选的，所述UI工程文件、逻辑代码和UI配置文件为通过预设的UI程序逻辑底层框架进行制作得到，其中，所述UI程序逻辑底层框架中UI相关的数据被划分为视图树数据、逻辑树数据和UI数据，所述UI程序逻辑底层框架中UI相关的编码逻辑被划分为视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层。

可选的，通过所述UI程序逻辑底层框架中视图树数据的编辑接口进行制作得到的所述UI工程文件，包括所述视图树数据；通过所述UI程序逻辑底层框架中编码逻辑的编辑接口进行制作得到的所述逻辑代码，包括所述视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层对应的代码；通过所述UI程序逻辑底层框架中逻辑树数据和UI数据对应的编辑接口进行制作得到的所述UI配置文件，包括所述逻辑树数据和UI数据；其中，所述UI配置文件独立于所述UI工程文件和逻辑代码。

其中，由于UI工程文件是通过视图树数据的编辑接口进行制作得到的，逻辑代码是通过所述UI程序逻辑底层框架中编码逻辑的编辑接口进行制作得到的，UI配置文件是通过UI程序逻辑底层框架中逻辑树数据和UI数据对应的编辑接口进行制作得到，UI工程文件、逻辑代码和UI配置文件从底层逻辑框架上是分离的，用户在制作阶段通过分离设计的相关底层架构模块，制作相应的文件或代码，从而避免了文件或代码之间的耦合，使得UI配置文件可以独立于UI工程文件和逻辑代码，即UI配置文件不耦合于UI工程文件(视图树数据不包含有逻辑树数据和UI数据)，且UI配置文件也不耦合于逻辑代码(逻辑代码不包含有逻辑树数据和UI数据)，各个职能人员可并行工作。

其中，响应于被触发的第一提交指令，获取所述UI工程文件，所述UI工程文件为第一用户针对交互设计图预先制作并提交的文件。具体的，首先提交交互设计图。UI设计人员将已设计好的交互设计图提交给其他职能人员，以供其他职能人员基于交互设计图制作相关文件或代码。其中，交互设计图包括交互设计文档与图示。其中，交互设计文档中包含有交互逻辑。其次提交UI工程文件。其他职能人员接到交互设计文档与图示后，美术人员根据交互设计图生产相关图片资源素材，然后美术人员将相关图片资源素材提交给拼接人员，以使拼接人员根据美术人员提交的相关图片资源素材进行UI工程文件进行制作。拼接人员(第一用户)通过目标平台上的提交入口触发第一提交指令，该第一提交指令包含有已制作完成的UI工程文件，通过第一提交指令将UI工程文件提交到目标平台。例如，目标平台为自动打包发布平台。其中，在制作UI工程文件的过程中，拼接人员通过UI程序逻辑底层框架中视图树数据的编辑接口进行制作，以生成UI工程文件。其中，UI工程文件包括视图树数据。

其中，游戏界面是游戏的用户界面。包括登录界面、技能栏、道具栏、状态栏、信息栏、游戏商城等。游戏用户界面是游戏系统和用户之间进行交互和信息交换的媒介。通过游戏界面，游戏玩家可以在游戏世界中实现各种操作。它实现了信息的内部形式和人类可接受的形式之间的转换。在游戏界面开发过程中，需要基于UI设计人员设计的交互设计图来制作游戏界面。其中，交互可以包括交互发生的时间、交互发生的位置和交互发生的动作等信息，可以分别用When、Where和What表示。When表示什么时候发生交互动作，也可以称之为事件。例如，当浏览器中加载页面时，或用户点击、拖曳一个控件后。Where表示交互在发生的位置，可以建主交互动作的控件。例如，矩形框、单选按钮、下拉到表、一个图片或页面的某个热区等。What表示会发生什么动作。动作定义了交互的过程和结果。例如，在页面加载时，将一个动态面板的坐标设置到某一个位置。交互设计图为UI设计人员根据产品项目需求设计的交互相关的示意图。其中，交互设计图可以包括以下至少一种：物理业务流程图、站点功能拓扑图、角色任务流程图、界面布局线框图、页面跳转逻辑图、软件逻辑流程图、底层数据流程图。

(1)物理业务流程图，用于规划物理业务流程。在产品项目开发过程后中，要对物理业务进行建摸，比如原来的部门有一些什么业务流程，如何拆分或合并业务流程，流程中会涉及哪些对象和职能人员，各个职能人员负责处理什么任务等。

(2)站点功能拓扑图，用于指示用户在浏览UI页面时通过链接跳转到相关UI页面。一个站点或一个产品的功能模块拓扑包括导航、频道、类目、功能块等组织结构之间的关系。其中功能模块可以包括用户常用功能以及功能块之间的逻辑关系。

(3)角色任务流程图，用于表示不同的角色对应的任务流。一个产品，会有不同的用户角色去操作，不同的用户角色要达成的目的和完成的任务都不一样。

(4)界面布局线框图，用于对界面功能模块的进行布局。线框图上的注释细节可以写成交互设计文档，比如可以包括界面的功能、内容、行为、限制因素等。比如功能包括操作、事件、反馈方式、响应时间、数据输入/输出等；内容包括文本、字体、图片、排版、尺寸、链接、多媒体、声音等；行为包括动画样式、速度、位移、交互效果、链接跳转位置、控件状态等；限制因素包括硬件、系统、软件、浏览器、数据格式等。

(5)页面跳转逻辑图，用于将页面和页面之前的关联和跳转事件设定到相关控件上。

(6)软件逻辑流程图，用于描述产品开发过程中的软件逻辑流程。

(7)底层数据流程图，用于描述产品开发过程中的底层数据流程。

其中，响应于被触发的第二提交指令，获取所述逻辑代码，所述逻辑代码为第二用户针对所述交互设计图预先制作并提交的代码。具体的，程序人员根据交互设计图中的交互逻辑制作对应的UI程序的逻辑代码，该逻辑代码为业务逻辑，运行于UI程序逻辑底层框架之上。UI程序逻辑底层框架将UI的编码逻辑划分为四部分：视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层。因此UI程序逻辑代码中所有的UI程序逻辑节点基类(UINode)包括视图类(View)、逻辑树类(UITree)和UI数据类(UIData)。程序人员(第二用户)通过目标平台上的提交入口触发第二提交指令，该第二提交指令包含有已制作完成的逻辑代码，通过第二提交指令将逻辑代码提交到目标平台。例如，目标平台为自动打包发布平台。其中，在制作逻辑代码的过程中，程序人员通过UI程序逻辑底层框架中编码逻辑的编辑接口进行制作，以生成UI程序的逻辑代码。逻辑代码包括视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层对应的代码。

其中，响应于被触发的第三提交指令，获取所述UI配置文件，所述UI配置文件为第三用户根据所述交互设计图和所述UI工程文件预先制作并提交的文件。程序人员或UI设计人员根据UI工程文件与交互设计图，设计UI数据与逻辑树数据，以生成UI配置文件。例如，UI数据可以包括用户交互界面关联的显示数据、逻辑相关的数据、数据类型等。逻辑树数据可以包括UI节点在程序视角下表现的树状结构，即哪些UI节点需要根据UI数据进行对应显示，哪些UI节点需要响应交互逻辑等。程序人员(第三用户)通过目标平台上的提交入口触发第三提交指令，该第三提交指令包含有已制作完成的UI配置文件，通过第三提交指令将UI配置文件提交到目标平台。例如，目标平台为自动打包发布平台。其中，在制作UI配置文件的过程中，程序人员通过UI程序逻辑底层框架中逻辑树数据和UI数据对应的编辑接口进行制作，以生成UI配置文件。UI配置文件包括逻辑树数据和UI数据。

其中，所述第一用户、第二用户、第三用户可以为不同职能的人员，也可以为相同职能的人员。

其中，根据所述UI工程文件、逻辑代码和UI配置文件生成所述初版UI逻辑文件。所述初版UI逻辑文件为目标平台将所述UI工程文件、逻辑代码和UI配置文件打包成的可执行文件，该可执行文件构成初版UI逻辑文件。

步骤102，将所述初版UI逻辑文件提交至主干程序。

其中，将逻辑代码、UI工程文件与UI配置文件打包形成的可执行文件提交到主干上，以供各职能人员可以从主干上最新的客户端运行该用户界面逻辑。

其中，大多数程序产品开发存在的生命周期为编码、测试、发布，然后不断重复。例如，开发工具以版本控制系统(Subversion，SVN为例，在SVN中创建代码库时，通常会创建主干(trunk)、分支(ranches)、标记(tags)三个子目录。其中，主干(trunk)，也可以称为主线，主干是用来做主方向开发的，新功能的开发放在主线中，当模块开发完成后，需要修改，可以采用分支。分支(branches)，是从主线上分出来，独立于主线的另一条线。可以创建多个分支。一个分支总是从主干一个备份开始的，从那里开始，发展自己独有的历史。在版本控制系统中，经常需要对开发周期中的单独生命线作单独的修改，这条单独的开发生命线就可以称为Branches，即分支。分支经常用于添加新的功能以及程序产品发布后的漏洞(bug)修复等，这样可以不影响主要的产品开发线以及避免编译错误等。当添加的新功能完成后可以将分支合并到主干中。分支开发和主线开发可以同时进行，即为并行开发。标记(tags)，用于标记某个可用的版本，可以标记已经上线发布的版本，也可以标记正在测试的版本，通常是只读的。

例如，主干作为开发主线，开发人员可以将符合要求的代码提交到主干上，如果在没有必要的条件下，不开分支。同时对主干做持续集成验证，最大程度上保证主干的稳定性。本申请实施例中的主干程序，可以为主干开得到的程序产品，主干程序为相对稳定版本的代码对应的程序产品。

步骤103，响应于被触发的修改指令，获取所述初版UI逻辑文件对应的修改文件，其中所述修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种。

其中，由于需求发生迭代，逻辑代码、UI工程文件、UI配置文件此三种资源都可能发生改变，但三种资源不一定同时发生改变，根据需求的不同，有时可能只是其中之一或者其二发生改变，但修改文件的制作是发生在本地终端或者开发分支上，且不会将修改文件马上提交至主干。具体的，基于用户触发的修改指令获取修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种。

其中，修改后的逻辑代码为程序人员在初版UI逻辑文件中的逻辑代码基础上，通过UI程序逻辑底层框架中编码逻辑的编辑接口进行修改，以生成修改后的逻辑代码，并基于修改指令，将在本地的修改后的逻辑代码提交到目标平台。修改后的逻辑代码包括视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层对应的代码。

其中，修改后的UI工程文件为拼接人员在初版UI逻辑文件中的UI工程文件基础上，通过UI程序逻辑底层框架中视图树数据的编辑接口进行修改，以生成修改后的UI工程文件，并基于修改指令，将在本地的修改后的UI工程文件提交到目标平台。修改后的UI工程文件包括视图树数据。

其中，修改后的UI配置文件为程序人员在初版UI逻辑文件中的UI配置文件基础上，通过UI程序逻辑底层框架中逻辑树数据和UI数据对应的编辑接口进行修改，以生成修改UI配置文件，并基于修改指令，将在本地的修改后的UI配置文件提交到目标平台。UI配置文件包括逻辑树数据和UI数据。

步骤104，对所述修改文件进行检测。

可选的，所述对所述修改文件进行检测，包括：

当所述修改文件为修改后的逻辑代码时，对所述修改后的逻辑代码进行单元测试；或者

当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查。

可选的，所述当所述修改文件为修改后的逻辑代码时，对所述修改后的逻辑代码进行单元测试，包括：

基于预设的单元测试工具对所述修改后的逻辑代码进行单元测试，当所述单元测试的输出为预期结果时，确定所述修改后的逻辑代码满足检测条件。

其中，单元测试是指对软件中的最小可测试单元进行检查和验证。单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。在代码提交主干之前，需要进行单元测试，可以通过预设的单元测试工具进行测试，单元测试工具中，程序人员可以基于当前UI工程文件和当前UI配置文件预先设置好相应的测试函数，测试函数中设有期望值，将被测试的逻辑代码输入单元测试工具中，进过测试之后，如果输出的实际值与预设的期望值一致时，判定输出的是预期结果。如果输出的实际值与预设的期望值不一致时，判定输出的不是预期结果。通过单元测试的代码，可以保证代码的有效性。

其中，除了对修改后的逻辑代码进行单元测试，也可以在修改后的逻辑代码被提交到目标平台之前，程序人员进行自测。程序人员基于获取到的当前UI工程文件和当前UI配置文件进行自测，若UI工程文件和UI配置文件已被修改，则当前UI工程文件和当前UI配置文件分别为修改后的UI工程文件和修改后的UI配置文件。若UI工程文件和UI配置文件未被修改，则当前UI工程文件和当前UI配置文件分别为原始UI工程文件和原始UI配置文件。

具体的，在逻辑代码修改后，使用最新的UI配置文件与UI工程文件进行测试，通过测试后该逻辑代码才具备提交权限，最终等待最新版工程文件与配置文件通过数据检查后才会将程序代码提交主干。工程文件与配置文件的测试失败只意味着工程文件与配置文件之间产生了不符合的情况，而不会与逻辑代码产生关联，因此测试失败只是让代码暂时无法提交，而不需要涉及代码的修改。其中，逻辑代码与UI工程文件或UI配置文件之间的匹配错误几乎都是语义上的错误，逻辑代码的测试环节没有办法进行数据检查，逻辑代码的测试环节的目的为让程序人员自身去保证逻辑代码提交的有效性。

可选的，所述当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查，包括：

当所述修改文件为修改后的UI工程文件时，对所述修改后的UI工程文件与所述初版UI逻辑文件中的UI配置文件进行数据检查；或者

当所述修改文件为修改后的UI配置文件时，对所述修改后的UI配置文件与所述初版UI逻辑文件中的UI工程文件进行数据检查；或者

当所述修改文件为修改后的UI工程文件和修改后的UI配置文件时，对所述修改后的UI工程文件和修改后的UI配置文件进行数据检查。

例如，当所述修改文件为修改后的UI工程文件时，目标UI工程文件为修改后的UI工程文件，目标UI配置文件为初版UI逻辑文件中的UI配置文件。

例如，当所述修改文件为修改后的UI配置文件时，目标UI工程文件为初版UI逻辑文件中的UI工程文件，目标UI配置文件为修改后的UI配置文件。

例如，当所述修改文件为修改后的UI工程文件和修改后的UI配置文件时，目标UI工程文件为修改后的UI工程文件，目标UI配置文件为修改后的UI配置文件。

可选的，所述当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查，包括：

检查所述目标UI配置文件中的逻辑树数据的节点命名与所述目标UI工程文件中的视图树数据的节点命名的一致性；

检查所述目标UI配置文件中的逻辑树数据的节点父子结构与所述目标UI工程文件中的视图树数据的节点父子结构的一致性；

检查所述目标UI配置文件中的逻辑树数据的节点类型与所述目标UI工程文件中的视图树数据的节点类型的一致性；

检查所述目标UI工程文件和目标UI配置文件中所使用的UI数据的一致性。

其中，检查所述目标UI配置文件中的逻辑树数据的节点命名与所述目标UI工程文件中的视图树数据的节点命名的一致性。例如，目标UI工程文件中具有如图2中的2.1所示的视图树数据。例如，若目标UI配置文件中具有如图2中的2.2所示的逻辑树数据，则图2中的2.2所示的逻辑树数据是合法的，因为逻辑树数据的节点A、E都有对应的视图树数据的节点。在进行节点命名一致性检查时不需要把每一个视图树数据的节点都对应一个逻辑树数据的节点，只要逻辑树数据的节点含有对应的视图树数据的节点，即可确定为节点命名一致。例如，若目标UI配置文件中具有如图2中的2.3所示的逻辑树数据，则图2中的2.3所示的逻辑树数据是非法的，虽然逻辑树数据有节点A，但是逻辑树数据的节点F并不在视图树数据当中。

其中，检查所述目标UI配置文件中的逻辑树数据的节点父子结构与所述目标UI工程文件中的视图树数据的节点父子结构的一致性。例如，目标UI工程文件中具有图3中的3.1所示的视图树数据。例如，若目标UI配置文件中具有如图3中的3.2所示的逻辑树数据，则图3中的3.2所示的逻辑树数据是合法的，节点C在A的视图树数据的子树中，节点C在逻辑树数据中只需要作为A的子树即可，而不需要严格还原视图树数据中的父子结构关系。例如，逻辑树数据中每两个节点的最近公共祖先，必然与这两个节点在视图树数据中的最近公共祖先一致。例如，若目标UI配置文件中具有如图3中的3.3所示的逻辑树数据，则图3中的3.3所示的逻辑树数据是非法的，A从B的祖先变成了A的儿子结构。例如，若目标UI配置文件中具有如图3中的3.4所示的逻辑树数据，则图3中的3.4所示的逻辑树数据也是非法的，E本来是B的兄弟结构，变成了B的儿子结构。

其中，检查所述目标UI配置文件中的逻辑树数据的节点类型与所述目标UI工程文件中的视图树数据的节点类型的一致性。例如，目标UI工程文件中具有图4中的4.1所示的视图树数据，B节点为文本节点，C节点为图片节点。例如，若目标UI配置文件中具有如图4中的4.2所示的逻辑树数据，则在逻辑树数据中声明了节点对应数据所关联的UI数据，其中为B节点绑定了UI数据，B节点数据变量名为text_content，为C节点绑定了对应的图片路径，即image_path变量的值。当text_content发生变化时，B节点显示的文本内容也会发生变化，而同理image_path发生变化时，C节点显示的图片内容也会发生变化。

例如，若目标UI配置文件中具有如图4中的4.3所示的逻辑树数据，在图4中的4.3为B节点绑定了对应的图片路径，为C节点绑定了UI数据，而图4中的4.1的视图树数据中的B节点是文本节点，不支持设置图片路径的操作，C节点是图标节点，不支持UI数据，因此图4中的4.3所示的逻辑树数据是错误的。

其中，检查所述目标UI工程文件和目标UI配置文件中所使用的UI数据的一致性。若预先声明了UI数据为text_content、image_path，则如图5中的5.1所示的逻辑树数据是合法的。例如，预先没有声明UI数据变量text_content2，image_path2，则无法取到一个对应值对节点进行操作，则如图5中的5.2所示的逻辑树数据是非法的。其中，若在代码中对不存在的UI数据变量进行操作，可以忽略对所使用的UI数据的一致性的检查，忽略处理后不会导致阻塞性报错与崩溃。

其中，节点命名一致性、节点父子结构一致性、节点类型一致性与所使用的UI数据的一致性，这四类一致性若出现问题，则在游戏运行时会造成严重的错误，比如阻塞游戏流程甚至导致游戏崩溃，在现有方案中，是不会进行数据一致性的检查，因此迭代过程中往往会由于代码或工程文件的提交导致不一致，带来流程阻塞与游戏崩溃。而在申请实施例中，引入了配置文件与编码逻辑的划分逻辑，使得逻辑代码与UI工程文件被UI配置文件这一中间层隔离开来，只需要保证UI配置文件与UI工程文件的一致性，在游戏运行时就不会发生阻塞性报错与崩溃的情况。

其中，当数据检查结果为节点命名一致、节点父子结构一致、节点类型一致与所使用的UI数据一致，确定所述修改文件满足检测条件。

其中，所述当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查，当数据检查结果为节点命名一致性、节点父子结构一致性、节点类型一致性与所使用的UI数据的一致性中的任一种不一致时，确定修改文件不满足检测条件，进而生成一提示信息，该提示信息可以包括显示检测结果的信息以及提示重新更新修改文件的信息，该提示信息用于指示用户根据检测结果重新对未通过检测的修改文件进行调整并重新提交调整后的修改文件。

步骤105，当所述修改文件满足检测条件时，将所述修改文件提交至所述主干程序，以更新所述主干程序中的初版UI逻辑文件。

其中，当修改文件为所述修改后的逻辑代码时，对所述修改后的逻辑代码进行单元测试，若所述单元测试输出的单元测试结果为预期结果，则确定所述修改后的逻辑代码满足检测条件；其中，当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查，若数据检查为节点命名一致、节点父子结构一致、节点类型一致与所使用的UI数据一致，则确定所述修改文件满足检测条件。将满足检测条件的修改文件提交至所述主干程序，以更新所述主干程序中的初版UI逻辑文件。

其中，修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的任一种的提交并无先后顺序，只要任一种修改文件触发修改指令，并满足检测条件时，均可提交至主干，以此将当前版本的修改文件对主干中上一版本的UI逻辑文件进行更新或修改。

其中，当修改文件为所述修改后的逻辑代码时，对所述修改后的逻辑代码进行单元测试，若所述单元测试输出的单元测试结果不为预期结果，则确定所述修改后的逻辑代码不满足检测条件；其中，当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查，若数据检查结果为节点命名一致性、节点父子结构一致性、节点类型一致性与所使用的UI数据的一致性中的任一种不一致时，确定修改文件不满足检测条件。当所述修改文件满足检测条件时，生成一提示信息，该提示信息可以包括显示检测结果的信息以及提示重新更新修改文件的信息，该提示信息用于指示用户根据检测结果重新对未通过检测的修改文件进行调整并重新提交调整后的修改文件。其中，检测结果包括单元测试结果和/或数据检查结果。

上述所有的技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

本申请实施例提供的用户界面的制作方法，通过响应于被触发的提交指令，获取初版UI逻辑文件，其中，初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，UI配置文件不耦合于UI工程文件和逻辑代码；将初版UI逻辑文件提交至主干程序；响应于被触发的修改指令，获取初版UI逻辑文件对应的修改文件，其中修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；对修改文件进行检测；当修改文件满足检测条件时，将修改文件提交至主干程序，以更新主干程序中的初版UI逻辑文件。本申请实施例通过UI配置文件将UI工程文件与逻辑代码进行隔离，减少代码的耦合性，降低UI制作的复杂度以及提升工作效率。

为便于更好的实施本申请实施例的用户界面的制作方法，本申请实施例还提供一种用户界面的制作装置。请参阅图6，图6为本申请实施例提供的用户界面的制作装置的结构示意图。该用户界面的制作装置300可以包括：

第一获取模块301，用于响应于被触发的提交指令，获取初版UI逻辑文件，其中，所述初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，所述UI配置文件独立于所述UI工程文件和逻辑代码；

第一提交模块302，用于将所述初版UI逻辑文件提交至主干程序；

第二获取模块303，用于响应于被触发的修改指令，获取所述初版UI逻辑文件对应的修改文件，其中所述修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；

检测模块304，用于对所述修改文件进行检测；

第二提交模块305，用于当所述修改文件满足检测条件时，将所述修改文件提交至所述主干程序，以更新所述主干程序中的初版UI逻辑文件。

可选的，所述第一获取模块301，用于：

响应于被触发的第一提交指令，获取所述UI工程文件，所述UI工程文件为针对交互设计图预先制作并提交的文件；

响应于被触发的第二提交指令，获取所述逻辑代码，所述逻辑代码为针对所述交互设计图预先制作并提交的代码；

响应于被触发的第三提交指令，获取所述UI配置文件，所述UI配置文件为根据所述交互设计图和所述UI工程文件预先制作并提交的文件；

根据所述UI工程文件、逻辑代码和UI配置文件生成所述初版UI逻辑文件。

可选的，所述UI工程文件、逻辑代码和UI配置文件为通过预设的UI程序逻辑底层框架进行制作得到，其中，所述UI程序逻辑底层框架中UI相关的数据被划分为视图树数据、逻辑树数据和UI数据，所述UI程序逻辑底层框架中UI相关的编码逻辑被划分为视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层。

可选的，通过所述UI程序逻辑底层框架中视图树数据的编辑接口进行制作得到的所述UI工程文件，包括所述视图树数据；通过所述UI程序逻辑底层框架中编码逻辑的编辑接口进行制作得到的所述逻辑代码，包括所述视图树逻辑、逻辑树逻辑、UI数据逻辑和逻辑接口层对应的代码；通过所述UI程序逻辑底层框架中逻辑树数据和UI数据对应的编辑接口进行制作得到的所述UI配置文件，包括所述逻辑树数据和UI数据；其中，所述UI配置文件独立于所述UI工程文件和逻辑代码。

可选的，所述检测模块304，用于：当所述修改文件为修改后的逻辑代码时，对所述修改后的逻辑代码进行单元测试；或者当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查。

可选的，所述检测模块304，用于当所述修改文件为修改后的逻辑代码时，对所述修改后的逻辑代码进行单元测试，包括：基于预设的单元测试工具对所述修改后的逻辑代码进行单元测试，当所述单元测试的输出为预期结果时，确定所述修改后的逻辑代码满足检测条件。

可选的，所述检测模块304，用于所述当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查，包括：

当所述修改文件为修改后的UI工程文件时，对所述修改后的UI工程文件与所述初版UI逻辑文件中的UI配置文件进行数据检查；或者

当所述修改文件为修改后的UI配置文件时，对所述修改后的UI配置文件与所述初版UI逻辑文件中的UI工程文件进行数据检查；或者

当所述修改文件为修改后的UI工程文件和修改后的UI配置文件时，对所述修改后的UI工程文件和修改后的UI配置文件进行数据检查。

可选的，所述检测模块304，用于所述当所述修改文件为修改后的UI工程文件、修改后的UI配置文件中的至少一种时，对当前最新的目标UI工程文件和目标UI配置文件进行数据检查，包括：

检查所述目标UI配置文件中的逻辑树数据的节点命名与所述目标UI工程文件中的视图树数据的节点命名的一致性；

检查所述目标UI配置文件中的逻辑树数据的节点父子结构与所述目标UI工程文件中的视图树数据的节点父子结构的一致性；

检查所述目标UI配置文件中的逻辑树数据的节点类型与所述目标UI工程文件中的视图树数据的节点类型的一致性；

检查所述目标UI工程文件和目标UI配置文件中所使用的UI数据的一致性。

可选的，所述检测模块304，还用于当数据检查结果为节点命名一致、节点父子结构一致、节点类型一致与所使用的UI数据的一致时，确定所述修改文件满足检测条件。

上述所有的技术方案，可以采用任意结合形成本申请的可选实施例，在此不再一一赘述。

本申请实施例提供的用户界面的制作装置300，第一获取模块301响应于被触发的提交指令，获取初版UI逻辑文件，初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，UI配置文件用于将所述UI工程文件与逻辑代码进行隔离；第一提交模块302将初版UI逻辑文件提交至主干程序；第二获取模块303响应于被触发的修改指令，获取初版UI逻辑文件对应的修改文件，其中修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；检测模块304对修改文件进行检测；当修改文件满足检测条件时，第二提交模块305将修改文件提交至主干程序，以更新主干程序中的初版UI逻辑文件。本申请实施例通过UI配置文件将UI工程文件与逻辑代码进行隔离，可以独立处理逻辑代码、UI工程文件、UI配置文件，减少了代码的耦合性，降低UI制作的复杂度以及提升工作效率。

相应的，本申请实施例还提供一种计算机设备，该计算机设备可以为终端或者服务器，该终端可以为智能手机、平板电脑、笔记本电脑、触控屏幕、游戏机、个人计算机、个人数字助理等终端设备。如图7所示，图7为本申请实施例提供的计算机设备的结构示意图。该计算机设备400包括有一个或者一个以上处理核心的处理器401、有一个或一个以上计算机可读存储介质的存储器402及存储在存储器402上并可在处理器上运行的计算机程序。其中，处理器401与存储器402电性连接。本领域技术人员可以理解，图中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

处理器401是计算机设备400的控制中心，利用各种接口和线路连接整个计算机设备400的各个部分，通过运行或加载存储在存储器402内的软件程序和/或模块，以及调用存储在存储器402内的数据，执行计算机设备400的各种功能和处理数据，从而对计算机设备400进行整体监控。

在本申请实施例中，计算机设备400中的处理器401会按照如下的步骤，将一个或一个以上的应用程序的进程对应的指令加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序，从而实现各种功能：

响应于被触发的提交指令，获取初版UI逻辑文件，其中，所述初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，所述UI配置文件独立于所述UI工程文件和逻辑代码；将所述初版UI逻辑文件提交至主干程序；响应于被触发的修改指令，获取所述初版UI逻辑文件对应的修改文件，其中所述修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；对所述修改文件进行检测；当所述修改文件满足检测条件时，将所述修改文件提交至所述主干程序，以更新所述主干程序中的初版UI逻辑文件。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

在一些实施例中，如图7所示，计算机设备400还包括：触控显示屏403、射频电路404、音频电路405、输入单元406以及电源407。其中，处理器401分别与触控显示屏403、射频电路404、音频电路405、输入单元406以及电源407电性连接。本领域技术人员可以理解，图7中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

触控显示屏403可用于显示图形用户界面以及接收用户作用于图形用户界面产生的操作指令。触控显示屏403可以包括显示面板和触控面板。其中，显示面板可用于显示由用户输入的信息或提供给用户的信息以及计算机设备的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。在一些实施例中，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode，OLED)等形式来配置显示面板。触控面板可用于收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板上或在触控面板附近的操作)，并生成相应的操作指令，且操作指令执行对应程序。在一些实施例中，触控面板可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器401，并能接收处理器401发来的命令并加以执行。触控面板可覆盖显示面板，当触控面板检测到在其上或附近的触摸操作后，传送给处理器401以确定触摸事件的类型，随后处理器401根据触摸事件的类型在显示面板上提供相应的视觉输出。在本申请实施例中，可以将触控面板与显示面板集成到触控显示屏403而实现输入和输出功能。但是在某些实施例中，触控面板与触控面板可以作为两个独立的部件来实现输入和输出功能。即触控显示屏403也可以作为输入单元406的一部分实现输入功能。

射频电路404可用于收发射频信号，以通过无线通信与网络设备或其他计算机设备建立无线通讯，与网络设备或其他计算机设备之间收发信号。

音频电路405可以用于通过扬声器、传声器提供用户与计算机设备之间的音频接口。音频电路405可将接收到的音频数据转换后的电信号，传输到扬声器，由扬声器转换为声音信号输出；另一方面，传声器将收集的声音信号转换为电信号，由音频电路405接收后转换为音频数据，再将音频数据输出处理器401处理后，经射频电路404以发送给比如另一计算机设备，或者将音频数据输出至存储器402以便进一步处理。音频电路405还可能包括耳塞插孔，以提供外设耳机与计算机设备的通信。

输入单元406可用于接收输入的数字、字符信息或用户特征信息(例如指纹、虹膜、面部信息等)，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

电源407用于给计算机设备400的各个部件供电。在一些实施例中，电源407可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源407还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管图7中未示出，计算机设备400还可以包括摄像头、传感器、无线保真模块、蓝牙模块等，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

由上可知，本实施例提供的计算机设备，通过响应于被触发的提交指令，获取初版UI逻辑文件，其中，初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，UI配置文件用于将所UI工程文件与逻辑代码进行隔离；将初版UI逻辑文件提交至主干程序；响应于被触发的修改指令，获取初版UI逻辑文件对应的修改文件，其中修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；对修改文件进行检测；当修改文件满足检测条件时，将修改文件提交至主干程序，以更新主干程序中的初版UI逻辑文件。本申请实施例通过UI配置文件将UI工程文件与逻辑代码进行隔离，可以独立处理逻辑代码、UI工程文件、UI配置文件，减少了代码的耦合性，降低UI制作的复杂度以及提升工作效率。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请实施例提供一种计算机可读存储介质，其中存储有多条计算机程序，该计算机程序能够被处理器进行加载，以执行本申请实施例所提供的任一种用户界面的制作方法中的步骤。例如，该计算机程序可以执行如下步骤：

响应于被触发的提交指令，获取初版UI逻辑文件，其中，所述初版UI逻辑文件划分为UI工程文件、逻辑代码和UI配置文件，所述UI配置文件独立于所述UI工程文件和逻辑代码；将所述初版UI逻辑文件提交至主干程序；响应于被触发的修改指令，获取所述初版UI逻辑文件对应的修改文件，其中所述修改文件包括修改后的逻辑代码、修改后的UI工程文件、修改后的UI配置文件中的至少一种；对所述修改文件进行检测；当所述修改文件满足检测条件时，将所述修改文件提交至所述主干程序，以更新所述主干程序中的初版UI逻辑文件。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

其中，该存储介质可以包括：只读存储器(Read Only Memory，ROM)、随机存取记忆体(Random Access Memory，RAM)、磁盘或光盘等。

由于该存储介质中所存储的计算机程序，可以执行本申请实施例所提供的任一种用户界面的制作方法中的步骤，因此，可以实现本申请实施例所提供的任一种用户界面的制作方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的一种用户界面的制作方法、装置、存储介质及计算机设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。