客户端应用功能热更新文件的灰度发布方法及相关设备

摘要

本说明书一个或多个实施例提供一种客户端应用功能热更新文件的灰度发布方法及相关设备。该方法包括：响应于客户端上的应用被启动，所述客户端获取在本地预先存储的客户标签，并从与所述客户端通信连接的服务器获取与所述应用的功能热更新文件关联的条件标签；所述客户端确定所述客户标签与所述条件标签是否匹配；响应于确定所述客户标签与所述条件标签匹配，所述客户端从所述服务器获取所述功能热更新文件，并用所述功能热更新文件来更新所述应用。这种方法及相关设备能够向用户推送符合自身使用习惯的功能热更新文件，而非将更新文件进行全量下载，也不会对客户的权限控制造成影响。

说明书

技术领域

本说明书一个或多个实施例涉及应用开发领域，尤其涉及一种客户端应用功能热更新的灰度发布方法及相关设备。

背景技术

随着移动互联网的不断深入发展，手机应用开发者需要设计多种不同页面、交互风格的功能投放至线上，以验证用户偏好，从而选择最佳的实现方式。这种在一定范围内验证不同实现方式被用户接受程度的方法，被称之为灰度发布。

手机应用开发者在设计一个新功能的页面UI、交互流程时，往往不一定能够满足用户的最佳要求。另外，新功能正式上线前，需要寻找部分用户提前试用，已验证该功能的可用度和用户的接受程度。

现有的技术一般采用权限控制的方法，即在所有用户的应用上包含了所有样式的所有功能。程序会根据用户的权限，为用户展示不同的功能，以实现灰度发布的效果。这种实现方案的主要问题是：

1、会浪费用户更新应用的流量。一方面，系统无法根据用户是哪一种灰度用户来选择性地只更新此类灰度用户需要看到的页面或者功能，只能更新所有的内容；另一方面即使该用户不是灰度发布的目标用户，其也需要将客户端进行全量更新。

2、权限控制容易混乱。基于这种实现方案，当完成灰度发布之后，需要将所有用户都切换为同一个权限。如果也有其他功能依赖于这个权限，则会导致其他功能出现问题。

发明内容

有鉴于此，本说明书一个或多个实施例的目的在于提出一种客户端应用功能热更新文件的灰度发布方法及相关设备，以解决无法根据用户信息进行相应的热更新的问题。

基于上述目的，本说明书一个或多个实施例提供了一种客户端应用功能热更新文件的灰度发布方法，包括：

响应于客户端上的应用被启动，所述客户端获取在本地预先存储的客户标签，并从与所述客户端通信连接的服务器获取与所述应用的功能热更新文件关联的条件标签；

所述客户端确定所述客户标签与所述条件标签是否匹配；

响应于确定所述客户标签与所述条件标签匹配，所述客户端从所述服务器获取所述功能热更新文件，并用所述功能热更新文件来更新所述应用。

基于同一发明目的，本说明书一个或多个实施例还提供了一种客户端应用功能热更新文件的灰度发布装置，根据功能可分为以下模块，包括：

标签获取模块，响应于客户端上的应用被启动，所述客户端获取在本地预先存储的客户标签，并从与所述客户端通信连接的服务器获取与所述应用的功能热更新文件关联的条件标签；

标签匹配模块，所述客户端确定所述客户标签与所述条件标签是否匹配；

热更新模块，响应于确定所述客户标签与所述条件标签匹配，所述客户端从所述服务器获取所述功能热更新文件，并用所述功能热更新文件来更新所述应用。

基于同一发明目的，本说明书一个或多个实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现客户端应用功能热更新文件的灰度发布方法。

基于同一发明目的，本说明书一个或多个实施例还提供了一种非暂态计算机可读存储介质，其中，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使计算机执行客户端应用功能热更新文件的灰度发布方法。

从上面所述可以看出，本说明书一个或多个实施例提供的一种客户端应用功能热更新文件的灰度发布方法及相关设备，能够提供一种更灵活更流畅的灰度发布的效果，并且节约了用户的流量。

