CN117992107A - 一种应用程序获取系统以及方法 - Google Patents

Abstract

本申请涉及终端设备领域，公开了一种应用程序获取系统以及方法，用以提高用户对应用程序的获取效率。该系统中，在云端的应用市场响应于终端的请求，获取目标应用程序的场景下，若云端未搜索到该目标应用程序，可以请求协同分发服务平台进行应用程序的协同分发，从而可以在从协同分发服务平台获取到该目标应用程序后，返回到终端的应用市场上进行显示。这样，不仅可以提升用户获取应用程序的效率，还可以保证获取应用程序的安全性和合法性。

Description

一种应用程序获取系统以及方法

技术领域

本申请实施例涉及终端设备领域，尤其涉及一种应用程序获取系统以及方法。

背景技术

应用程序在终端设备上具有不可或缺的作用。用户可以从终端设备上的应用市场中、或互联网上获取应用程序的程序包，从而可以实现将应用程序安装到终端设备中。

对于应用程序开发侧来说，由于终端设备使用的操作系统、设备类型等因素的不同，应用程序开发者在推送新的应用程序的程序包时，通常需要在多种终端设备中进行分批次地推送。这样，只有应用程序开发者将新的应用程序的程序包推送到用户使用的终端设备、或终端设备可链接到的云侧(如应用市场云侧、或互联网等)之后，用户才能获取到该应用程序的程序包。因此，如何提高用户获取应用程序的效率，是具有研究意义的。

发明内容

本申请实施例提供一种应用程序获取系统以及方法，用以提供一种可以实现跨厂商或跨终端设备的应用程序协同分发，从而可以提高用户对应用程序的获取效率，进而提升用户体验。

第一方面，本申请实施例提供了一种应用程序获取系统。该系统可以包括请求方、应用程序协同分发服务平台和至少一个提供方，所述请求方包括终端和云端，其中，所述请求方的终端，用于检测并响应于在第一界面中用于搜索目标应用程序的第一用户操作，向所述请求方的云端发送获取请求；所述获取请求用于获取所述目标应用程序的程序包；所述请求方的云端，用于根据所述获取请求，确定未搜索到所述目标应用程序时，向所述应用程序协同分发服务平台发送申请协同消息；所述应用程序协同分发服务平台，用于根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方；并向所述目标提供方发送协同请求消息；所述目标提供方，用于接收所述协同请求消息，并向所述应用程序协同分发服务平台返回应用协同消息，所述应用协同消息用于指示所述应用程序协同分发服务平台可获取所述目标应用程序；所述应用程序协同分发服务平台，还用于根据所述应用协同消息，获取所述目标应用程序；基于所述目标应用程序生成应用数据包并返回给所述请求方的云端；所述请求方的云端，用于将所述应用数据包返回给所述请求方的终端；所述请求方的终端，用于根据所述应用数据包，显示第二界面，所述第二界面用于展示所述目标应用程序的相关信息。

通过该系统，基于构建协同分发服务平台，可以支持接入多个不同厂商或不同终端设备，并且实现跨厂商或跨终端设备的应用程序协同分发，从而可以实现在存在厂商或终端设备具有应用程序的程序包的场景下，其他厂商或其他终端设备可以通过协同分发服务平台实现应用程序协同。这样，可以提升用户获取应用程序的效率。并且，协同分发服务平台还可以通过签名认证等手段，保证应用协同分发的安全性和合法性。

在一种可能的设计中，所述申请协同消息中包括所述目标应用程序的标识；所述协同请求消息中包括所述目标应用程序的标识。该设计中，通过在设备之间传输的消息中携带目标应用程序的标识，可以准确地确定请求方的终端请求的目标应用程序。需要说明的是，本申请不限定目标应用程序的标识的具体类型，例如可以为名称、代码等。

在一种可能的设计中，所述应用程序协同分发服务平台，用于根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方，具体用于：根据所述申请协同消息，确定申请协同所述目标应用程序；基于所述协同策略，确定可提供所述目标应用程序的程序包的至少一个提供方的优先级；按照优先级从高到低选择所述目标提供方。

该设计中，通过协同分发服务平台基于优先级选择目标提供方，可以在可以提供目标应用程序的基础上，更精准地获取到目标应用程序，从而可以保障获取效率、获取准确度等。

在一种可能的设计中，所述协同策略根据应用程序类别、应用程序版本号、应用程序获取费用、手动配置信息等信息中的一种或组合，确定所述可提供所述目标应用程序的程序包的至少一个提供方的优先级。该设计中，通过基于多种不同的考虑设置提供方的优先级，从而可以提供更贴合请求方的请求需求的目标应用程序。这样，不仅可以提供目标应用程序，还可以保证提供的目标应用程序的精准度。

在一种可能的设计中，所述应用程序协同分发服务平台，用于根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方，具体用于：根据所述申请协同消息，确定申请协同所述目标应用程序；向至少一个提供方分别发送协同请求消息；从至少一个返回应用协同消息的提供方中选择目标提供方。

该设计中，协同分发服务平台还可以通过与各个提供方的交互，从而确定获取目标应用程序的途径。这样，可以保障获取到目标应用程序的实时性和准确性，确定可以从提供方中获取到目标应用程序。

在一种可能的设计中，所述应用程序协同分发服务平台，用于根据所述应用协同消息，获取所述目标应用程序；基于所述目标应用程序生成应用数据包，具体用于：根据所述应用协同消息，获取目标应用程序的原始程序包并生成所述目标应用程序的配置文件；所述配置文件包括以下信息中的一种或多种：包信息、包检测信息、签名信息；基于所述原始程序包和所述配置文件，生成所述应用数据包。

该设计中，协同分发服务平台还可以实现对应用数据包的检测、校验等操作，从而可以保障应用程序的安全性、合法性和可靠性。

在一种可能的设计中，所述请求方的云端，用于将所述应用数据包返回给所述请求方的终端之前，还用于：对所述应用数据包进行校验；确定校验通过。

在一种可能的设计中，所述请求方的终端，用于根据所述应用数据包，显示第二界面之后，还用于：检测到在所述第二界面上用于下载所述目标应用程序的程序包的第二用户操作；响应于所述第二用户操作，从所述应用数据包指示的下载地址下载所述目标应用程序的程序包。该设计中，基于该系统，在请求方的云端无法搜索到目标应用程序的场景下，也可以通过协同分发服务平台对该目标应用程序的协同分发，从而可以实现终端显示为可以获取到目标应用程序，从而可以保障用户对目标应用程序的获取效率，减少发生由于云端未搜索到该目标应用程序而导致无法获取到该应用程序的场景。

