基于应用程序的操作方法、装置、电子设备及计算机介质与流程

本申请涉及计算机和互联网技术领域，具体而言，本申请涉及一种基于应用程序的操作方法、装置、电子设备及计算机介质。

背景技术：

在现有技术中，随着终端设备的普及，如智能手机、平板电脑，移动终端等设备的广泛应用，使得移动终端上运行的应用程序越来越多，大量应用程序的出现在让用户感受不同应用程序带来的便利同时，也给用户带来一定的困扰，比如用户需要不断地更新应用程序的版本。

而且，随着技术的不断发展和更新，应用程序的功能也越来越强大，研发人员也会在现有应用程序的基础上进行一些功能或应用项目的扩充，例如现有版本的应用程序(例如1.0版本的应用程序)支持3个应用项目，而当研发人员新开发出了2个应用项目，并准备将新开发的2个应用项目集成到原来的应用程序中时，只能通过升级应用程序的版本才能实现，例如将1.0版本应用程序升级到1.1版本，即需要重新进行应用程序版本的发布，这不仅增加了研发成本，而且导致用户需要不断地更新应用程序的版本才能使用应用程序中新增加的应用项目，给用户带来极大不便，同时应用程序的不断更新也极大消耗用户流量、用户体验较差。

技术实现要素：

本申请的目的旨在至少能解决上述的技术缺陷之一，特提出以下技术方案：

第一方面，提供了一种基于应用程序的操作方法，包括：

接收针对多应用管理平台中任一应用程序的操作请求；

通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作。

具体地，在接收针对多应用管理平台中任一应用程序的操作请求的步骤之前，还包括：

基于预设的脚本指令建立多应用管理平台与终端设备间的预设接口，以使得将多个应用程序封装至多应用管理平台中。

进一步地，在接收针对多应用管理平台中任一应用程序的操作请求的步骤之前，还包括：

封装终端设备的底层相关方法；

基于封装后的底层相关方法将多应用管理平台中任一应用程序适配至所述终端设备。

进一步地，该方法还包括：

通过预设的通讯通道进行多应用管理平台中任一应用程序与服务器间的数据传输。

进一步地，在通过预设的通讯通道进行多应用管理平台中任一应用程序与服务器间的数据传输的步骤之前，该方法还包括：

建立多应用管理平台与服务器之间的所述通讯通道。

进一步地，应用程序为基于web的应用程序。

进一步地，底层相关方法包括以下至少一项：

基于web的组织展示方法；底层交互方法；消息通知方法。

第二方面，提供了一种基于应用程序的操作装置，包括：

接收模块，用于接收针对多应用管理平台中任一应用程序的操作请求；

处理模块，用于通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作。

具体地，该装置还包括第一建立模块；

第一建立模块，用于基于预设的脚本指令建立多应用管理平台与终端设备间的预设接口，以使得将多个应用程序封装至多应用管理平台中。

进一步地，该装置还包括封装模块与适配模块；

封装模块，用于封装终端设备的底层相关方法；

适配模块，用于基于封装后的底层相关方法将多应用管理平台中任一应用程序适配至终端设备。

进一步地，该装置还包括传输模块；

传输模块，用于通过预设的通讯通道进行多应用管理平台中任一应用程序与服务器间的数据传输。

进一步地，该装置还包括第二建立模块；

第二建立模块，用于建立多应用管理平台与服务器之间的所述通讯通道。

进一步地，应用程序为基于web的应用程序。

进一步地，底层相关方法包括以下至少一项：

基于web的组织展示方法；底层交互方法；消息通知方法。

第三方面，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行所述程序时实现上述的基于应用程序的操作方法。

第四方面，提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现上述的基于应用程序的操作方法。

本申请实施提供的基于应用程序的操作方法，接收到针对多应用管理平台中任一应用程序的操作请求时，通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作，一方面，使得通过终端设备与多应用管理平台间的预设接口即可实现对多应用管理平台中任一应用程序的访问，而无需建立终端设备与各个应用程序分别对应的接口，极大降低了研发复杂度，另一方面，使得只要将客户端发布版本以后新开发的应用程序集成到多应用管理平台中，用户即可通过终端设备与多应用管理平台间的接口对其进行访问，从而无需针对新开发的应用程序重新发布客户端，同时用户也需要频繁更新客户端版本，极大提升用户体验。