附图说明

为了更清楚地说明本说明书一个或多个实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书一个或多个实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书一个或多个实施例提供的一种客户端应用功能热更新文件的灰度发布方法的流程图；

图2为本说明书一个或多个实施例提供的生成客户标签的流程示意图；

图3为本说明书一个或多个实施例提供的功能热更新文件上传的流程示意图；

图4为本说明书一个或多个实施例提供的应用热更新的流程图；

图5为本说明书一个或多个实施例提供的一种客户端应用功能热更新文件的灰度发布装置的结构示意图；

图6为本说明书一个或多个实施例提供的电子设备结构示意图。

具体实施方式

为使本公开的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本公开进一步详细说明。

需要说明的是，除非另外定义，本说明书一个或多个实施例使用的技术术语或者科学术语应当为本公开所属领域内具有一般技能的人士所理解的通常意义。本说明书一个或多个实施例中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而只是用来区分不同的组成部分。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。

如背景技术所述，在现有的灰度发布方法中，在所有用户的应用上包含了所有样式的所有功能，会根据用户的权限展示不同的功能，以实现灰度发布的效果。但是，由于系统无法根据用户是哪一种灰度用户来选择性地只更新此类灰度用户需要看到的页面或者功能，在应用更新的过程中只能更新所有的内容；另一方面即使该用户不是灰度发布的目标用户，也需要将应用进行全量更新。而且，现有的灰度发布方法还面临着权限控制容易混乱的问题：基于这种灰度发布方法，当完成灰度发布之后，需要将所有用户都切换为同一个权限，如果也有其他功能依赖于这个权限，则会导致其他功能出现问题。

本说明书一个或多个实施例提出了一种客户端应用功能热更新文件的灰度发布方法及相关设备，用来解决现有的灰度发布方法面临的问题。首先，由应用收集用户信息生成客户标签存储在客户端；服务器为功能热更新文件配置能够与客户标签匹配的条件标签；用户启动应用时，应用从服务端获取功能热更新文件的条件标签与客户标签进行匹配，匹配成功则下载对应的功能热更新文件并解压，令解压得到的文件覆盖原有的文件完成热更新；否则正常启动该应用。

本说明书一个或多个实施例提出了一种客户端应用功能热更新文件的灰度发布方法，参考图1，其步骤如下：

步骤S101、响应于客户端上的应用被启动，所述客户端获取在本地预先存储的客户标签，并从与所述客户端通信连接的服务器获取与所述应用的功能热更新文件关联的条件标签。

本步骤中，将收集到的用户信息上传至服务器，采用包括MapReduce(并行处理计算模型)、Spark(计算引擎)、HDFS(分布式文件系统)、Hive(数据仓库工具)、HBase在内的技术对用户信息进行处理，将生成的客户标签存储在应用客户端。其中安卓版和iOS版采用的存储技术不同，安卓版采用SharedPreferrences进行存储，iOS采用NSUserDefaults进行存储。

步骤S102、所述客户端确定所述客户标签与所述条件标签是否匹配。

步骤S103、响应于确定所述客户标签与所述条件标签匹配，所述客户端从所述服务器获取所述功能热更新文件，并用所述功能热更新文件来更新所述应用。

本步骤中，采用了Webview热更新技术，Web页面可以放在远程服务器上，也可以放在手机本地。将Web页面按照H5标准进行开发并实现相应的功能，并放在手机本地存储中，然后利用Webview打开本地的这些H5标准的Web页面文件，便可以实现手机应用功能页面；同时，手机应用可以下载服务器上的H5页面压缩包，并动态覆盖本地的H5页面文件；覆盖完成之后，Webview再次打开的页面就是更新之后的页面。这就是实现了功能页面的热更新。

以下，结合具体的实施例对本说明书提供的技术方案进行描述。