第二方面，本申请还提供一种应用功能程序获取方法。该方法中，协同分发服务平台接收来自请求方的云端发送的申请协同消息；根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方；向所述目标提供方发送协同请求消息；接收来自所述目标请求方的应用协同消息；根据所述应用协同消息，获取所述目标应用程序；基于所述目标应用程序生成应用数据包并返回给所述请求方的云端。

在一种可能的设计中，所述申请协同消息中包括所述目标应用程序的标识；所述协同请求消息中包括所述目标应用程序的标识。

在一种可能的设计中，所述根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方，包括：根据所述申请协同消息，确定申请协同所述目标应用程序；基于所述协同策略，确定可提供所述目标应用程序的程序包的至少一个提供方的优先级；按照优先级从高到低选择所述目标提供方。

在一种可能的设计中，所述协同策略根据应用程序类别、应用程序版本号、应用程序获取费用、手动配置信息等信息中的一种或组合，确定所述可提供所述目标应用程序的程序包的至少一个提供方的优先级。

在一种可能的设计中，所述根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方，包括：根据所述申请协同消息，确定申请协同所述目标应用程序；

向至少一个提供方分别发送协同请求消息；从至少一个返回应用协同消息的提供方中选择目标提供方。

在一种可能的设计中，所述根据所述应用协同消息，获取所述目标应用程序；基于所述目标应用程序生成应用数据包，包括：根据所述应用协同消息，获取目标应用程序的原始程序包并生成所述目标应用程序的配置文件；所述配置文件包括以下信息中的一种或多种：包信息、包检测信息、签名信息；基于所述原始程序包和所述配置文件，生成所述应用数据包。

第三方面，本申请还提供一种应用程序获取方法。该方法中，请求方的云端接收来自请求方的终端发送的获取请求；所述获取请求用于获取所述目标应用程序的程序包；根据所述获取请求，确定未搜索到所述目标应用程序时，向应用程序协同分发服务平台发送申请协同消息；接收来自所述应用程序协同分发服务平台返回的应用数据包，并将所述应用数据包返回给所述请求方的终端。

在一种可能的设计中，所述申请协同消息中包括所述目标应用程序的标识。

在一种可能的设计中，所述方法还包括：将所述应用数据包返回给所述请求方的终端之前对所述应用数据包进行校验；确定校验通过。

第四方面，本申请提供一种服务端设备，所述服务端设备包括多个功能模块；所述多个功能模块相互作用，实现上述任一方面及其各实施方式中服务端设备(如前述实施例中的请求方的云端、或协同分发服务平台、又或协同分发服务的提供方)所执行的方法。所述多个功能模块可以基于软件、硬件或软件和硬件的结合实现，且所述多个功能模块可以基于具体实现进行任意组合或分割。

第五方面，本申请提供一种服务端设备，包括至少一个处理器和至少一个存储器，所述至少一个存储器中存储计算机程序指令，所述服务端设备(如前述实施例中的请求方的云端、或协同分发服务平台、又或协同分发服务的提供方)运行时，所述至少一个处理器执行上述任一方面及其各实施方式中服务端设备执行的方法。

第六方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序被计算机执行时，使得所述计算机执行上述任一方面及其各可能的设计服务端设备(如前述实施例中的请求方的云端、或协同分发服务平台、又或协同分发服务的提供方)执行的方法。

第七方面，本申请提供了一种计算机程序产品，计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当计算机程序被运行时，使得计算机执行上述任一方面及其各可能的设计服务端设备(如前述实施例中的请求方的云端、或协同分发服务平台、又或协同分发服务的提供方)的方法。

第八方面，本申请还提供一种芯片，所述芯片用于读取存储器中存储的计算机程序，执行上述任一方面及其各可能的设计服务端设备(如前述实施例中的请求方的云端、或协同分发服务平台、又或协同分发服务的提供方)执行的方法。

第九方面，本申请还提供一种芯片系统，该芯片系统包括处理器，用于支持计算机装置实现上述任一方面及其各可能的设计服务端设备执行的方法。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存该计算机装置必要的程序和数据。该芯片系统可以由芯片构成，也可以包含芯片和其他分立器件。

上述第二方面至第九方面中任一方面及其可能的设计的有益效果请具体参阅上述第一方面中各种可能的设计的有益效果，在此不再赘述。

附图说明

图1为一种应用程序获取方法适用的架构示例图；

图2为本申请实施例提供的一种可能的终端设备的硬件结构示意图；

图3为本申请实施例提供的一种终端设备的软件系统架构框图；

图4为本申请实施例提供的一种应用程序获取方法适用的应用场景图；

图5为本申请实施例提供的一种应用程序获取方法适用的系统架构图；

图6为本申请实施例提供的一种应用程序获取方法的交互流程示意图；

图7为本申请实施例提供的一种应用程序包的示例图；

图8为本申请实施例提供的一种应用程序获取方法的时序图；

图9为本申请实施例提供一种应用程序获取方法的对比图；

图10为本申请实施例提供的一种协同分发服务平台的模块示意图；

图11为本申请实施例提供的一种应用程序获取方法的流程示意图；

图12为本申请实施例提供的一种应用程序获取方法的界面示意图。

具体实施方式

下面将结合附图，对本申请实施例进行详细描述。

本申请实施例提供的技术方案可以应用于终端设备领域，具体可以应用于例如终端设备中的获取应用程序的相关场景中。例如，图1为本申请实施例提供的一种应用程序获取方法适用的架构示例图，该架构中至少可以包括：应用程序使用者101(本申请实施例中也可简称为“用户”)、应用市场102以及应用程序开发者103；其中，应用市场102也可以划分为终端设备侧的应用市场1021和云侧的应用市场1022。基于图1所示的系统架构，应用程序的全生命周期可以包括以下步骤：

A1、应用程序开发者103生成应用程序的程序包。其中，应用程序的程序包可以为一个新的应用程序对应的程序包，也可以为对已有应用程序进行更新之后的程序包。

A2、应用程序开发者103将应用程序的程序包发送给云侧的应用市场1022。其中，云侧的应用市场1022可以在如服务器等设备中进行管理和维护。