本申请附加的方面和优点将在下面的描述中部分给出，这些将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：

图1为本申请实施例的基于应用程序的操作方法的流程示意图；

图2为本申请实施例的终端设备、多应用管理平台及服务器之间进行数据传输的基本结构示意图；

图3为本申请实施例的多应用管理平台的细化示意图；

图4为本申请实施例的基于应用程序的操作装置的基本结构示意图；

图5为本申请实施例的基于应用程序的操作装置的详细结构示意图；

图6为本申请实施例的电子设备的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能解释为对本申请的限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

随着技术的不断发展和更新，应用程序的功能也越来越强大，研发人员也会在现有应用程序的基础上进行一些功能或应用项目的扩充，例如现有版本的应用程序(例如1.0版本的应用程序)支持3个应用项目，而当研发人员新开发出了2个应用项目，并准备将新开发的2个应用项目集成到原来的应用程序中时，只能通过升级应用程序的版本才能实现，例如将1.0版本应用程序升级到1.1版本，即需要重新进行应用程序版本的发布，这不仅增加了研发成本，而且导致用户需要不断地更新应用程序的版本才能使用应用程序中新增加的应用项目，给用户带来极大不便，同时应用程序的不断更新也极大消耗用户流量、用户体验较差。

本申请提供的基于应用程序的操作方法、装置、电子设备和计算机介质，旨在解决现有技术的如上技术问题。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

本申请实施例提供了一种基于应用程序的操作方法，如图1所示，包括：

步骤s110，接收针对多应用管理平台中任一应用程序的操作请求。

具体地，多应用管理平台中包括多个应用程序，即如果需要多个应用程序同时在线，则可以将该多个应用程序均集成到多应用管理平台中，其中，该多个应用程序可以是当前版本客户端(例如客户端1.0)中的已有应用程序，也可以是后续为当前版本客户端新增加的一些应用程序，即无论该应用程序是原先客户端1.0中已有的，还是客户端1.0发布后研发人员新开发的，均可集成到多应用管理平台中。

进一步地，无论该应用程序是原先客户端1.0中已有的，还是客户端1.0发布后研发人员新开发的，只要集成到了多应用管理平台中，那么就终端设备就可以接收针对该多应用管理平台中的应用程序的操作请求。

步骤s120，通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作。

具体地，终端设备与多应用管理平台间存在预设接口，并且终端设备可以通过该预设接口与多应用管理平台中的任一应用程序进行数据交互，于是，当终端设备接收针对多应用管理平台中任一应用程序的操作请求时，可以通过调用终端设备与多应用管理平台间的预设接口，来基于操作请求对任一应用程序进行相应操作。

本申请实施例提供的基于应用程序的操作方法，与现有技术相比，接收到针对多应用管理平台中任一应用程序的操作请求时，通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作，一方面，使得通过终端设备与多应用管理平台间的预设接口即可实现对多应用管理平台中任一应用程序的访问，而无需建立终端设备与各个应用程序分别对应的接口，极大降低了研发复杂度，另一方面，使得只要将客户端发布版本以后新开发的应用程序集成到多应用管理平台中，用户即可通过终端设备与多应用管理平台间的接口对其进行访问，从而无需针对新开发的应用程序重新发布客户端，同时用户也需要频繁更新客户端版本，极大提升用户体验。

本申请实施例提供了另一种可能的实现方式，其中，在步骤s110之前还包括步骤s100(图中未标注)：基于预设的脚本指令建立多应用管理平台与终端设备间的预设接口，以使得将多个应用程序封装至多应用管理平台中。

其中，应用程序为基于web的应用程序。