参考图2，本说明书一个或多个实施例提供了一种客户标签生成方法，其步骤如下：

步骤S201、用户注册。

本步骤中，用户填写能通过验证的手机号码和密码进行应用注册。

步骤S202、获取用户设备信息。

本步骤中，系统会收集并存储用户注册时的时间、IP地址、地理位置信息等，同时收集应用所在手机设备的品牌、型号、操作系统和设备号，并存储至数据库。

步骤S203、用户实名认证。

本步骤中，将用户实名认证时使用的姓名、性别、证件类型、证件号码、出生日期等进行存储。

步骤S204、获取用户保单信息。

本步骤中，根据实名数据拉取业务相关的数据。比如在保险类应用中，可根据实名认证信息查询客户的保单信息，供后续计算标签使用。

步骤S205、初始化客户标签。

本步骤中，对之前步骤手机的注册id、注册时间、IP地址、地理位置、手机设备的品牌、型号、操作系统、设备号、姓名、性别、证件类型、证件号码、出生日期及业务类信息如保单信息等进行加工处理，生成数据标签。

首先进行数据清洗，将上述用户信息转化为标准格式的待处理数据；然后由运营人员制定客户标签生成规则并由开发人员编写程序实现该规则；最后使用开发人员完成的程序对待处理数据进行处理得到客户标签。

步骤S206、客户端存储客户标签。

参考图3，本说明书一个或多个实施例提供了一种功能热更新文件上传方法，其步骤如下：

步骤S301、生成功能热更新文件。

本步骤中，对包括功能页面所需要使用的基于H5标准的HTML(超文本标记语言)文件、js文件、css(层叠样式表)文件、图片及配置文件在内的文件按照预设的目录结构进行组织并打包生成功能热更新文件。

步骤S302、选择功能热更新文件的条件标签。

本步骤中，将功能热更新文件与条件标签进行对应，并制定具体的版本号。

步骤S303、将功能热更新文件上传至服务器。

本步骤中，将功能热更新文件上传并按照“/版本号/压缩包”的格式在服务器上进行存储。

参考图4，本说明书一个或多个实施例提供了一种应用热更新方法，其步骤如下：

步骤S401、用户打开应用。

步骤S402、应用获取本地用户的客户标签。

步骤S403、请求后台接口，获取条件标签。

步骤S404、检查标签是否匹配。

本步骤中，客户标签与条件标签匹配，进入步骤S405继续后续操作；否则，进入步骤S407正常打开应用。

标签匹配的过程举例如下：用户登录应用后，产生的标签为“性别：女，地区：北京，手机操作系统：安卓，手机品牌：华为，有无长险保单：有”。

若热更新文件中对应的标签为“性别：女，有无长险保单：有”。此时用户的标签中，“性别”和“有长险保单”与热更新版本中的“性别”和“有长险保单”这两个字段对应的值一致，则认为标签匹配。

若热更新版本中对应的标签为“性别：女，有无长险保单：无”。此时，用户的“有无长险保单”字段的值和热更新版本中要求的不一致，则认为不匹配。

若热更新版本中对应的标签为“地区：北京或天津，有无长险保单：有”。此时，用户的“有无长险保单”字段的值和热更新版本中要求的一致，并且“地区”字段的值在热更新版本的标签字段“地区”要求的范围内，则认为匹配。

即用户在客户端存储的标签字段的值与热更新版本中条件标签要求的字段的值完全一致，或用户标签的字段值在热更新版本中条件标签要求的字段值的范围内，才认为标签匹配，否则认为不匹配。

步骤S405、请求灰度热更新接口，获取功能热更新文件。

步骤S406、解压功能热更新文件并覆盖原文件。

步骤S407、进入应用。

通过本说明书一个或多个实施例展现出来的客户端应用功能热更新文件的灰度发布方法，可以根据应用用户的个人信息和业务信息为其推荐符合用户需求的功能热更新文件进行应用的更新，避免了传统应用更新方法中需要由客户全量下载更新文件，以及会影响用户的权限设置的问题；能够使灰度发布更加灵活流畅，并节约了用户的流量。