A3、应用程序使用者101在终端设备侧的应用市场1021中搜索应用程序。其中，终端设备侧的应用市场1021例如可以包括但不限于：手机端应用市场、智能电视端应用市场、平板电脑端应用市场、电脑端应用市场、路由器端应用市场和手表端应用市场。可以理解，本申请不限定终端设备的设备类型。

A4、云侧的应用市场1022响应于终端设备侧的请求，分发应用程序的程序包到终端设备。例如，用户可以在手机的应用市场中搜索应用程序A，手机响应于用户的搜索操作，可以向手机对应的云侧的应用市场1022发送请求，以获取该应用程序A的程序包。可选的，相同厂商和/或相同设备类型等的终端设备可以对应相同的云侧的应用市场1022。

另一示例性的，由于终端设备的处理能力不同，云侧的应用市场1022也可以根据对应的终端设备的处理能力，进行应用程序的程序包的分发。例如，云侧的应用市场可以将应用程序A的程序包分发给2020年之后发布的终端设备，而不分发给在2020年之前发布的终端设备，避免2020年之前发布的终端设备无法支持对应用程序A可实现的功能。

A5、终端设备接收来自云侧的应用市场1022的应用程序的程序包，在终端设备上部署该应用程序的程序包。

从以上对应用程序的全生命周期的介绍内容中可以看到，若云侧的应用市场1022无法将应用程序的程序包分发给终端设备侧的应用市场1021，则用户无法从终端设备侧的应用市场1021中搜索到该应用程序。因此，采用应用程序开发者103分批次地推送应用程序的程序包的实现方式，存在用户获取应用程序的效率低、体验差等问题。

另一种可选的实现方式中，用户除了从终端设备侧的应用市场102中获取应用程序，还可以从互联网中搜索应用程序，以实现下载该应用程序。然而，该实现方式可能导致终端设备的设备安全存在问题。

因此，在各种实现方式中，由于不同厂商的生态一般为自闭环的状态，存在应用程序推送的效率差、或安全性低的问题。

有鉴于此，本申请实施例提供一种应用程序获取方法。该方法通过构建应用程序协同分发服务平台，可以实现多个不同厂商或不同终端设备等之间对应用程序的程序包(也可称为“应用程序包”、“应用包”或“软件包”等)的共享。因此，本申请可以实现跨厂商或跨终端设备的软件包共享，一方面可以保障共享软件包的安全性，另一方面还可以提升用户搜索应用程序时的获取效率，降低用户无法搜索到应用程序的发生概率，进而可以提升用户体验。

可以理解的是，本申请实施例的终端设备可以是诸如手机、可穿戴设备(例如，手环、手表、头盔、脚环等)、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、平板电脑、笔记本电脑、超级移动个人计算机(ultra-mobile personalcomputer，UMPC)、上网本、智能家居设备(例如，智能电视，智慧屏，智能音箱等)、个人数字助理(personaldigital assistant，PDA)等可以获取或安装应用程序的设备。可以理解的是，本申请实施例对终端设备的具体类型不作任何限制。

本申请实施例可以应用到的终端设备，示例性包括但不限于搭载HarmonyOS、IOS/>、android/>、Microsoft/>或者其它操作系统的终端设备。

图2示出了一种可能的终端设备的硬件结构示意图。其中，所述终端设备200包括：射频(radio frequency，RF)电路210、电源220、处理器230、存储器240、输入单元250、显示单元260、音频电路270、通信接口280、以及无线保真(wireless-fidelity，Wi-Fi)模块290等部件。本领域技术人员可以理解，图2中示出的终端设备200的硬件结构并不构成对终端设备200的限定，本申请实施例提供的终端设备200可以包括比图示更多或更少的部件，可以组合两个或更多的部件，或者可以具有不同的部件配置。图2中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

下面结合图2对所述终端设备200的各个构成部件进行具体的介绍：

所述RF电路210可用于通信或通话过程中，数据的接收和发送。特别地，所述RF电路210在接收到基站的下行数据后，发送给所述处理器230处理；另外，将待发送的上行数据发送给基站。通常，所述RF电路210包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(low noise amplifier，LNA)、双工器等。

此外，RF电路210还可以通过无线通信网络和其他设备进行通信。所述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(global system ofmobilecommunication，GSM)、通用分组无线服务(general packet radio service，GPRS)、码分多址(code division multiple access，CDMA)、宽带码分多址(wideband codedivision multipleaccess，WCDMA)、长期演进(long term evolution，LTE)、电子邮件、短消息服务(shortmessaging service，SMS)等。

Wi-Fi技术属于短距离无线传输技术，所述终端设备200通过Wi-Fi模块290可以连接访问接入点(access point，AP)，从而实现数据网络的访问。所述Wi-Fi模块290可用于通信过程中，数据的接收和发送。

所述终端设备200可以通过所述通信接口280与其他设备实现物理连接。可选的，所述通信接口280与所述其他设备的通信接口通过电缆连接，实现所述终端设备200和其他设备之间的数据传输。

所述终端设备200还能够实现通信业务，与服务侧设备、或者其他终端设备实现交互，因此所述终端设备200需要具有数据传输功能，即所述终端设备200内部需要包含通信模块。虽然图2示出了所述RF电路210、所述Wi-Fi模块290、和所述通信接口280等通信模块，但是可以理解的是，所述终端设备200中存在上述部件中的至少一个或者其他用于实现通信的通信模块(如蓝牙模块)，以进行数据传输。

例如，当所述终端设备200为手机时，所述终端设备200可以包含所述RF电路210，还可以包含所述Wi-Fi模块290，或可以包含蓝牙模块(图2中未示出)；当所述终端设备200为计算机时，所述终端设备200可以包含所述通信接口280，还可以包含所述Wi-Fi模块290，或可以包含蓝牙模块(图2中未示出)；当所述终端设备200为平板电脑时，所述终端设备200可以包含所述Wi-Fi模块，或可以包含蓝牙模块(图2中未示出)。

所述存储器240可用于存储软件程序以及模块。所述处理器230通过运行存储在所述存储器240的软件程序以及模块，从而执行所述终端设备200的各种功能应用以及数据处理。可选的，所述存储器240可以主要包括存储程序区和存储数据区。其中，存储程序区可存储操作系统(主要包括内核层、系统层、应用程序框架层和应用程序层等各自对应的软件程序或模块)。

此外，所述存储器240可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。本申请实施例中，所述存储器240可以存储终端设备200已经获取到的应用程序的程序包，从而可以支持实现各已有程序包可提供的功能。