具体地，在现有机制的基础上，可以利用预设的脚本指令建立多应用管理平台与终端设备间的预设接口，即利用预设的脚本指令将终端设备提供的与各个基于web的应用程序(下述简称为web应用程序)之间的单独的接口，转变成一个统一的预设接口，并通过该预设接口进行终端设备与各个web应用程序之间的交互，其中，该预设接口是多应用管理平台与终端设备间的接口，也即将各个web应用程序封装或集成到多应用管理平台，从而终端设备通过该预设接口即可与多应用管理平台中的任一web应用程序进行交互。

假如原来终端设备与web应用程序1之间的接口为接口1，终端设备与web应用程序2之间的接口为接口2，终端设备与web应用程序3之间的接口为接口3，依次类推。当终端设备需要与web应用程序1进行交互时，只能通过接口1来进行交互，当终端设备需要与web应用程序2进行交互时，也只能通过接口2来进行交互，依次类推。现在利用预设的脚本指令将终端设备提供的与各个web应用程序之间的单独的接口(例如接口1、接口2及接口3)，转变成一个统一的预设接口(例如接口0)，并且终端设备通过该接口0与各个web应用程序进行交互，即各个web应用程序共用这一接口0，也即接口0是各个web应用程序的统一出入口，相当于将各个web应用程序集成在一起共用这一接口0。其中，可以将各个web应用程序封装(即集成)到多应用管理平台中，此时接口0即为终端设备与多应用管理平台间的统一的预设接口。

进一步地，将多个应用程序封装至多应用管理平台后，即可以通过调用终端设备与多应用管理平台间的预设接口，与多应用管理平台中的任一应用程序进行交互。

对于本申请实施例，通过基于预设的脚本指令建立多应用管理平台与终端设备间的预设接口，使得通过一个公共接口即可实现对任一应用程序的访问，极大节省了开发过程中的接口资源，降低了对各个应用程序进行访问的复杂度。

本申请实施例提供了另一种可能的实现方式，其中，在步骤s110之前还包括步骤s101(图中未标注)与步骤s102(图中未标注)，其中，

步骤s101：封装终端设备的底层相关方法。

步骤s102：基于封装后的底层相关方法将多应用管理平台中任一应用程序适配至终端设备。

其中，底层相关方法包括以下至少一项：

基于web的组织展示方法；底层交互方法；消息通知方法。

具体地，步骤s101与步骤s102可以在步骤s110之前执行，也可以在步骤s100之前执行，本申请不对其做限制，下面以在步骤s110之前执行为例，对其进行简要说明，具体如下：

在基于终端设备的web应用程序开发过程中，通过终端设备支持一种形式的语言，例如编程语言1，web应用程序开发使用的是另一种形式的语言，例如编程语言2，由于web应用程序是通过终端设备进行展现的，即将web应用程序安装到终端设备后，才能够在终端设备中对其进行使用或进行其它操作，于是就需要使基于编程语言2的web应用程序适配基于编程语言1的终端设备，从而终端设备支持该web应用程序。

具体地，在适配的过程中，通常是对终端设备的每一项都要进行适配，例如进行基于web的组织展示方法的适配，又例如进行底层交互方法的适配，再例如进行消息通知方法的适配，然而这种适配每一项的操作不仅过程繁杂而且重复操作，极大增加了研发人员的工作量。于是，本申请实施将终端设备的每一项需要适配的底层方法都封装在一起，即封装终端设备所有的底层相关方法，即将终端设备所有的底层相关方法作为一个整体，类似一个固定好的“黑匣子”，在将web应用程序适配终端设备的过程中，只要调用一次这个“黑匣子”即可完成所有的适配，而无需一项一项地单独适配，从而极大提高工作效率，降低适配过程的繁杂程度。

进一步地，在封装终端设备的底层相关方法后，可以基于封装后的底层相关方法(即上述的“黑匣子”)将多应用管理平台中任一应用程序适配至终端设备，假如多应用管理平台中包括web应用程序1、web应用程序2及web应用程序3，此时，web应用程序1通过调用上述的“黑匣子”，即可以基于封装后的底层相关方法，适配至终端设备，web应用程序2也可以通过调用上述的“黑匣子”适配至终端设备，同样，web应用程序3也可以通过调用上述的“黑匣子”适配至终端设备，从而实现了多个web应用程序对封装后的终端底层相关方法的统一调用。

