处理方法、装置、电子设备及存储介质与流程

1.本技术涉及软件技术领域，更具体地说，涉及一种处理方法、装置、电子设备及存储介质。


背景技术：

2.现阶段，用户在低编译平台通过快速搭建交互表单应用并绑定远程服务的api(application programinterface，应用程序接口)，以实现交互表单应用的动态数据交互能力。在此过程中，用户在搭建动态数据表单应用时，会存在多种表单组件和api的方案选择，但不同搭建方案会产生不同的性能差异，从而影响用户体验。
3.对此，如何让搭建交互表单的用户快速获得满足要求的api方案，成为现阶段亟需解决的问题。


技术实现要素：

4.有鉴于此，本技术提供一种处理方法、装置、电子设备及存储介质，技术方案如下：
5.本技术一方面提供一种处理方法，所述方法包括：
6.确定目标应用下已绑定应用程序接口api的目标交互表单，所述目标应用为低编译平台的未发布应用；
7.获得所述目标交互表单所绑定的第一api的业务指标，至少基于所述第一api的业务指标确定所述目标交互表单在所述第一api下的响应性能。
8.优选的，所述获得所述目标交互表单所绑定的第一api的业务指标，包括：
9.调用api业务指标库，所述业务指标库中各api的业务指标是通过聚类统计分析所述低编译平台的已发布应用对各api的调用日志所确定的；
10.在所述api业务指标库中确定所述第一api的业务指标。
11.优选的，所述业务指标至少包含请求返回时长，所述至少基于所述第一api的业务指标确定所述目标交互表单在所述第一api下的响应性能，包括：
12.获得所述目标交互表单对所述第一api的调用状态；
13.如果所述调用状态为连续调用，则将所述第一api的请求返回时长的累加和作为所述目标交互表单在所述第一api下的表单响应时长；
14.如果所述调用状态为非连续调用，则对所述第一api的请求返回时长执行运算，将相应的运算结果作为所述目标交互表单在所述第一api下的表单响应时长。
15.优选的，所述方法还包括：
16.确定与所述第一api具有相似性的第二api；
17.获得所述第二api的业务指标，至少基于所述第二api的业务指标确定所述目标交互表单在所述第二api下的响应性能；
18.通过比对所述目标交互表单在所述第一api和所述第二api下的响应性能，从所述第一api和所述第二api中选取响应性能最优的目标api。
19.优选的，所述确定与所述第一api具有相似性的第二api，包括：
20.调用api相似库，所述api相似库中两个api的相似度是通过分析所述低编译平台的已发布应用对两个api的调用日志中的请求和返回数据所确定的；
21.在所述api相似库中确定与所述第一api的相似度满足对应阈值的api作为所述第二api。
22.优选的，所述方法还包括：
23.在所述目标api为所述第一api的情况下，基于所述第一api输出相应的提示信息；或
24.在所述目标api为所述第二api的情况下，基于所述第二api输出相应的推荐信息。
25.本技术另一方面提供一种处理装置，所述装置包括：
26.表单确定模块，用于确定目标应用下已绑定应用程序接口api的目标交互表单，所述目标应用为低编译平台的未发布应用；
27.性能确定模块，用于获得所述目标交互表单所绑定的第一api的业务指标，至少基于所述第一api的业务指标确定所述目标交互表单在所述第一api下的响应性能。
28.优选的，所述性能确定模块获得所述目标交互表单所绑定的第一api的业务指标，包括：
29.调用api业务指标库，所述业务指标库中各api的业务指标是通过聚类统计分析所述低编译平台的已发布应用对各api的调用日志所确定的；在所述api业务指标库中确定所述第一api的业务指标。
30.本技术另一方面提供一种电子设备，所述电子设备包括：
31.存储器，用于存储应用程序及所述应用程序运行所产生的数据；
32.处理器，用于执行所述应用程序，以实现功能：确定目标应用下已绑定应用程序接口api的目标交互表单，所述目标应用为低编译平台的未发布应用；获得所述目标交互表单所绑定的第一api的业务指标，至少基于所述第一api的业务指标确定所述目标交互表单在所述第一api下的响应性能。
33.本技术另一方面提供一种存储介质，所述存储介质存储有计算机程序代码，所述计算机程序代码执行时实现任意一项所述的处理方法。
34.经由上述的技术方案可知，本技术提供的处理方法，对于低编译平台的未发布应用，即处于搭建阶段的目标应用，可以确定该目标应用下已绑定api的目标交互表单，进而获得该目标交互表单所绑定的第一api的业务指标，并至少基于该第一api的业务指标确定目标交互表单在该第一api下的响应性能。由此，本发明能够支持应用搭建阶段快速评估用户所选择表单方案的响应性能，以使用户灵活调整优化表单方案。
附图说明
35.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
36.图1为本技术实施例提供的电子设备的硬件结构框图；
37.图2为本技术实施例提供的处理方法的方法流程图；
38.图3为本技术实施例提供的另一处理方法的方法流程图；
39.图4为本技术实施例提供的另一处理方法的方法流程图；
40.图5为本技术实施例提供的另一处理方法的方法流程图；
41.图6为本技术实施例提供的另一处理方法的方法流程图；
42.图7为本技术实施例提供的处理场景的场景示意图；
43.图8为本技术实施例提供的处理装置的结构示意图。
具体实施方式
44.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
45.为使本技术的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本技术作进一步详细的说明。
46.为方便理解本技术，以下首先对低编译平台搭建交互表单应用并绑定远程服务的api的背景进行说明：
47.应用开发的阶段，通常会涉及到前端开发和后端开发。前端开发的过程中，美工涉及应用产品原型，比如前端页面中交互表单的图片，由开发人员以代码编写的方式将交互表单的图片转换为一定格式，比如html格式的能够被浏览器所识别的网页，这个过程中前端开发的网页并不具备动态数据交互能力，由此就需要后端开发。后端的开发过程中，开发人员以代码编写的方式开发后端的程序。后端的程序用于执行业务逻辑运算，比如对特定数据库中的数据进行增删改查等操作。
48.而为了实现前端与后端的对接，后端的开发人员需要将后端程序暴露为api，再由前端的开发人员将网页形式的交互表单与api进行绑定。由此，应用的整个开发过程繁琐、效率低、成本高。需要说明的是，与api绑定的交互表单即为动态数据表单，动态数据表单中的交互数据来自于api，本发明实施例中的交互表单为动态数据表单。
49.为解决该问题，简化应用的开发，低编译平台可以开发并封装大量的表单组件，表单组件则可以被重复使用，以拖拽表单组件的方式来实现应用开发，表单组件可以包括诸如输入框、下拉框、长文本编辑框等基础组件、还可以包含由多个基础组件组合得到的复杂组件。以前端设计交互表单为例，无需通过设计图和开发程序转换，前端的开发人员以一定的逻辑关系或者一定的设计布局通过拖拽交互表单相关的表单组件就可完成交互表单的设计，这就可以将交互表单的开发时间由通常的一个星期降低为短短数个小时。
50.前端开发人员在低编译平台搭建动态数据表单应用时，对于交互表单的表单组件其可以有多种api的方案选择，但不同搭建方案会产生不同的性能差异。现有解决方案，总结有如下两种：
51.1)通过应用搭建预览，对表单交互性能进行初略评估。这种方式的性能评估误差较大，预览所采用的远程服务api一般基于人工模拟数据，很难反映出真实的交互性能。
52.2)在动态数据表单应用发布后的使用过程中，再对应用性能进行优化。这种方法
的灵活性较差，而且在运行时优化应用性能的成本较高，例如要重启应用则需要考虑对现有业务的影响。
53.为解决上述现有方案的弊端，本技术提供一种处理方法。由于动态数据表单的性能主要由远程服务api的响应性能来决定，因此获得动态数据表单所绑定的api业务指标(即性能指标)就可以估算动态数据表单的响应性能，从而可以在用户搭建交互表单过程中，对用户所选api方案进行性能评估。
54.本技术提供的处理方法可以应用于电子设备，参见图1所示的电子设备的硬件结构框图，该电子设备的硬件结构可以包括：处理器11、通信接口12，存储器13和通信总线14；
55.在本技术实施例中，处理器11、通信接口12、存储器13、通信总线14的数量为至少一个，且处理器11、通信接口12、存储器13通过通信总线14完成相互间的通信。
56.处理器11可以是一个中央处理器cpu、gpu(graphics processing unit，图形处理器)，或者是特定集成电路asic(application specific integrated circuit)，或者是被配置成实施本技术实施例的一个或多个集成电路等。
57.存储器13可以包括高速ram存储器，也可以还包括非易失性存储器(non-volatile memory)等，例如至少一个磁盘存储器。
58.其中，存储器13存储应用程序及应用程序运行所产生的数据，处理器11则执行应用程序，以实现功能：
59.确定目标应用下已绑定应用程序接口api的目标交互表单，目标应用为低编译平台的未发布应用；获得目标交互表单所绑定的第一api的业务指标，至少基于第一api的业务指标确定目标交互表单在第一api下的响应性能。
60.需要说明的是，处理器执行应用程序所实现功能的细化和扩展，可以参见下文描述。
61.本技术实施例提供一种处理方法，参见图2所示的方法流程图，该方法包括如下步骤：
62.s101，确定目标应用下已绑定应用程序接口api的目标交互表单，目标应用为低编译平台的未发布应用。
63.本技术实施例中，前端的开发人员通过低编译平台可以搭建交互表单应用，以拖拽表单组件的方式生成该应用下的交互表单，并为该交互表单绑定api以获得动态数据交互能力。因此，对于在低编译平台处于搭建阶段而未发布的应用(即目标应用)，本技术可以对该目标应用下用户所选的已绑定api的交互表单(即目标交互表单)分析。
64.前端的开发人员在低编译平台搭建交互表单应用的过程中，其以拖拽表单组件的方式生成该应用下某一交互表单时，可以按照该表单组件所实现的业务功能为该表单组件绑定合适的api，一个表单组件可以绑定一个或多个api。
65.为方便理解，举例来说明，前端的开发人员在低编译平台搭建交互表单应用a，以拖拽表单组件的方式生成该应用a下的至少一个交互表单，比如包括两个交互表单a_1和a_2。假设，交互表单a_1为前端的开发人员所选的绑定api的交互表单，则在确定前端的开发人员对交互表单a_1的某一表单组件绑定api的操作结束后，可以对该表单组件所绑定的api进行分析。
66.s102，获得目标交互表单所绑定的第一api的业务指标，至少基于第一api的业务
指标确定目标交互表单在第一api下的响应性能。
67.本技术实施例中，对于目标交互表单，可以对其所绑定的api(即第一api)进行业务分析，以获得该第一api的业务指标，该第一api的业务指标可以通过分析该第一api在低编译平台的已发布的交互表单应用中的业务性能来确定，具体可以通过设计自动采集任务来监控和分析运行环境中第一api的调用状态所实现。第一api的业务指标一方面可以包含时间维度下的业务指标，比如请求时长，以此体现响应性能的反应速度，另一方面可以包含内容维度下的业务指标，比如请求返回数据的准确率(或者失败率)，以此体现响应性能的稳定性。
68.进一步，由于交互表单的动态数据交互性能主要取决于所绑定的api的业务性能，因此根据api业务指标可以估算出该交互表单在第一api下的响应性能。
69.为方便理解，以下对api在已发布应用中的动态数据交互过程进行说明：
70.通过交互表单应用发布，安装部署应用，应用可以在正式环境中启动，使用者则可以使用该应用。使用者在使用已发布应用的过程中，可以在前端的交互表单中对某一表单组件所对应的数据项进行信息输入，进而触发该交互表单调用该表单组件所绑定的api，向该api发送对应的一组参数，由该api所对应的后台程序执行业务逻辑运算，并由该api将运算结果返回给前端，由前端按照定义的形式进行展示。由此，完成api在一个已发布应用中的动态数据交互。
71.而在实际业务中，一个api可以与一个或多个已发布应用的交互表单所绑定。举例来说，api1可以同时被已发布的表单应用b和表单应用c的交互表单所绑定，另外，api1还可以同时被应用b或者应用c下多个交互表单所绑定。
72.为方便理解，继续以目标应用为应用a、目标交互表单为交互表单a_1为例进行说明。确定前端的开发人员对交互表单a_1的某一表单组件绑定api1的操作结束后，可以对api1在已发布应用中的业务性能进行业务分析，以获得该api1的业务指标。
73.继续假设api1同时被应用b的交互表单b_1和交互表单b_2、以及应用c的交互表单c_1所绑定，则可以通过分析api1在应用b和应用c业务性能来确定该api1的业务指标。通过设计自动采集任务来自动监控和分析运行环境中api1被应用b和应用c的调用状态，利用聚类统计分析来计算得到api1的业务指标。
74.继续假设业务指标包含请求时长，api1被应用b调用m次、且m次请求返回时长分别为a1、a2、
……
、am，api1被应用c调用n次、且n次请求返回时长分别为b1、b2、
……
、bn。则，api1的请求时长可以通过聚类分析统计m+n个请求返回时长(包括a1～am、以及b1～bn)来确定，具体的可以为a1～am、以及b1～bn中的最短返回时长、最长返回时长、平均返回时长、95％请求返回时长等，本技术实施例对此不做限定。需要说明的是，95％请求返回时长是按照请求返回时长由小到大的次序对m+n个请求返回时长进行正态的分布的排序，从最小的请求返回时长起m+n中95％的平均时长。api的请求时长越大、就表示api1响应性能的反应速度越慢。
75.而根据api1的请求时长估算交互表单a_1在api1下的响应性能时，可以对api1的请求时长进行评估、api1的请求时长越大、其响应性能就越差。具体的，可以设置多个响应等级、且每个响应等级对应一个请求时长范围，由此可以根据api1的请求时长所在的请求时长范围来确定其响应等级，当然，api1的请求时长越大、则其响应等级也就越低、相应的
响应性能就越差。
76.继续假设业务指标包含请求返回数据的准确率，由于api的请求返回数据中一般包含一个状态码，该状态码用于表征远程服务api成功(比如状态码为1)/失败(比如状态码0)，因此通过解析请求返回数据中的状态码即可确定本次调用成功/失败。api1被应用b调用m次、且m次请求返回数据中有c次状态码为0、有d次状态码为1(c+d＝m)，api1被应用c调用n次、且n次请求返回数据中有e次状态码为0、有f次状态码为1(e+f＝n)。则，api1的请求返回数据的准确率可以为d+f/m+n，准确率越大、就表示api1响应性能越稳定。当然，如果业务指标包含请求返回数据的失败率，则api1的请求返回数据的失败率为c+e/m+n，失败率越大、就表示api1响应性能越不稳定。
77.而根据api1的请求返回数据的准确率估算交互表单a_1在api1下的响应性能时，可以对api1的请求返回数据的准确率进行评估、api1的请求返回数据的准确率越大、其响应性能就越好。具体的，可以设置多个响应等级、且每个响应等级对应一个准确率范围，由此可以根据api1的请求返回数据的准确率所在的准确率范围来确定其响应等级，当然，api1的请求返回数据的准确率越大、其响应等级也就越高、相应的响应性能就越好。
78.需要说明的是，如果业务指标同时包含请求时长和请求返回数据的准确率，则可以按照上述方案确定api1的请求时长所在的响应等级(后续称之为第一响应等级)、以及api1的请求返回数据的准确率所在的响应等级(后续称之为第二响应等级)后，可以考虑具体业务场景来确定请求时长和请求返回数据的准确率两者的优先级，以此对第一响应等级和第二响应等级做出相应的处理，比如加权平均，以此来确定最终的响应等级，最终的响应等级越高、就表示交互表单a_1在api1下的响应性能越好。
79.基于此，可以将交互表单a_1在api1下的响应性能进行输出，以使前端的开发人员快速获得交互表单a_1在api1下的响应性能，进而为其继续选择绑定api1、还是选择绑定其它的api做出参考。
80.本技术实施例提供的处理方法，对于低编译平台的处于搭建阶段的目标应用，可以确定该目标应用下已绑定api的目标交互表单，进而获得该目标交互表单所绑定的第一api的业务指标，并至少基于该第一api的业务指标确定目标交互表单在该第一api下的响应性能。由此，本发明能够支持应用搭建阶段快速评估用户所选择表单方案的响应性能，以使用户灵活调整优化表单方案。
81.作为获得目标交互表单所绑定的第一api的业务指标的一种实现方式，本技术实施例提供另一种处理方法，参见图3所示的方法流程图，该方法包括如下步骤：
82.s201，确定目标应用下已绑定应用程序接口api的目标交互表单，目标应用为低编译平台的未发布应用。
83.s202，调用api业务指标库，业务指标库中各api的业务指标是通过聚类统计分析低编译平台的已发布应用对各api的调用日志所确定的。
84.本技术实施例中，可以设计自动采集任务来监控和分析运行环境中各api的调用状态，以此构建api业务指标库，该api业务指标库中包含不同api的业务指标。
85.对于在低编译平台的已发布的交互表单应用，该应用可以监控其交互表单所绑定的各api在其运行环境中的调用状态，并将调用状态写入至调用日志中，将该调用日志实时上报。本技术实施例中，则可以综合各应用所上报各api的调用日志，进而利用聚类统计分
析来计算得到各api的业务指标，并将所得到的各api的业务指标实时录入api业务指标库。
86.为方便理解，以某一时段内运行的已发布应用包括应用b、应用c和应用d为例进行说明。应用b、应用c和应用d在各自运行环境中分别监控其交互表单所调用的api，进而将api的调用状态，比如请求发送时间、请求响应时间、请求返回时长、请求数据、返回数据、是否连续调用(即对该api的调用是否被其他api所触发、或者其是否触发其它api的调用)等信息写入至调用日志，并实时上报。
87.继续假设，应用b所上报的调用日志中包含api2、api3的调用状态、应用c所上报的调用日志中包含api3、api4的调用状态、应用d所上报的调用日志则包含api2和api4的调用状态，则api2的业务指标则可以聚类统计分析应用b和应用d所上报的api2的调用状态来计算、api3的业务指标则可以聚类统计分析应用b和应用c所上报的api3的调用状态来计算、api4的业务指标则可以聚类统计分析应用c和应用d所上报的api4的调用状态来计算。而对api的调用状态的聚类分析过程可以参考上述实施例中api1的业务指标的聚类统计分析过程，在此不再赘述，业务指标可以包含请求时长和请求返回数据的准确率。
88.s203，在api业务指标库中确定第一api的业务指标。
89.本技术实施例中，在确定第一api后，可以通过在api业务指标库中进行api匹配来获得该第一api的业务指标。
90.s204，至少基于第一api的业务指标确定目标交互表单在第一api下的响应性能。
91.本技术实施例提供的处理方法，对于低编译平台的处于搭建阶段的目标应用，在确定该目标应用下已绑定api的目标交互表单后，可以在预先搭建的api业务指标库中获得该目标交互表单所绑定的第一api的业务指标，这就可以快速获得第一api的业务指标，进而快速估算目标交互表单在该第一api下的响应性能，以及时提醒用户灵活优化表单方案。
92.作为至少基于第一api的业务指标确定目标交互表单在第一api下的响应性能的一种实现方式，本技术实施例提供另一种处理方法，包括如下步骤：
93.s301，确定目标应用下已绑定应用程序接口api的目标交互表单，目标应用为低编译平台的未发布应用。
94.s302，获得目标交互表单所绑定的第一api的业务指标，业务指标至少包含请求返回时长。
95.s303，获得目标交互表单对第一api的调用状态。
96.本技术实施例中，如上述实施例说明，api的调用状态可以包含所属api的请求发送时间、请求响应时间、请求返回时长、请求数据、请求返回数据、是否连续调用等信息。
97.因此，对于目标交互表单所绑定的某一api，其如果为连续调用，则说明该api的调用是被其他api的触发的。因此，对于第一api，其由多个api所组成，即目标交互表单的被拖拽的表单组件所绑定的api有多个。假设，前端的开发人员在低编译平台拖拽表单组件x，并且为其绑定api5、api6和api7，即api5、api6和api7为第一api。如果前端的开发人员配置api5调用api6、api6调用api7，即api5、api6和api7的调用状态中均为连续调用；如果前端的开发人员配置api5调用api6、api7不涉及任何调用，则api5和api6的调用状态中为连续调用、api7的调用状态为非连续调用；如果前端的开发人员配置api5、api6和api7均不涉及任何调用，则api5、api6和api7的调用状态中均为非连续调用。
98.s304，如果调用状态为连续调用，则将第一api的请求返回时长的累加和作为目标
交互表单在第一api下的表单响应时长。
99.本技术实施例中，为方便理解，继续以表单组件x所绑定的api5、api6和api7均为连续调用为例进行说明，则可以将api5、api6和api7的请求返回时长的累加和作为目标交互表单在第一api下的表单响应时长。
100.另外，如果表单组件x所绑定的api5、api6均为连续调用、而api7为非连续调用，则首先计算api5和api6的请求返回时间的累加和，再进一步将该累加和与api7的请求返回时间执行运算，比如加权平均，以此获得目标交互表单在第一api下的表单响应时长。
101.s305，如果调用状态为非连续调用，则对第一api的请求返回时长执行运算，将相应的运算结果作为目标交互表单在第一api下的表单响应时长。
102.本技术实施例中，为方便理解，继续以表单组件x所绑定的api5、api6和api7均为非连续调用为例进行说明，则可以对api5、api6和api7的请求返回时长执行运算，比如加权平均，以此获得目标交互表单在第一api下的表单响应时长。
103.本技术实施例提供的处理方法，对于低编译平台的处于搭建阶段的目标应用，在确定该目标应用下已绑定api的目标交互表单后，通过获得目标交互表单对其所绑定的第一api的调用状态是确定目标交互表单在该第一api下的表单响应时长，以此来估算响应性能。
104.本技术实施例提供另一处理方法，参见图5所示的方法流程图，该方法包括如下步骤：
105.s401，确定目标应用下已绑定应用程序接口api的目标交互表单，目标应用为低编译平台的未发布应用。
106.s402，获得目标交互表单所绑定的第一api的业务指标，至少基于第一api的业务指标确定目标交互表单在第一api下的响应性能。
107.s403，确定与第一api具有相似性的第二api。
108.本技术实施例中，可以设计自动采集任务来监控和分析运行环境中各api的调用状态，该调用状态中包含请求和返回数据，该请求和返回数据则包括请求数据和返回数据两类数据。对于请求数据和返回数据，其中均包含属性和属性值。
109.对于在低编译平台的已发布的交互表单应用，该应用可以监控其交互表单所绑定的各api在其运行环境中的调用状态，并将调用状态写入至调用日志中，将该调用日志实时上报。本技术实施例中，则可以综合各应用所上报各api的调用日志，进而解析调用日志来获得各api对应的请求和返回数据。由此，可以获得第一api、以及其它api各自所对应的请求和返回数据。
110.对于第一api以及其它任意一个api，分别比对两个api请求数据中的属性和属性值、以及返回数据中的属性和属性值，以此来确定两个api在属性和属性值下的相似度，举例来说，第一api与某个api的属性中有90％的属性名称和类型完全相同、且相同属性的属性值也多次重合，则两个api的相似度很高。
111.为方便理解，继续假设第一api为api1、且api1同时被已发布的表单应用e和表单应用f的交互表单所绑定。假设某一时段内应用e和应用f均上报对api的调用日志，因此通过解析应用e和应用f的调用日志可以获得api1对应的请求和返回数据，假设api1被应用e调用p次、被应用f调用q次，则解析获得的api1对应的请求和返回数据包含p+q条，每条请求
和返回数据均包含请求数据中的属性和属性值、以及返回数据中的属性和属性值。
112.同理，对于除api1以外的其它api，通过解析绑定其的已发布的表单应用所上报的调用日志也可获得其对应的请求和返回数据。假设，其它api为api2、且api2同时被已发布的表单应用g和表单应用h所绑定。假设某一时段内应用g和应用h均上报对api的调用日志，因此通过解析应用g和应用h的调用日志可以获得api2对应的请求和返回数据，假设api2被应用g调用s次、被应用h调用t次，则解析获得的api2对应的请求和返回数据包含s+t条，每条请求和返回数据均包含请求数据中的属性和属性值、以及返回数据中的属性和属性值。
113.基于此，为获得api1与api2的相似性，可以比对api1对应的p+q条请求数据与api2对应的s+t条请求数据中的属性和属性值，确定请求数据中api1与api2属性名称和类型完全相同的属性的占比(后续称之为第一占比)、以及相同属性的属性值重合的占比(后续称之为第二占比)。继续比对api1对应的p+q条返回数据与api2对应的s+t条返回数据中的属性和属性值，确定返回数据中api1与api2属性名称和类型完全相同的属性的占比(后续称之为第三占比)、以及相同属性的属性值重合的占比(后续称之为第四占比)。由此，根据第一占比和第三占比确定api1和api2的属性的相似度、以及，根据第二占比和第四占比确定api1和api2的属性值的相似度，进而综合属性的相似度以及属性值的相似度来确定api1与api2相似度。
114.需要说明的是，第一占比与第三占比均与属性的相似度正相关、第二占比与第四占比均与属性值的相似度正相关、属性的相似度和属性值的相似度也均与api间的相似度正相关，属性值的相似度、属性值的相似度、以及api间的相似度的计算方式可以根据实际场景来设置，比如可以采用加权平均的方式来处理，在此不做限定。
115.还需要说明的是，在一些场景中，还可以采用现有的相似度算法，比如最短编辑距离算法来计算api间的相似度。继续以上述api1和api2为例进行说明，对于api1对应的p+q条请求数据与api2对应的s+t条请求数据中的属性和属性值，可以采用最短编辑距离算法计算api1和api2在请求数据维度下的相似度；而对于api1对应的p+q条返回数据与api2对应的s+t条返回数据中的属性和属性值，可以采用最短编辑距离算法计算api1和api2在返回数据维度下的相似度；进而综合请求数据维度下的相似度和请求数据维度下的相似度来确定api1与api2相似度，比如可以采用加权平均的方式来确定，本技术对此不做限定。
116.基于此获得api1与api2的相似度之后，可以基于该相似度确定是否api2与api是否具有相似性，比如可以设置阈值，高于该阈值即可确定api2与api具有相似性，反之，则不具有。
117.s404，获得第二api的业务指标，至少基于第二api的业务指标确定目标交互表单在第二api下的响应性能。
118.本技术实施例中，第二api的业务指标的获得方式、以及目标交互表单在第二api下的响应性能的确定方式可以参见第一api业务指标的获得方式、以及目标交互表单在第一api下的响应性能的确定方式，在此不再赘述。
119.s405，通过比对目标交互表单在第一api和第二api下的响应性能，从第一api和第二api中选取响应性能最优的目标api。
120.本技术实施例中，继续以响应性能以响应等级来表示来说明。对比第一api和第二api的响应等级，以响应等级较高的api作为目标api，推荐给用户。
121.在此基础上，在目标api为第一api的情况下，基于第一api输出相应的提示信息；或
122.在目标api为第二api的情况下，基于第二api输出相应的推荐信息。
123.本技术实施例中，针对低编译平台用户所选的表单方案，如果用户当前所选的方案已是最优的，则不会推荐其他api，可以提示用户当前所选择的方案已是最优方案。反之，如果还存在其他更优的方案，则向用户推荐响应性能更好的api，以使用户对表单方案进行优化调整，最终可以实现高质量表单应用的搭建。
124.本技术实施例提供的处理方法，一方面支持应用搭建阶段快速评估用户所选择表单方案的响应性能，另外还可以基于相似度分析和api性能指标分析给用户推荐响应性能最优的api方案，提升应用搭建效率。
125.作为确定与第一api具有相似性的第二api的一种实现方式，本技术实施例提供另一种处理方法，参见图6所示的方法流程图，该方法包括如下步骤：
126.s501，确定目标应用下已绑定应用程序接口api的目标交互表单，目标应用为低编译平台的未发布应用。
127.s502，获得目标交互表单所绑定的第一api的业务指标，至少基于第一api的业务指标确定目标交互表单在第一api下的响应性能。
128.s503，调用api相似库，api相似库中两个api的相似度是通过分析低编译平台的已发布应用对两个api的调用日志中的请求和返回数据所确定的。
129.本技术实施例中，可以自动采集任务来监控和分析运行环境中各api的调用状态，以此构建api相似库，该api相似库中包含api之间的相似度。
130.对于在低编译平台的已发布的交互表单应用，该应用可以监控其交互表单所绑定的各api在其运行环境中的调用状态，并将调用状态写入至调用日志中，将该调用日志实时上报。本技术实施例中，则可以综合各应用所上报各api的调用日志，进而解析调用日志来获得各api对应的请求和返回数据。
131.而对于任意两个获得请求和返回数据的api，可以对这两个api进行相似度分析，具体分析过程可以参见上述实施例中api1与api2的相似度的分析过程，以此可以获得这两个api的相似度。
132.s504，在api相似库中确定与第一api的相似度满足对应阈值的api作为第二api。
133.本技术实施例中，在api相似库可以检索与第一api的相似度高于对应阈值的api作为第二api。
134.s505，获得第二api的业务指标，至少基于第二api的业务指标确定目标交互表单在第二api下的响应性能。
135.s506，通过比对目标交互表单在第一api和第二api下的响应性能，从第一api和第二api中选取响应性能最优的目标api。
136.本技术实施例中，通过预先搭建api相似度能够快速获得目标交互表单所绑定的第一api具有相似性的api，以此快速向用户推荐响应性能最优的api方案，显著提升应用搭建效率。
137.参见图7所示的处理场景。设计自动采集任务来采集api调用日志，自动监控和分析运行环境中api的调用状态，一方面计算诸如请求时长和请求返回数据的准确率的api业
务指标(即性能指标)，以此搭建api业务指标库；另一方面基于请求和返回数据对不同api进行相似度分析，生成api相似关系数据(即api间的相似度)，以此搭建api相似库。
138.用户(前端的开发人员)在低编译平台搭建交互表单应用，在搭建过程中，以拖拽表单组件的方式生成交互表单并绑定api。由于交互表单的动态数据交互性能主要取决于所绑定的api的业务性能，因此根据用户所选交互表单绑定的api的标识，从api业务指标库中获得该api的业务指标，进而估算交互表单在该api下的响应性能。
139.另外，根据用户所选交互表单绑定的api的标识，从api相似库中检索与其具有相似性的api，并从api业务指标库中获得该api的业务指标，进而估算交互表单在该api下的响应性能。通过比对用户所选交互表单绑定的api的响应性能、以及具有相似性的api的响应性能，向用户推荐最优性能的api。如果用户当前所选的方案已是最优的，则不会推荐其他api，可以提示用户当前所选择的方案已是最优方案。反之，如果还存在其他更优的方案，则向用户推荐响应性能更好的api，以使用户对表单方案进行优化调整，最终可以实现高质量表单应用的搭建。
140.与上述实施例提供的处理方法对应的，本技术实施例则提供一种处理装置，如图8所示，该装置包括：
141.表单确定模块10，用于确定目标应用下已绑定应用程序接口api的目标交互表单，目标应用为低编译平台的未发布应用；
142.性能确定模块20，用于获得目标交互表单所绑定的第一api的业务指标，至少基于第一api的业务指标确定目标交互表单在第一api下的响应性能。
143.在本技术公开的处理装置的另一实施例中，性能确定模块20获得目标交互表单所绑定的第一api的业务指标，包括：
144.调用api业务指标库，业务指标库中各api的业务指标是通过聚类统计分析低编译平台的已发布应用对各api的调用日志所确定的；在api业务指标库中确定第一api的业务指标。
145.在本技术公开的处理装置的另一实施例中，业务指标至少包含请求返回时长，性能确定模块20至少基于第一api的业务指标确定目标交互表单在第一api下的响应性能，包括：
146.获得目标交互表单对第一api的调用状态；如果调用状态为连续调用，则将第一api的请求返回时长的累加和作为目标交互表单在第一api下的表单响应时长；如果调用状态为非连续调用，则对第一api的请求返回时长执行运算，将相应的运算结果作为目标交互表单在第一api下的表单响应时长。
147.在本技术公开的处理装置的另一实施例中，性能确定模块20，还用于：
148.确定与第一api具有相似性的第二api；获得第二api的业务指标，至少基于第二api的业务指标确定目标交互表单在第二api下的响应性能；通过比对目标交互表单在第一api和第二api下的响应性能，从第一api和第二api中选取响应性能最优的目标api。
149.在本技术公开的处理装置的另一实施例中，性能确定模块20确定与第一api具有相似性的第二api，包括：
150.调用api相似库，api相似库中两个api的相似度是通过分析低编译平台的已发布应用对两个api的调用日志中的请求和返回数据所确定的；在api相似库中确定与第一api
的相似度满足对应阈值的api作为第二api。
151.在本技术公开的处理装置的另一实施例中，性能确定模块20，还用于：
152.在目标api为第一api的情况下，基于第一api输出相应的提示信息；或
153.在目标api为第二api的情况下，基于第二api输出相应的推荐信息。
154.本技术实施例中各模块的细化功能可以参见上述信息处理方法实施例对应公开部分，在此不再赘述。
155.与上述处理方法对应的，本技术还公开了一种存储介质，该存储介质存储有计算机程序代码，计算机程序代码执行时实现上述实施例的处理方法。
156.以上对本技术所提供的一种处理方法、装置、电子设备及存储介质进行了详细介绍，本文中应用了具体个例对本技术的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本技术的方法及其核心思想；同时，对于本领域的一般技术人员，依据本技术的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本技术的限制。
157.需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
158.还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备所固有的要素，或者是还包括为这些过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
159.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本技术。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本技术的精神或范围的情况下，在其它实施例中实现。因此，本技术将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。