一种应用的更新方法和系统与流程

本发明实施例涉及应用管理技术领域，尤其涉及一种应用的更新方法和系统。

背景技术：

随着终端和互联网的普及，应用(application，APP)被广泛的安装于终端，以满足用户不同的需求。

在现有技术中，对应用的更新主要是基于后台的维护人员不定期或定期的更新，可通过发送更新提示消息的方式告知用户，以便用户确定是否对应用进行更新。

发明人在实现本发明的过程中，发现至少存在以下技术问题：

针对应用的所有用户同时进行同样的更新，缺少灵活性。

技术实现要素：

本发明所要解决的技术问题是针对现有技术中所存在的上述缺陷，提供一种应用的更新方法和系统，用以解决现有技术中存在更新应用缺少灵活性的问题。

根据本发明实施例的一个方面，本发明实施例提供了，一种应用的更新方法，所述方法包括：

根据获取到的用户标识和应用标识，从预设数据库中获取预设时间段内的分别与所述用户标识和所述应用标识对应的浏览记录；

根据所述浏览记录确定用户对应用的子业务功能的偏好信息，其中，所述用户与所述用户标识对应，所述应用与所述应用标识对应；

根据所述偏好信息对所述应用进行更新。

在一些实施例中，所述根据所述浏览记录确定用户对应用的子业务功能的偏好信息，包括：

根据所述浏览记录生成所述用户使用所述应用的行为轨迹链；

根据所述行为轨迹链确定所述偏好信息。

在一些实施例中，在所述根据获取到的用户标识和应用标识，从预设数据库中获取预设时间段内的分别与所述用户标识和所述应用标识对应的浏览记录之前，还包括：

接收所述用户发送的访问所述应用的请求；

获取所述用户访问所述应用的历史访问记录；

根据所述历史访问记录判断所述用户是否为活跃用户；

如果是，则获取所述用户标识和所述应用标识。

在一些实施例中，所述根据所述历史访问记录判断所述用户是否为活跃用户，包括：

从所述历史访问记录中提取所述用户登录所述应用的次数；

响应于所述次数大于预设的第一阈值，则将所述用户确定为活跃用户。

在一些实施例中，所述根据所述历史访问记录判断所述用户是否为活跃用户，包括：

根据所述历史访问记录中确定所述用户使用所述应用的使用率；

响应于所述使用率大于预设的第二阈值，则将所述用户确定为活跃用户。

在一些实施例中，所述浏览记录包括下述至少一种：

浏览时长、浏览路径、子业务功能的开启时长、子业务功能的开启次数、子业务功能之间的跳转路径。

根据本发明实施例的另一个方面，本发明实施例提供了一种应用的更新系统，所述系统包括：

获取模块，用于根据获取到的用户标识和应用标识，从预设数据库中获取预设时间段内的分别与所述用户标识和所述应用标识对应的浏览记录；

确定模块，用于根据所述浏览记录确定用户对应用的子业务功能的偏好信息，其中，所述用户与所述用户标识对应，所述应用与所述应用标识对应；

更新模块，用于根据所述偏好信息对所述应用进行更新。

在一些实施例中，所述确定模块具体用于：

根据所述浏览记录生成所述用户使用所述应用的行为轨迹链；

根据所述行为轨迹链确定所述偏好信息。

在一些实施例中，所述系统还包括：

接收模块，用于接收所述用户发送的访问所述应用的请求；

所述获取模块还用于，获取所述用户访问所述应用的历史访问记录；

判断模块，用于根据所述历史访问记录判断所述用户是否为活跃用户；

如果是，则所述获取模块还用于，获取所述用户标识和所述应用标识。

在一些实施例中，所述判断模块具体用于：

从所述历史访问记录中提取所述用户登录所述应用的次数；

响应于所述次数大于预设的第一阈值，则将所述用户确定为活跃用户。

在一些实施例中，所述判断模块具体用于：

根据所述历史访问记录中确定所述用户使用所述应用的使用率；

响应于所述使用率大于预设的第二阈值，则将所述用户确定为活跃用户。

本发明实施例的有益效果在于，由于采用了根据获取到的用户标识和应用标识，从预设数据库中获取预设时间段内的分别与用户标识和应用标识对应的浏览记录，根据浏览记录确定用户对应用的子业务功能的偏好信息，其中，用户与用户标识对应，应用与应用标识对应，根据偏好信息对应用进行更新的技术方案，由于是基于该用户对该应用的子业务功能的偏好信息进行更新，可以实现针对不同的用户的喜欢对同一应用进行不同的更新，进而实现更新的多元性，以满足不同的用户的需求。

附图说明

图1为本公开实施例的应用的更新方法的示意图；

图2为本公开实施例的根据浏览记录确定用户对应用的子业务功能的偏好信息的示意图；

图3为本公开实施例的触发获取用户标识和应用标识的示意图；

图4为本公开实施例的应用的更新系统的示意图；

图5为本公开另一实施例的应用的更新系统的示意图；

附图标记：

1、获取模块，2、确定模块，3、更新模块，4、接收模块，5、判断模块。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之类的具体细节，以便透彻理解本发明。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的系统、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。

本发明实施例提供了一种应用的更新方法和系统。

根据本发明实施例的一个方面，本发明实施例提供了一种应用的更新方法。

请参阅图1，图1为本公开实施例的应用的更新方法的示意图。

如图1所示，该方法包括：

S1：根据获取到的用户标识和应用标识，从预设数据库中获取预设时间段内的分别与用户标识和应用标识对应的浏览记录。

其中，数据库中存储了不同的用户浏览不同的应用的浏览记录。