所述输入单元250可用于接收用户输入的数字或字符信息等多种不同类型的数据对象的编辑操作，以及产生与所述终端设备200的用户设置以及功能控制有关的键信号输入。可选的，输入单元250可包括触控面板251以及其他输入设备252。

其中，所述触控面板251，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在所述触控面板251上或在所述触控面板251附近的操作)，并根据预先设定的程序驱动相应的连接装置。本申请实施例中，所述触控面板251可以收集用户在其上或附近的用户操作，所述用户操作可用于用户使用所述终端设备200管理前台业务等，例如，所述用户操作可以为用户在应用市场中用于获取应用程序的搜索操作以及搜索到应用程序之后的下载和安装操作等。

可选的，所述其他输入设备252可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

所述显示单元260可用于显示由用户输入的信息或提供给用户的信息以及所述终端设备200的各种菜单。所述显示单元260即为所述终端设备200的显示系统，用于呈现界面，实现人机交互。所述显示单元260可以包括显示面板261。可选的，所述显示面板261可以采用液晶显示屏(liquid crystal display，LCD)、有机发光二极管(organic light-emitting diode，OLED)等形式来配置。本申请实施例中，所述显示单元260可用于为用户显示获取应用程序相关的显示界面等。

所述处理器230是所述终端设备200的控制中心，利用各种接口和线路连接各个部件，通过运行或执行存储在所述存储器240内的软件程序和/或模块，以及调用存储在所述存储器240内的数据，执行所述终端设备200的各种功能和处理数据，从而实现基于所述终端设备200的多种业务。本申请实施例中，处理器230可用来实现本申请实施例提供的方法。

所述终端设备200还包括用于给各个部件供电的电源220(比如电池)。可选的，所述电源220可以通过电源管理系统与所述处理器230逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗等功能。

如图2所示，终端设备200还包括音频电路270、麦克风271和扬声器272，可提供用户与终端设备200之间的音频接口。音频电路270可用于将音频数据转换为扬声器272能够识别的信号，并将信号传输到扬声器272，由扬声器272转换为声音信号输出。麦克风271用于收集外部的声音信号(如人说话的声音、或者其它声音等)，并将收集的外部的声音信号转换为音频电路270能够识别的信号，发送给音频电路270。音频电路270还可用于将麦克风271发送的信号转换为音频数据，再将音频数据输出至RF电路210以发送给比如另一终端设备，或者将音频数据输出至存储器240以便后续进一步处理。

尽管未示出，所述终端设备200还可以包括摄像头、至少一种传感器等，在此不再赘述。至少一种传感器可以包含但不限于压力传感器、气压传感器、加速度传感器、距离传感器、指纹传感器、触摸传感器、温度传感器等。

本申请实施例涉及的操作系统(operating system，OS)，是运行在终端设备200上的最基本的系统软件。终端设备200的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本申请实施例以采用分层架构的操作系统为例，示例性说明终端设备200的软件结构。

图3为本申请实施例提供的一种终端设备的软件结构框图。如图3所示，终端设备的软件结构可以是分层架构，例如可以将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将操作系统分为五层，从上至下分别为应用程序层，应用程序框架层(framework，FWK)，运行时和系统库，内核层，以及硬件层。

应用程序层可以包括一系列应用程序包。如图3所示，应用程序层可以包括相机、设置、皮肤模块、用户界面(user interface，UI)、第三方应用程序等。其中，第三方应用程序可以包括无线局域网(wireless local area network，WLAN)、音乐、通话、蓝牙、视频等。

一种可能的实现方式中，应用程序可以使用java语言开发，通过调用应用程序框架层所提供的应用程序编程接口(application programming interface，API)来完成，开发者可以通过应用程序框架层来与操作系统的底层(例如硬件层、内核层等)进行交互，开发自己的应用程序。该应用程序框架层主要是操作系统的一系列的服务和管理系统。

应用程序框架层为应用程序层的应用程序提供应用编程接口和编程框架。应用程序框架层包括一些预定义函数。如图3所示，应用程序框架层可以包括活动管理器，窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。

活动管理器用于管理各个应用程序生命周期并提供常用的导航回退功能，为所有程序的窗口提供交互的接口。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

电话管理器用于提供终端设备的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端设备振动，指示灯闪烁等。

运行时包括核心库和虚拟机。运行时负责操作系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是操作系统的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体框架(mediaframework)，三维图形处理库(例如：OpenGL ES)，二维图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了二维和3D图层的融合。

媒体框架支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体框架可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

二维图形引擎是二维绘图的绘图引擎。

在一些实施例中，三维图形处理库可以用于绘制三维的运动轨迹图像，二维图形引擎可以用于绘制二维的运动轨迹图像。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

硬件层可以包括各类传感器，例如加速度传感器、重力传感器、触摸传感器等。

通常终端设备200可以同时运行多个应用程序。较为简单的，一个应用程序可以对应一个进程，较为复杂的，一个应用程序可以对应多个进程。每个进程具备一个进程号(进程ID)。

应理解，本申请实施例中“以下至少一(项)个”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b或c中的至少一项(个)，可以表示：a，b，c，a和b，a和c，b和c，或a、b和c，其中a、b、c可以是单个，也可以是多个。“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

另外，需要理解的是，在本申请的描述中，“第一”、“第二”等词汇，仅用于区分描述的目的，而不能理解为指示或暗示相对重要性，也不能理解为指示或暗示顺序。

应理解，终端设备的硬件结构可以如图2所示，软件系统架构可以如图3所示，其中，终端设备中的软件系统架构对应的软件程序和/或模块可以存储在存储器240中，处理器230可以运行存储器240中存储的软件程序和应用，以执行本申请实施例提供的一种应用程序获取方法的流程。

为了便于理解本申请提供的一种应用程序获取方法，以下结合图4至图12中所示的内容，对采用本申请提供的方法的实现过程进行介绍。

本申请实施例适用于在手机、或平板电脑等终端设备中获取应用程序的场景，例如用户在使用手机的过程中，在手机的应用市场等应用程序(application，APP)上搜索APP的场景。首先通过以下多个示例对本申请实施例适用的应用场景进行说明。可以理解，本申请实施时并不限定于以下应用场景。