对于本申请实施例，通过封装终端设备的底层相关方法，并基于封装后的底层相关方法将多应用管理平台中任一应用程序适配至终端设备，有效避免了现有技术中一项接着一项的单独适配过程，降低了适配过程的繁杂程度，减小开发成本，极大提高工作效率。

本申请实施例提供了另一种可能的实现方式，其中，还包括步骤s130(图中未标注)：通过预设的通讯通道进行多应用管理平台中任一应用程序与服务器间的数据传输。

其中，在步骤s130之前还包括步骤s121(图中未标注)：建立多应用管理平台与服务器之间的通讯通道。

具体地，步骤s130可以在步骤s110之前也可以在步骤s110之后，还可以在步骤s120之后，本申请实施例不对其做限定，下面以在步骤s120之后执行为例，对其进行简要说明，具体如下：

终端设备可以通过预设接口与多应用管理平台中的任一应用程序进行数据交互，在该数据交互过程中，可能存在应用程序需要访问后台服务器的情况，即需要与后台服务器进行交互，比如进行数据传输，例如可以是从向后台服务器发送数据获取请求，并接收后台服务器返回的相应数据，从而响应通过终端设备进行的操作请求。

其中，在应用程序与后台服务器进行交互的过程之前，可以预先建立多应用管理平台与后台服务器之间的通讯通道，即将各个web应用程序与后台服务器进行交互的单独的通讯通道，转变成一个统一的通讯通道，并通过该统一的通讯通道与后台服务器进行交互，其中，该统一的通讯通道是多应用管理平台与服务器间的通讯通道，也即将各个web应用程序封装或集成到多应用管理平台，从而各个应用程序分别通过该该统一的通讯通道与后台服务器进行交互。

假如原来后台服务器与web应用程序1之间的通讯通道为通讯通道1，后台服务器与web应用程序2之间的通讯通道为通讯通道2，后台服务器与web应用程序3之间的通讯通道为通讯通道3，依次类推。当web应用程序1需要与后台服务器进行交互时，只能通过通讯通道1来进行交互，当web应用程序2需要与后台服务器进行交互时，也只能通过通讯通道2来进行交互，依次类推。现在将后台服务器与各个web应用程序之间的单独的通讯通道(例如通讯通道1、通讯通道2及通讯通道3)，转变成一个统一的通讯通道(例如通讯通道0)，并且各个web应用程序通过该通讯通道0与后台服务器进行交互，即各个web应用程序共用这一通讯通道0，也即通讯通道0是各个web应用程序的统一出入口，相当于将各个web应用程序集成在一起共用这一通讯通道0。

进一步地，将多个应用程序封装至多应用管理平台后，即可以通过调用多应用管理平台与后台服务器间的预设的通讯通道，来与后台服务器进行数据传输、数据交互等。

对于本申请实施例，通过建立多应用管理平台与服务器间的预设的通讯通道，使得通过一个公共通讯通道即可实现任一应用程序对服务器的访问，极大节省了开发过程中的通讯通道资源，降低了各个应用程序与服务器进行数据传输的复杂度。

需要说明的是，图2给出了上述实施例一至实施例四中的任一实施例的终端设备、多应用管理平台及服务器之间进行数据传输的基本结构示意图，其中，多应用管理平台包括多个web应用程序，多应用管理平台与终端设备间的接口即为上述的预设接口，多应用管理平台与服务器间的通讯通道即为上述的预设的通讯通道。其中，图3为图2中多应用管理平台的一个细化。

图4为本申请实施例提供的一种基于应用程序的操作装置的结构示意图，如图4所示，该装置40可以包括：接收模块41与处理模块42，其中，

接收模块41用于接收针对多应用管理平台中任一应用程序的操作请求；

处理模块42用于通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作。

具体地，该装置还包括第一建立模块43，如图5所示，其中，

第一建立模块43用于基于预设的脚本指令建立多应用管理平台与终端设备间的预设接口，以使得将多个应用程序封装至多应用管理平台中。

进一步地，该装置还包括封装模块44与适配模块45，如图5所示，其中，

