CN113485722A

CN113485722A - 应用商店的应用程序的上架方法、处理方法及计算机设备

Info

Publication number: CN113485722A
Application number: CN202110740871.7A
Authority: CN
Inventors: 刘成城
Original assignee: Beijing Jingling Information System Technology Co Ltd
Current assignee: Beijing ByteDance Network Technology Co Ltd
Priority date: 2021-06-30
Filing date: 2021-06-30
Publication date: 2021-10-08

Abstract

本申请公开了一种应用商店的应用程序的上架方法、处理方法及计算机设备。一种应用商店中的应用程序的上架方法，包括：接收应用程序的安装文件；判断所述应用程序是否上架成功；在所述应用程序上架成功的情况下，显示所述应用程序的上架状态为成功。本申请使得客户端在安装应用程序时，能够无障碍地进行，提高了应用程序的安装效率。

Description

应用商店的应用程序的上架方法、处理方法及计算机设备

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种应用商店的应用程序的上架方法、处理方法及计算机设备。

背景技术

在Linux操作系统中，用户在安装应用程序时，通常是使用apt-get等命令方式从具有该应用程序安装文件的软件源进行下载和安装。与Windows和Mac OS不同的是，Linux下的应用程序往往需要各种依赖，当安装命令在软件源中无法找到所需要的依赖包或者依赖关系存在错误时出现安装失败，这种情况下需要用户自行添加依赖的软件源或者手工安装相关依赖，操作比较繁琐，导致安装效率降低，会影响用户的体验。

在相关技术中，Linux操作系统提供了应用商店，诸如UOS应用商店、Deepin应用商店等，允许开发者向应用商店上传Debian格式的应用程序安装文件(deb)，但依旧未解决上述问题，使得终端用户使用时频繁出现弹出命令行窗口提示无法找到相关依赖。

发明内容

本申请的主要目的在于提供一种应用商店的应用程序的上架方法、处理方法及计算机设备，以解决上述的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种应用程序的上架方法，包括：

接收应用程序的安装文件；

判断所述应用程序是否上架成功；

如果所述应用程序上架成功，则显示所述应用程序的上架状态为成功。

在一种实施方式中，还包括：

将上架成功的应用程序生成当前可安装应用程序列表；

响应于查询当前可安装应用程序列表的请求，发送所述当前可安装应用程序列表。

在一种实施方式中，将上架成功的应用程序生成当前可安装应用程序列表，包括：

根据每个应用程序所需的依赖数量，依序排列。

根据每个应用程序在应用商店中的历史安装次数，依序排列。

根据本申请实施例的第二方面，本申请还提出了一种应用商店中的应用程序的处理方法，包括：

获取应用程序的信息和在应用商店的上架请求；

获得所述应用程序的安装文件；

分析和处理所述应用程序的依赖；

发布所述应用程序。

在一种实施方式中，分析和处理所述应用程序的依赖，发布所述应用程序，包括：

根据所述应用程序的安装文件分析安装所述应用程序的依赖；

在安装所述应用程序需要依赖的情况下，获取安装所述应用程序的依赖；

发布所述应用程序和与所述应用程序对应的依赖。

在一种实施方式中，还包括：生成包括每个应用程序和与其所对应的依赖关系的索引及校验文件。

在一种实施方式中，还包括：响应于更新所述应用程序和/或与其对应的依赖、删除所述应用程序和/或与其对应的依赖、修改所述应用程序和/或与其对应的依赖操作中的任一者，更新所述索引及校验文件。

第三方面，本申请还提供了一种电子设备，电子设备包括：处理器以及存储有计算机程序指令的存储器；所述处理器执行所述计算机程序指令时实现如上述任一所述应用商店中的应用程序的上架方法。

第四方面，本申请还提供了一种电子设备，电子设备包括：处理器以及存储有计算机程序指令的存储器；所述处理器执行所述计算机程序指令时实现如上述任一所述应用商店中的应用程序的处理方法。