一种可能的场景中，图4为本申请实施例提供的一种应用程序获取方法适用的应用场景示意图。以手机作为示例，用户可以在手机上的应用市场APP中包括的显示界面中搜索目标应用程序，假设为应用程序A。手机响应于用户该搜索操作，向云端请求应用程序A的程序包。可以理解，若云端具有应用程序A的程序包，则云端可以直接向手机返回应用程序A的程序包。其中，云端可以为手机对应的服务器，负责实现协助手机等多个终端设备进行业务处理、数据管理等；云端可以由服务器或服务器集群组成，本申请不限制云端的具体形式。

另一可选的，若云端未存储有应用程序A的程序包，则云端可以通过本申请提供的应用程序协同分发服务平台来实现应用程序A的程序包的协同共享。示例性的，图5为本申请实施例提供的一种应用程序获取方法适用的系统架构图。从图5中可以看到，该系统至少可以包括：协同分发服务的请求方501、应用程序协同分发服务平台502以及协同分发服务的提供方503。其中，

(1)请求方501，用于根据与用户之间的交互，触发协同分发服务。示例性的，请求方501可以为第三方厂商等无法提供应用程序A的程序包的一方。可选的，请求方501还可以划分为终端5011和云端5012。其中，

终端5011可主要负责与用户进行交互，一方面可以接收用户的APP获取请求、APP下载请求以及APP安装请求等；另一方面还可以向用户展示APP搜索结果、APP下载进度以及APP安装进度等。例如，终端5011可以为手机等设备，在终端5011上可以提供应用市场等APP，通过应用市场等APP可实现用户获取应用程序。

云端5012可主要负责协助终端5011进行APP的管理，可以接收来自终端5011的APP获取请求，并且响应于该APP获取请求从自身搜索APP、或在自身搜索无结果时向应用程序协同分发服务平台502申请协同，以实现向终端5011提供请求的APP的程序包。另外，云端5012还可以实现对来自应用程序协同分发服务平台502的程序包进行合法性校验、签名认证等。

此外，在另一些可能的场景中，请求方501也可以作为其他应用程序的提供方，假设为应用程序B。在开发者将应用程序B的程序包发送给图5中的请求方501之后，若存在其他厂商或其他终端设备请求获取应用程序B时，图5中的请求方501也可以作为提供方。

(2)应用程序协同分发服务平台502(可简称为“协同分发服务平台”等)，与多个不同厂商或不同设备类型的终端设备连接，用于实现应用程序的跨厂商或跨设备类型的协同分发。示例性的，协同分发服务平台502可接收请求方501对应用程序A的申请协同消息，从一个或多个提供方503中确定应用程序A的提供方503，向请求方501返回应用程序A的程序包；其中，一个或多个提供方503例如可以包括图5中示出的提供方5031、提供方5032、……、提供方503n(n可为正整数)。

此外，在一些可能的示例中，协同分发服务平台502还可以对来自提供方503的原始程序包进行配置，生成配置文件；其中，配置文件中可以包括但不限于以下信息：包信息、包检测信息、签名信息。然后，协同分发服务平台502可以将包括配置文件和原始程序包的软件包以及认证中心(certification authority，CA)数字证书等应用数据包发送给请求方501的云端5012，从而可以实现应用程序的协同分发，并且还可以保证应用程序的程序包的安全性。

(3)提供方503，用于提供应用程序的程序包的共享，可以通过协同分发服务平台502将应用程序的程序包提供给请求方501。可以理解，提供方503可以可提供应用程序A的程序包的一方，可以具有一个或多个提供方。

结合图5介绍的系统架构，参阅图6，为本申请实施例提供的一种应用程序获取方法的交互流程示意图，该交互流程可以包括：

S601、请求方的云端5012向协同分发服务平台502发送申请协同消息。其中，该申请协同消息中可以为请求方的云端5012响应于未搜索到应用程序A的事件时生成的，并且该申请协同消息中可包括应用程序A的标识。

S602、协同分发服务平台502接收来自请求方的云端5012的申请协同消息，根据协同策略，选择协同分发服务的提供方(也即目标提供方)。示例性的，协同策略可以为预先配置的策略。例如协同策略可以包括多个子策略，根据各个子策略逐一确定是否具有符合条件的提供方。例如，子策略一可以为根据应用程序类型设置提供方的优先级，例如，参阅以下表1，为一种可能的优先级的设置方式，如下：

表1

优先级	游戏类	视频类	购物类	……
					1	厂商1	厂商2	厂商3	……
2	厂商2	厂商3	厂商1	……
					3	厂商3	厂商1	厂商2	……
4	……	……	……	……

从表1介绍的内容可以看到，以游戏类为例进行说明，优先级为：厂商1＞厂商2＞厂商3＞其他厂商。示例性的，若应用程序A属于游戏类，则可以优先考虑厂商1是否可作为提供方，如果厂商1可提供应用程序A的程序包，则确定厂商1为应用程序A的提供方；可以理解，如果厂商1无法可提供应用程序A的程序包，则可以根据优先级继续考虑厂商2是否可作为提供方。

子策略二可以为根据应用程序的版本号设置提供方的优先级。示例性的，应用程序的版本号越高，则可以设置提供方具有更高的优先级。此外，还可以根据其他信息设置提供方的优先级，例如应用程序的获取费用等，本申请对此不进行限定。

子策略三可以为根据手动配置设置提供方的优先级。示例性的，可以手动配置优先级为：厂商3＞厂商2＞厂商1。

在一种可能的实施方式中，若协同分发服务平台502可以依次根据子策略一、子策略二和子策略三的先后顺序确定是否具有符合条件的提供方。可以理解，若根据子策略一确定选择到提供方，则可以不再执行根据子策略二和子策略三进行提供方的选择。

另一种可能的实施方式中，协同策略也可以为协同分发服务平台502向多个提供方发送协同请求消息，从至少一个返回应用协同消息的提供方中选择目标提供方，例如可以选择最早返回应用协同消息的提供方作为目标提供方等。

S603、协同分发服务平台502向选择的提供方发送协同请求消息，假设选择的提供方为提供方5031。其中，该协同请求消息也可包括应用程序A的标识。

S604、提供方5031向协同分发服务平台502返回应用协同消息。其中，应用协同消息中可以包括但不限于：应用程序A的原始程序包的下载地址、原始程序包的检测结果等信息。