需要说明的是，本说明书一个或多个实施例的方法可以由单个设备执行，例如一台计算机或服务器等。本实施例的方法也可以应用于分布式场景下，由多台设备相互配合来完成。在这种分布式场景的情况下，这多台设备中的一台设备可以只执行本说明书一个或多个实施例的方法中的某一个或多个步骤，这多台设备相互之间会进行交互以完成所述的方法。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

基于同一发明构思，与上述任意实施例方法相对应的，本说明书一个或多个实施例还提供了一种客户端应用功能热更新文件的灰度发布装置。

参考图5，所述客户端应用功能热更新文件的灰度发布装置，包括：

标签获取模块501，响应于客户端上的应用被启动，所述客户端获取在本地预先存储的客户标签，并从与所述客户端通信连接的服务器获取与所述应用的功能热更新文件关联的条件标签。

标签匹配模块502，所述客户端确定所述客户标签与所述条件标签是否匹配。

热更新模块503，响应于确定所述客户标签与所述条件标签匹配，所述客户端从所述服务器获取所述功能热更新文件，并用所述功能热更新文件来更新所述应用。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书一个或多个实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现。

上述实施例的装置用于实现前述实施例中相应的客户端应用功能热更新文件的灰度发布方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本说明书一个或多个实施例还提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上任意一实施例所述的客户端应用功能热更新文件的灰度发布方法。

图6示出了本实施例所提供的一种更为具体的电子设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(应用lication Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线1050包括一通路，在设备的各个组件(例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

上述实施例的电子设备用于实现前述任一实施例中相应的客户端应用功能热更新文件的灰度发布方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

基于同一发明构思，与上述任意实施例方法相对应的，本说明书一个或多个实施例还提供了一种非暂态计算机可读存储介质，所述非暂态计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行如上任一实施例所述的客户端应用功能热更新文件的灰度发布方法。

本实施例的计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上述实施例的存储介质存储的计算机指令用于使所述计算机执行如上任一实施例所述的客户端应用功能热更新文件的灰度发布方法，并且具有相应的方法实施例的有益效果，在此不再赘述。

所属领域的普通技术人员应当理解：以上任何实施例的讨论仅为示例性的，并非旨在暗示本公开的范围(包括权利要求)被限于这些例子；在本公开的思路下，以上实施例或者不同实施例中的技术特征之间也可以进行组合，步骤可以以任意顺序实现，并存在如上所述的本说明书一个或多个实施例的不同方面的许多其它变化，为了简明它们没有在细节中提供。

另外，为简化说明和讨论，并且为了不会使本说明书一个或多个实施例难以理解，在所提供的附图中可以示出或可以不示出与集成电路(IC)芯片和其它部件的公知的电源/接地连接。此外，可以以框图的形式示出装置，以便避免使本说明书一个或多个实施例难以理解，并且这也考虑了以下事实，即关于这些框图装置的实施方式的细节是高度取决于将要实施本说明书一个或多个实施例的平台的(即，这些细节应当完全处于本领域技术人员的理解范围内)。在阐述了具体细节(例如，电路)以描述本公开的示例性实施例的情况下，对本领域技术人员来说显而易见的是，可以在没有这些具体细节的情况下或者这些具体细节有变化的情况下实施本说明书一个或多个实施例。因此，这些描述应被认为是说明性的而不是限制性的。

尽管已经结合了本公开的具体实施例对本公开进行了描述，但是根据前面的描述，这些实施例的很多替换、修改和变型对本领域普通技术人员来说将是显而易见的。例如，其它存储器架构(例如，动态RAM(DRAM))可以使用所讨论的实施例。

本说明书一个或多个实施例旨在涵盖落入所附权利要求的宽泛范围之内的所有这样的替换、修改和变型。因此，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何省略、修改、等同替换、改进等，均应包含在本公开的保护范围之内。