为了对不同的用户进行区分，为每个用户分配一个用户标识。由于每个终端都有其独一无二的编号，因此，用户标识可以是用户对应的终端编号。当然，也可采用用户的手机号码作为用户标识。当然，还可以是通过用户预设的标识(如用户名等)作为用户标识。

同理，为了对不同的应用进行区分，为每个应用分配一个应用标识。

可以理解的是，同一用户可同时在其终端上安装多个应用。即同一用户可通过同一终端访问不同的应用。在该步骤中，先通过用户标识在数据库中查询到该用户的浏览所有应用的浏览记录，再从所有应用的浏览记录中提取与应用标识对应的浏览记录。

S2：根据浏览记录确定用户对应用的子业务功能的偏好信息，其中，用户与用户标识对应，应用与应用标识对应。

可以理解的是，一个应用包括多个子业务功能，不同的子业务功能满足用户的不同的应用需求。如，优酷应用(即安装在终端上的优酷APP)分为不同的子业务功能(电视，电影，综艺等)。其中，子业务功能-电视主要满足用户观看连续剧。

由于用户与用户之间的差异性，因此，不同的用户对同一应用的不同的子业务功能的偏好程度并不相同。如，部分用户喜欢观看连续剧，则其必然偏好子业务功能-电视。而喜欢观看电影的用户，则其必然偏好子业务功能-电影。

在该步骤中，基于浏览记录可确定某用户对某应用的子业务功能的偏好信息。

S3：根据偏好信息对应用进行更新。

在该步骤中，当确定偏好信息好，可基于该偏好信息对该应用进行更新。

由S1至S3可知，在本公开实施例中，采用的技术方案为：获取某用户访问某应用的浏览记录，基于该浏览记录获悉该用户对该应用的子业务功能的偏好信息，进而基于该偏好信息对该应用进行更新，由于是基于该用户对该应用的子业务功能的偏好信息进行更新，可以实现针对不同的用户的喜欢对同一应用进行不同的更新，进而实现更新的多元性，以满足不同的用户的需求。

结合图2可知，在一些实施例中，S2包括：

S2-1：根据浏览记录生成用户使用应用的行为轨迹链。

其中，浏览记录包括下述至少一种：

浏览时长、浏览路径、子业务功能的开启时长、子业务功能的开启次数、子业务功能之间的跳转路径。

当然，浏览记录还可包括用户登录应用的时间等。此处不再一一列举。

S2-2：根据行为轨迹链确定偏好信息。

结合图3可知，在一些实施例中，在S1之前，还包括：

S01：接收用户发送的访问应用的请求。

S02：获取用户访问应用的历史访问记录。

S03：根据历史访问记录判断用户是否为活跃用户。如果是，则执行S04。如果否，则流程结束。

S04：获取用户标识和应用标识。

其中，S1至S3的具体方案请参见上述实施例，此处不再赘述。

在本公开实施例中，采用的技术方案为：在接收到用户访问某应用的请求后，获取该用户访问该应用的历史访问记录，以便基于该历史访问记录确定该用户是否为活跃用户(是针对该应用而言)，如果该用户为活跃用户，则对用户标识和应用标识进行获取，以便最终对该应用进行更新。

也就是说，在本公开实施例中，在确定用户为活跃用户时，则执行后续更新步骤。而在现有技术中，是基于后台工作人员定期或不定期的对应用进行更新。因此，通过本公开实施例提供的上述技术方案，对应用的更新无需人为进行控制，从而可以实现更新应用的灵活性。且，由于避免了后台工作人员的主观因素的影响，可实现更新应用的准确性和及时性。且，若某用户为非活跃用户，则结束流程，即无需对应用进行更新。而在现有技术中，但凡到了规定更新的时间，会对所有用户对应的该应用均进行更新，从而造成了资源浪费的技术弊端。也就是说，通过本公开实施例提供的技术方案，还可实现节约资源的技术效果。

在一些实施例中，S03包括：

S03-1：从历史访问记录中提取用户登录应用的次数。

S03-2：响应于次数大于预设的第一阈值，则将用户确定为活跃用户。

其中，第一阈值可基于实际需求进行设定。

在一些实施例中，S03包括：

S03-1’：根据历史访问记录中确定用户使用应用的使用率。

S03-2’：响应于使用率大于预设的第二阈值，则将用户确定为活跃用户。

同理，第二阈值也可基于实际需求进行设定。

根据本发明实施例的另一个方面，本发明实施例提供了与上述方法相对应的一种应用的更新系统。

请参阅图4，图4为本公开实施例的应用的更新系统的示意图。

如图4所示，该系统包括：

获取模块1，用于根据获取到的用户标识和应用标识，从预设数据库中获取预设时间段内的分别与用户标识和应用标识对应的浏览记录；

确定模块2，用于根据浏览记录确定用户对应用的子业务功能的偏好信息，其中，用户与用户标识对应，应用与应用标识对应；

更新模块3，用于根据偏好信息对应用进行更新。

在一些实施例中，确定模块2具体用于：

根据浏览记录生成用户使用应用的行为轨迹链；

根据行为轨迹链确定偏好信息。

结合图5可知，在一些实施例中，该系统还包括：

接收模块4，用于接收用户发送的访问应用的请求；

获取模块1还用于，获取用户访问应用的历史访问记录；

判断模块5，用于根据历史访问记录判断用户是否为活跃用户；

如果是，则获取模块1还用于，获取用户标识和应用标识。

在一些实施例中，判断模块5具体用于：

从历史访问记录中提取用户登录应用的次数；

响应于次数大于预设的第一阈值，则将用户确定为活跃用户。

在一些实施例中，判断模块5具体用于：

根据历史访问记录中确定用户使用应用的使用率；

响应于使用率大于预设的第二阈值，则将用户确定为活跃用户。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以是两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

还应理解，在本发明各实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。