S605、协同分发服务平台502根据应用协同消息，生成应用数据包。示例性的，协同分发服务平台502可以根据应用协同消息中包括的下载地址获取到应用程序A的原始程序包，并且生成应用程序A对应的配置文件；其中，配置文件中可以包括但不限于以下信息：包信息、包检测信息、签名信息；其中，包信息例如可以包括包版本、应用名称、开发者信息等，包检测信息例如可以包括病毒检测报告结果、广告检测报告结构、隐私检测报告结果、复检报告结果等。然后，协同分发服务平台502还可以根据应用程序A的原始程序包、配置文件以及CA数字证书等信息生成应用程序A的应用数据包。

另一示例性的，协同分发服务平台502也可以直接根据应用程序A的下载地址、配置文件以及CA数字证书生成应用数据包，以使请求方501的云端5012可以根据下载地址获取到应用程序A的原始程序包。

S606、协同分发服务平台502上传应用数据包到请求方501的云端5012。示例性的，云端5012接收到来自协同分发服务平台502的应用程序包之后，可以直接从应用数据包中获取到应用程序A的原始程序包、或根据应用数据包中的下载地址获取到应用程序A的原始程序包，然后可以使用CA数字证书对原始程序包进行验签，以提取到应用程序信息。并且，为了保证应用程序安全性，云端5012可以进行合法性校验通过之后，将包括应用程序A的原始程序包或下载地址等信息的应用程序包返回给终端5011。

S607、终端5011接收来自云端5012的应用数据包，向用户401展示应用程序的相关信息。示例性的，应用程序的相关信息可以包括但不限于：应用图标、应用名称、原始程序包存储大小、下载控件等。可以理解，若终端5011检测到用户对下载控件的用户操作，可以根据下载地址将应用程序A的原始程序包下载到手机上，并且可以在下载完成之后向用户展示安装控件或自动安装等。

通过前述内容可以看出，本申请基于构建协同分发服务平台，可以支持接入多个不同厂商或不同终端设备，并且实现跨厂商或跨终端设备的应用程序协同分发，从而可以实现在存在厂商或终端设备具有应用程序的程序包的场景下，其他厂商或其他终端设备可以通过协同分发服务平台实现应用程序协同。这样，可以提升用户获取应用程序的效率。并且，协同分发服务平台还可以通过签名认证等手段，保证应用协同分发的安全性和合法性。

为了更好地理解本申请实施例提供的方法，参阅图8，为本申请实施例提供的一种应用程序获取方法的时序图，可以包括以下步骤：

步骤801、请求方的终端检测到用于搜索应用的用户操作。例如，请求方的终端可以为手机上的应用市场，手机可以通过应用市场进程检测到该用户操作，如用户在应用市场的搜索框输入“应用程序A”的文本内容。可以理解，终端响应于该用户操作，可以确定用户请求获取应用程序A的程序包。另外，若手机上已经存在应用程序A的程序包，该用户操作还可以为用于请求获取应用程序A的其他版本的程序包。

步骤802、请求方的终端向云端发送获取请求。示例性的，终端可以基于应用程序A的标识向云端发送获取请求。例如终端向云端发送的获取请求消息，该获取请求消息中包括应用程序A的标识。

可选的，请求方的云端可以根据应用程序A的标识在云端进行搜索，若确定搜索到应用程序A，则可以直接执行步骤810；若确定未搜索到应用程序A，则可以继续执行步骤803。

步骤803、请求方的云端向协同分发服务平台申请应用协同。示例性的，请求方的云端可以向协同分发服务平台发送申请协同消息，该申请协同消息中可以包括应用程序A的标识。

步骤804、协同分发服务平台根据协同策略，选择协同分发服务的提供方。示例性的，该步骤的实现方式可参阅前述实施例中S602介绍的内容，在此不再赘述。

步骤805、协同分发服务平台向选择的提供方发送协同请求消息。其中，该协同请求消息中可以包括应用程序A的标识。

步骤806、提供方返回应用协同消息。其中，应用协同消息中可以包括但不限于：应用程序A的原始程序包的下载地址、原始程序包的检测结果等信息。

步骤807、协同分发服务平台根据应用协同消息，生成应用数据包。示例性的，该步骤的实现方式可参阅前述实施例中S605介绍的内容，在此不再赘述。

步骤808、协同分发服务平台向请求方的云端上传应用数据包。

步骤809、请求方的云端接收到来自协同分发服务平台的应用数据包之后，可以验证改应用数据包的合法性。

示例性的，若云端确定合法性通过，则可以继续执行步骤810；可以理解，若云端确定合法性未通过，则可以无需继续执行后续步骤，或者，还可以再次向协同分发服务平台申请来自其他提供方的应用协同。

步骤810、请求方的云端向终端返回应用数据包。

步骤811、请求方的终端向用户展示应用程序的相关信息。示例性的，应用程序的相关信息可以包括但不限于：应用图标、应用名称、原始程序包存储大小、下载控件等。

步骤812、请求方的终端检测到用于指示安装应用的用户操作。示例性的，请求方的终端可以检测到对下载控件的点击操作。

步骤813、请求方的终端下载安装应用。示例性的，请求方的终端响应于对下载控件的点击操作，可以根据来自云端的应用数据包，获取应用程序A的原始程序包，并安装到手机上。

可以理解，通过本申请实施例提供的方法，在开发者未将应用程序A的应用程序包推送到前述内容中的请求方的场景下，也可以实现对应用程序A的获取，从而可以提升获取应用程序的效率。例如，图9为本申请实施例提供的一种应用程序获取方法的对比图。相比于仅可以通过云端获取应用程序的实现方式1，实现方式2在云端无法搜索到应用程序A的场景下，还可以通过协同分发服务平台从提供方来申请应用程序A的协同分发，从而可以降低无法搜索到应用程序的发生概率，提升用户体验。

另一种可选的实施方式中，图10为本申请实施例提供的一种协同分发服务平台的模块示意图。协同分发服务平台502可以包括但不限于以下功能单元：策略管理模块1001、事件响应模块1002、接入管理模块1003、alops 1004、报表1005、中间件1006。需要说明的是，图10中所述的各模块仅为一种功能性划分，具体实现时也可以具有其他划分方式，本申请对功能单元的划分方式不进行限定。

策略管理模块1001，可用于支持管理和配置不同的协同策略，从而可以实现应用程序的提供方的选择。例如，策略管理模块1001可用于实现前述实施例中S602介绍的内容，从而可以实现协同分发服务平台502根据管理的协同策略，选择协同分发服务的提供方。其中，协同策略例如可以为前述实施例中介绍到的子策略一、子策略二以及子策略三等，在此不再赘述。