封装模块44用于封装终端设备的底层相关方法；

适配模块45用于基于封装后的底层相关方法将多应用管理平台中任一应用程序适配至终端设备。

进一步地，该装置还包括传输模块46，如图5所示，其中，

传输模块46用于通过预设的通讯通道进行多应用管理平台中任一应用程序与服务器间的数据传输。

进一步地，该装置还包括第二建立模块47，如图5所示，其中，

第二建立模块，用于建立多应用管理平台与服务器之间的所述通讯通道。

进一步地，应用程序为基于web的应用程序。

进一步地，底层相关方法包括以下至少一项：

基于web的组织展示方法；底层交互方法；消息通知方法

本申请实施例提供的装置，与现有技术相比，接收到针对多应用管理平台中任一应用程序的操作请求时，通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作，一方面，使得通过终端设备与多应用管理平台间的预设接口即可实现对多应用管理平台中任一应用程序的访问，而无需建立终端设备与各个应用程序分别对应的接口，极大降低了研发复杂度，另一方面，使得只要将客户端发布版本以后新开发的应用程序集成到多应用管理平台中，用户即可通过终端设备与多应用管理平台间的接口对其进行访问，从而无需针对新开发的应用程序重新发布客户端，同时用户也需要频繁更新客户端版本，极大提升用户体验。

本申请实施例提供了一种电子设备，如图6所示，图6所示的电子设备600包括：处理器601和存储器603。其中，处理器601和存储器603相连，如通过总线602相连。进一步地，电子设备600还可以包括收发器604。需要说明的是，实际应用中收发器604不限于一个，该电子设备600的结构并不构成对本申请实施例的限定。

其中，处理器601应用于本申请实施例中，用于实现图4或图5所示的接收模块与处理模块的功能，以及图5的第一建立模块、封装模块、适配模块及第二建立模块。收发器604包括接收机和发射机，收发器604应用于本申请实施例中，用于实现图5所示的传输模块的功能。

处理器601可以是cpu，通用处理器，dsp，asic，fpga或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器601也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，dsp和微处理器的组合等。

总线602可包括一通路，在上述组件之间传送信息。总线602可以是pci总线或eisa总线等。总线602可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器603可以是rom或可存储静态信息和指令的其他类型的静态存储设备，ram或者可存储信息和指令的其他类型的动态存储设备，也可以是eeprom、cd-rom或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器603用于存储执行本申请方案的应用程序代码，并由处理器601来控制执行。处理器601用于执行存储器603中存储的应用程序代码，以实现图4或图5所示实施例提供的基于应用程序的操作装置的动作。

本申请实施例提供的电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，与现有技术相比，可实现：接收到针对多应用管理平台中任一应用程序的操作请求时，通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作，一方面，使得通过终端设备与多应用管理平台间的预设接口即可实现对多应用管理平台中任一应用程序的访问，而无需建立终端设备与各个应用程序分别对应的接口，极大降低了研发复杂度，另一方面，使得只要将客户端发布版本以后新开发的应用程序集成到多应用管理平台中，用户即可通过终端设备与多应用管理平台间的接口对其进行访问，从而无需针对新开发的应用程序重新发布客户端，同时用户也需要频繁更新客户端版本，极大提升用户体验。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现实施例一所示的方法。与现有技术相比，接收到针对多应用管理平台中任一应用程序的操作请求时，通过调用终端设备与多应用管理平台间的预设接口，基于操作请求对任一应用程序进行相应操作，一方面，使得通过终端设备与多应用管理平台间的预设接口即可实现对多应用管理平台中任一应用程序的访问，而无需建立终端设备与各个应用程序分别对应的接口，极大降低了研发复杂度，另一方面，使得只要将客户端发布版本以后新开发的应用程序集成到多应用管理平台中，用户即可通过终端设备与多应用管理平台间的接口对其进行访问，从而无需针对新开发的应用程序重新发布客户端，同时用户也需要频繁更新客户端版本，极大提升用户体验。

本申请实施例提供的计算机可读存储介质适用于上述方法的任一实施例。在此不再赘述。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。