在本申请实施例中，接收应用程序的安装文件；判断所述应用程序是否上架成功；在所述应用程序上架成功的情况下，显示所述应用程序的上架状态为成功。从而使得应用程序商店客户端在安装应用程序时，能够无障碍地进行，提高了应用程序的安装效率。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，使得本申请的其它特征、目的和优点变得更明显。本申请的示意性实施例附图及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种应用程序安装方法的流程图；

图2是根据本申请实施例的一种应用商店中的应用程序的处理方法的流程图；

图3是根据本申请实施例的一种上架新应用的方法的流程图；

图4是根据本申请实施例的一种电子设备的结构示意图。

具体实施方式

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

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

由于三方应用程序的安装依赖要求无法预知，而系统软件源很难完全匹配三方应用程序的要求，所以经常需要用户手动/其他方式修改系统依赖库地址的配置。一方面用户体验不好，有时还需要用户自行解决依赖冲突。另一方面造成不同的三方应用程序，在不同的系统环境中会出现安装失败，需要用户自行调查、解决。

对于专业的Linux使用者而言，可以通过Google或者百度等检索查询下载所需依赖或者编程修改所需依赖关系自行解决，但当将Linux操作系统推广至普通计算机用户，则导致了使用门槛和不良好的使用体验。

本申请涉及到的专业术语

软件源，Linux下的应用程序安装库，可以位于网络服务器、光盘或存储器上的文件夹。

应用商店，用于面向终端用户提供应用程序安装服务的应用，其向终端用户显示各种在对应操作系统上可以安装的应用程序，终端用户可通过点击对应的应用程序的图标进行下载和安装。

在本发明中，应用商店至少支持Linux系统下的应用程序；进一步的，由于可以在Linux系统上通过容器或虚拟机技术部署Android运行环境，应用商店还可以支持Android系统下的应用程序。

基于此，本申请提出了一种应用商店的应用程序的上架方法，参见附图1所示流程图；应用于应用程序服务端，该方法包括：

步骤S102，接收应用程序的安装文件；

例如，开发者通过邮件或者FTP或者上传界面，提供应用程序的安装文件，服务端接收应用程序的安装文件。

步骤S104，判断所述应用程序是否上架成功；如果是，则执行步骤S106；如果否，则执行步骤S108；

具体的，根据安装文件判断该应用程序是否上架成功。

步骤S106，显示所述应用程序的上架状态为成功；

步骤S108，显示所述应用程序的上架状态为失败。

在一些实施例中，还可以根据应用程序是否上架成功的状态，给予开发者通知，例如电子邮件自动回复上架成功或失败，例如在开发者操作界面弹出通知上架成功或失败。

本发明的上架方法，应用程序服务端，接收到安装文件后，根据安装文件判断是否上架成功，如果上架成功，则显示上架状态为成功。提高了应用程序客户端在安装应用程序的成功率，提高了安装应用程序的效率。

在一种实施方式中，将上架成功的应用程序生成当前可安装应用程序列表；

具体的，可安装应用程序列表中包括了每一个可安装应用程序的描述信息和图片。描述信息可包括该应用程序的名称、版本、简介、更新时间、大小等。图片为该应用程序的图标或者典型使用界面图。

应用程序商店服务端接收应用程序商店客户端发送的当前可安装应用程序列表的查询请求消息后，将所述应用程序列表发送给所述应用程序商店客户端。

在一种实施方式中，将上架成功的应用程序生成当前可安装应用程序列表，包括：根据每个应用程序所需的依赖数量，依序排列。

其中，依赖是指应用程序需要的依赖安装包。

其中，依序排列指的是按照时间、大小、数量等从大到小或者从小到大排列。

例如，在所述应用程序列表中，统计每个应用程序的需要安装的依赖的数量；按照依赖数量从大到小进行排序。如果没有依赖，则在所述应用程序列表中按照应用程序的历史安装次数从大到小的顺序进行排序。

示例性的，如果WPS需要的依赖数量为2个；如果Firefox安装需要依赖的数量为4个，则在应用程序列表中，Firefox的排名靠前，WPS排序靠后。