事件响应模块1002，可用于根据来自请求方的申请协同消息，进行校验。示例性的，可以进行请求来源合法性校验，从而可以防止非法请求。另一示例性的，还可以进行该请求方是否接入了协同分发服务平台502的校验。例如，图11为本申请实施例提供的一种应用程序获取方法的流程示意图，可以包括以下流程：

S1101、事件响应模块1002对请求中的src进行合法性校验，是否接入协同分发服务平台；其中，src是source的缩写，可指向请求方。此外，请求方在向协同分发服务平台502发送申请协同消息时，可以申请协同消息中携带加密之后的src和应用程序的标识，这样可以便于事件响应模块1002进行合法性校验。

示例性的，若确定接入，则可以继续执行S1102；否则，可以继续执行S1103B。

S1102、事件响应模块1002验证签名，是否检验通过。示例性的，若确定通过，则可以继续执行S1103A；否则，可以继续执行S1103B。

S1103A、事件响应模块1002确定请求成功。可以理解，此时协同分发服务平台502可以对请求方的申请协同的请求进行响应。

S1103B、事件响应模块1002确定请求失败。示例性的，此时协同分发服务平台502可以向请求方返回请求失败的指示消息。

接入管理模块1003，可用于管理请求方501的接入，还可用于管理提供方503的接入。

一种可选的示例中，接入管理模块1003可具体用于管理不同厂商或终端设备的接入，各厂商或各终端设备的角色(请求方或提供方)可根据实际的应用程序获取场景确定。例如，在获取应用程序A的场景下，厂商1可以为请求方，其他厂商可以作为提供方；而在获取应用程序B的场景下，厂商2可以为请求方，除厂商2之外的其他厂商可以作为提供方。

另一种可选的示例中，请求方501接入协同分发服务平台502之前，可以通过如图12所示的管理界面进行配置。如图12所示，在管理界面中，可以配置包括但不限于：接口地址的入口、上传证书文件的入口、以及接入类型的选择入口等。其中，接口地址的入口可用于链接协同分发服务平台502的接口地址，以可以实现根据接口地址接入协同分发服务平台502；上传证书文件的入口可用于协同分发服务平台502根据该证书文件验证请求方501的请求合法性；接入类型的选择入口可用于选择以请求方角色接入或者以提供方角色接入，以便于协同分发服务平台502确定该厂商接入的类型，例如可以如图12所示选择请求方的提示条，以确定以请求方角色接入协同分发服务平台502。

另一可选的，提供方也接入协同分发服务平台502之前，可以通过如图12所示的管理界面进行配置。在提供方的管理界面中，可以配置接口地址的入口；此时接口地址的入口可用于协同分发服务平台502发送协同请求消息，以实现应用协同分发。

智能运维(alops)1004、报表1005以及中间件1006可以用于支持协同分发服务的功能实现。例如，alops 1004可以包括系统的日志、告警、性能监控和处理等；报表1005可用于对各请求方的协同请求进行统计汇总等，并生成报表，以实现使用情况的统计和查阅；中间件1006可用于实现协同分发服务平台502的数据库管理和资源交互等。

基于以上实施例，本申请还提供一种终端设备，所述终端设备包括多个功能模块；所述多个功能模块相互作用，实现本申请实施例所描述的各方法中终端设备所执行的功能。所述多个功能模块可以基于软件、硬件或软件和硬件的结合实现，且所述多个功能模块可以基于具体实现进行任意组合或分割。如执行图8所示实施例中终端设备执行的步骤801至802以及810至813。

基于以上实施例，本申请还提供一种终端设备，该终端设备包括至少一个处理器和至少一个存储器，所述至少一个存储器中存储计算机程序指令，所述终端设备运行时，所述至少一个处理器执行本申请实施例所描述的各方法中终端设备所执行的功能。如执行图8所示实施例中终端设备执行的步骤801至802以及810至813。

基于以上实施例，本申请还提供一种服务端设备，所述服务端设备包括多个功能模块；所述多个功能模块相互作用，实现本申请实施例所描述的各方法中服务端设备(如前述实施例中的请求方的云端、或协同分发服务平台、又或协同分发服务的提供方)所执行的功能。所述多个功能模块可以基于软件、硬件或软件和硬件的结合实现，且所述多个功能模块可以基于具体实现进行任意组合或分割。如执行图8所示实施例中请求方的云端执行的步骤802至803以及808至810；或执行图8所示实施例中协同分发服务平台执行的步骤803至808；又或执行图8所示实施例中提供方执行的步骤805和步骤806。

基于以上实施例，本申请还提供一种服务端设备，该服务端设备包括至少一个处理器和至少一个存储器，所述至少一个存储器中存储计算机程序指令，所述服务端设备运行时，所述至少一个处理器执行本申请实施例所描述的各方法中服务端设备(如前述实施例中的请求方的云端、或协同分发服务平台、又或协同分发服务的提供方)所执行的功能。如执行图8所示实施例中请求方的云端执行的步骤802至803以及808至810；或执行图8所示实施例中协同分发服务平台执行的步骤803至808；又或执行图8所示实施例中提供方执行的步骤805和步骤806。

基于以上实施例，本申请还提供一种应用程序获取系统。该系统可以包括前述实施例中的请求方的终端、请求方的云端、协同分发服务平台以及至少一个提供方，本申请对此不进行限定。如各设备的协同处理可实现如图8所示的流程。

基于以上实施例，本申请还提供一种计算机程序产品，计算机程序产品包括：计算机程序(也可以称为代码，或指令)，当计算机程序被运行时，使得计算机执行本申请实施例所描述的各方法。

基于以上实施例，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序被计算机执行时，使得所述计算机执行本申请实施例所描述的各方法。

基于以上实施例，本申请还提供了一种芯片，所述芯片用于读取存储器中存储的计算机程序，实现本申请实施例所描述的各方法。

基于以上实施例，本申请提供了一种芯片系统，该芯片系统包括处理器，用于支持计算机装置实现本申请实施例所描述的各方法。在一种可能的设计中，所述芯片系统还包括存储器，所述存储器用于保存该计算机装置必要的程序和数据。该芯片系统，可以由芯片构成，也可以包含芯片和其他分立器件。本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的保护范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (20)

1.一种应用程序获取系统，其特征在于，该系统包括请求方、应用程序协同分发服务平台和至少一个提供方，所述请求方包括终端和云端，其中，

所述请求方的终端，用于检测并响应于在第一界面中用于搜索目标应用程序的第一用户操作，向所述请求方的云端发送获取请求；所述获取请求用于获取所述目标应用程序的程序包；

所述请求方的云端，用于根据所述获取请求，确定未搜索到所述目标应用程序时，向所述应用程序协同分发服务平台发送申请协同消息；

所述应用程序协同分发服务平台，用于根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方；并向所述目标提供方发送协同请求消息；

所述目标提供方，用于接收所述协同请求消息，并向所述应用程序协同分发服务平台返回应用协同消息，所述应用协同消息用于指示所述应用程序协同分发服务平台可获取所述目标应用程序；

所述应用程序协同分发服务平台，还用于根据所述应用协同消息，获取所述目标应用程序；基于所述目标应用程序生成应用数据包并返回给所述请求方的云端；

所述请求方的云端，用于将所述应用数据包返回给所述请求方的终端；

所述请求方的终端，用于根据所述应用数据包，显示第二界面，所述第二界面用于展示所述目标应用程序的相关信息。

2.根据权利要求1所述的系统，其特征在于，所述申请协同消息中包括所述目标应用程序的标识；

所述协同请求消息中包括所述目标应用程序的标识。

3.根据权利要求1或2所述的系统，其特征在于，所述应用程序协同分发服务平台，用于根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方，具体用于：

根据所述申请协同消息，确定申请协同所述目标应用程序；

基于所述协同策略，确定可提供所述目标应用程序的程序包的至少一个提供方的优先级；

按照优先级从高到低选择所述目标提供方。

4.根据权利要求3所述的系统，其特征在于，所述协同策略根据应用程序类别、应用程序版本号、应用程序获取费用、手动配置信息等信息中的一种或组合，确定所述可提供所述目标应用程序的程序包的至少一个提供方的优先级。

5.根据权利要求1或2所述的系统，其特征在于，所述应用程序协同分发服务平台，用于根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方，具体用于：

根据所述申请协同消息，确定申请协同所述目标应用程序；

向至少一个提供方分别发送协同请求消息；

从至少一个返回应用协同消息的提供方中选择目标提供方。

6.根据权利要求1至5中任一项所述的系统，其特征在于，所述应用程序协同分发服务平台，用于根据所述应用协同消息，获取所述目标应用程序；基于所述目标应用程序生成应用数据包，具体用于：

根据所述应用协同消息，获取目标应用程序的原始程序包并生成所述目标应用程序的配置文件；所述配置文件包括以下信息中的一种或多种：包信息、包检测信息、签名信息；

基于所述原始程序包和所述配置文件，生成所述应用数据包。

7.根据权利要求1至6中任一项所述的系统，其特征在于，所述请求方的云端，用于将所述应用数据包返回给所述请求方的终端之前，还用于：

对所述应用数据包进行校验；

确定校验通过。

8.根据权利要求1至7中任一项所述的系统，其特征在于，所述请求方的终端，用于根据所述应用数据包，显示第二界面之后，还用于：

检测到在所述第二界面上用于下载所述目标应用程序的程序包的第二用户操作；

响应于所述第二用户操作，从所述应用数据包指示的下载地址下载所述目标应用程序的程序包。

9.一种应用功能程序获取方法，其特征在于，包括：

接收来自请求方的云端发送的申请协同消息；

根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方；

向所述目标提供方发送协同请求消息；

接收来自所述目标请求方的应用协同消息；

根据所述应用协同消息，获取所述目标应用程序；基于所述目标应用程序生成应用数据包并返回给所述请求方的云端。

10.根据权利要求9所述的方法，其特征在于，所述申请协同消息中包括所述目标应用程序的标识；

所述协同请求消息中包括所述目标应用程序的标识。

11.根据权利要求9或10所述的方法，其特征在于，所述根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方，包括：

根据所述申请协同消息，确定申请协同所述目标应用程序；

基于所述协同策略，确定可提供所述目标应用程序的程序包的至少一个提供方的优先级；

按照优先级从高到低选择所述目标提供方。

12.根据权利要求11所述的方法，其特征在于，所述协同策略根据应用程序类别、应用程序版本号、应用程序获取费用、手动配置信息等信息中的一种或组合，确定所述可提供所述目标应用程序的程序包的至少一个提供方的优先级。

13.根据权利要求9或10所述的方法，其特征在于，所述根据所述申请协同消息以及协同策略，从至少一个提供方中选择目标提供方，包括：

根据所述申请协同消息，确定申请协同所述目标应用程序；

向至少一个提供方分别发送协同请求消息；

从至少一个返回应用协同消息的提供方中选择目标提供方。

14.根据权利要求9至13中任一项所述的方法，其特征在于，所述根据所述应用协同消息，获取所述目标应用程序；基于所述目标应用程序生成应用数据包，包括：

根据所述应用协同消息，获取目标应用程序的原始程序包并生成所述目标应用程序的配置文件；所述配置文件包括以下信息中的一种或多种：包信息、包检测信息、签名信息；

基于所述原始程序包和所述配置文件，生成所述应用数据包。

15.一种应用程序获取方法，其特征在于，包括：

请求方的云端接收来自请求方的终端发送的获取请求；所述获取请求用于获取所述目标应用程序的程序包；

根据所述获取请求，确定未搜索到所述目标应用程序时，向应用程序协同分发服务平台发送申请协同消息；

接收来自所述应用程序协同分发服务平台返回的应用数据包，并将所述应用数据包返回给所述请求方的终端。

16.根据权利要求15所述的方法，其特征在于，所述申请协同消息中包括所述目标应用程序的标识。

17.根据权利要求15或16所述的方法，其特征在于，所述方法还包括：

将所述应用数据包返回给所述请求方的终端之前对所述应用数据包进行校验；

确定校验通过。

18.一种服务端设备，其特征在于，包括至少一个处理器，所述至少一个处理器与至少一个存储器耦合，所述至少一个处理器用于读取所述至少一个存储器所存储的计算机程序，以执行如权利要求9至14中任一项所述的方法，或执行如权利要求15至17中任一项所述的方法。

19.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行如权利要求9至14中任一项所述的方法，或执行如权利要求15至17中任一项所述的方法。

20.一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如权利要求9至14中任一项所述的方法，或执行如权利要求15至17中任一项所述的方法。