示例性的，如果微信、支付宝，在安装时不需要依赖，则在应用程序列表中，按照历史安装的次数从大到小进行排序。如果微信历史安装的次数为10次，支付宝的历史安装的次数为6次；则微信排在支付宝的前面。

第二方面，本申请还提出了一种应用商店中的应用程序的处理方法，应用于软件源控制端，参见附图2所示的一种应用商店中的应用程序的处理方法的流程图；该方法包括：

步骤S202，获取应用程序的信息和在应用商店的上架请求；

例如，应用程序的信息包括其名称、大小、版本等；

步骤S204，获得所述应用程序的安装文件；

步骤S206，分析和处理所述应用程序的依赖；

具体的，根据安装文件确定依赖。对依赖进行分析和处理，具体包括，如果发现缺乏依赖，则下载依赖。

步骤S208，发布所述应用程序。

本发明的上述的方法，软件源控制端在应用程序发布时，进行了依赖分析处理，把安装需要用到的依赖都下载好之后再发布。从而避免了用户的客户端进行应用程序安装时，用户自行下载相关的插件，软件等，提高了用户的效率和体验度。

发布所述应用程序和与所述应用程序对应的依赖。

例如，索引文件可以是描述安装文件、依赖包等名称、路径及其依赖关系、校验文件的文件。

例如，校验文件可以是安装文件、依赖包等名称、路径的MD5校验码。

在一种实施方式中，还包括：在发布所述应用程序之后，向应用商店发送所述应用程序上架成功的通知。

例如，通知可以是邮件通知或者弹窗消息。

为了更好的说明本发明的技术方案的实现方式，以Linux下的应用商店接收deb格式应用程序安装文件为例，参考附图3.

以上架deb文件格式的新应用为例，deb应用发布的流程如下：

应用商店服务端收到开发者上传的deb文件格式的应用；

应用商店服务端将原始应用A的安装包上传到下载服务；【3->6】；

应用商店服务端将应用信息及操作类型通知远端的控制服务，告知应用A请求上架；【3->4】；

控制服务通过下载服务将应用包下载到本地并分析依赖；【6->4】；

控制服务将应用A发布到软件源，并将A需要的依赖软件发布到软件源，并触发软件源的扫描动作；【4->5】；

控制服务对软件源的发布成功后，通知应用商店服务端应用A上架成功。

应用商店服务端将应用A状态改为成功上架，对外接口可以查询。

Deb文件格式的应用安装的流程如下：

应用商店客户端向服务端查询当前可安装应用列表；【2->3】；

应用商店客户端显示服务端下发的各项描述信息及图片等；

当用户点击安装应用A时，应用商店调用操作系统接口，使用当前默认系统软件源地址安装应用A。【1->5】；

安装应用A时，发现有A有若干依赖的软件需要安装，则直接从前默认系统软件源地址下载安装。【1->5】；

全部安装成功后，应用商店提示用户安装结果。

本发明的技术方案在第三方应用发布时，即动态修改、扫描当前系统软件源中的各个软件，在应用发布环节就准备好了应用所需的各个依赖软件。

将安装的各种软件依赖没有找到的问题，软件依赖的版本要求问题，从终端用户侧解决改到了从系统软件源侧解决；从需要用户参与解决改为系统软件源以及应用商店维护者解决。

对于终端系统用户来说，默认的系统软件源可以保证应用商店中的应用程序安装时的各种依赖软件及以来软件版本的要求，不需要用户进行干预或自行解决软件冲突。有依赖冲突的第三方应用程序在软件发布环节就已经发现，拒绝发布，并给开发者相关的提示。

另一方面，对应用程序的开发者而言，可以认为标准的默认软件源中各软件的版本即为终端用户的实际环境，因为标准的软件源的动态变更，维护，已经能满足用户从应用商店中安装应用的各种问题，减少了用户自行变更系统软件源配置，自行变更各个依赖软件的情况。从而对应用软件自身，减少了各种系统环境引起的不确定性，在发布环节就能知晓自身的依赖与系统默认软件源的兼容问题，可以提前解决，减少对各种兼容性测试的依赖。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

第三方面，本申请还提供了一种电子设备，参见附图4所示的一种电子设备的结构示意图，该设备包括：至少一个处理器41和至少一个存储器42；所述存储器42用于存储一个或多个程序指令；所述处理器41，用于运行一个或多个程序指令，用以执行上述任意一项的方法。

第四方面，本申请还提出了一种计算机可读存储介质，计算机可读存储介质中包含一个或多个程序指令，所述一个或多个程序指令用于执行上述任一项所述的方法。

可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。处理器读取存储介质中的信息，结合其硬件完成上述方法的步骤。

存储介质可以是存储器，例如可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。

其中，非易失性存储器可以是只读存储器(Read-Only Memory，简称ROM)、可编程只读存储器(Programmable ROM，简称PROM)、可擦除可编程只读存储器(Erasable PROM，简称EPROM)、电可擦除可编程只读存储器(Electrically EPROM，简称EEPROM)或闪存。

易失性存储器可以是随机存取存储器(Random Access Memory，简称RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(SDRAM)、双倍数据速率同步动态随机存取存储器(DDR SDRAM)、增强型同步动态随机存取存储器(EnhancedSDRAM)、同步连接动态随机存取存储器(Synchlink DRAM)和直接内存总线随机存取存储器(DirectRambus RAM)。

其中，处理器可以采用通用的中央处理器(CPU)、微处理器(MCU)、应用专用集成电路(ASIC)、现场可编程逻辑门阵列(FPGA)或者一个或多个集成电路等方式实现，用于执行与其对应的一个或多个计算机指令。

尽管未在图中示意，本领域技术人员可以理解，为了实现对电子设备的操作、控制、内容传输，还可以有输入/输出接口和通信接口。例如输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。通信接口可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

本发明实施例描述的存储介质旨在包括但不限于这些和任意其它适合类型的存储器。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件与软件组合来实现。当应用软件时，可以将相应功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种应用商店中的应用程序的上架方法，其特征在于，包括：

接收应用程序的安装文件；

判断所述应用程序是否上架成功；

如果所述应用程序上架成功，显示所述应用程序的上架状态为成功。

2.根据权利要求1所述的上架方法，其特征在于，还包括：

将上架成功的应用程序生成当前可安装应用程序列表；

3.根据权利要求2所述的上架方法，其特征在于，将上架成功的应用程序生成当前可安装应用程序列表，包括：

根据每个应用程序所需的依赖数量，依序排列。

4.根据权利要求2所述的上架方法，其特征在于，将上架成功的应用程序生成当前可安装应用程序列表，包括：

5.一种应用商店中的应用程序的处理方法，其特征在于，包括：

获取应用程序的信息和在应用商店的上架请求；

获得所述应用程序的安装文件；

分析和处理所述应用程序的依赖；

发布所述应用程序。

6.根据权利要求5所述的处理方法，其特征在于，分析和处理所述应用程序的依赖，发布所述应用程序，包括：

发布所述应用程序和与所述应用程序对应的依赖。

7.根据权利要求6所述的处理方法，其特征在于，还包括：生成包括每个应用程序和与其所对应的依赖关系的索引及校验文件。

8.根据权利要求7所述的处理方法，其特征在于，还包括：响应于更新所述应用程序和/或与其对应的依赖、删除所述应用程序和/或与其对应的依赖、修改所述应用程序和/或与其对应的依赖操作中的任一者，更新所述索引及校验文件。

9.根据权利要求5所述的处理方法，还包括：在发布所述应用程序之后，向应用商店发送所述应用程序上架成功的通知。

10.一种计算机设备，其特征在于，包括：处理器以及存储有计算机程序指令的存储器；所述处理器执行所述计算机程序指令时实现如权利要求1-4任一所述应用商店中的应用程序的上架方法。

11.一种计算机设备，其特征在于，包括：处理器以及存储有计算机程序指令的存储器；所述处理器执行所述计算机程序指令时实现如权利要求5-9任一所述应用商店中的应用程序的处理方法。