CN108762800A - 应用程序的动态更新方法和装置 - Google Patents

Abstract

本发明实施例提供一种应用程序的动态更新方法和装置，该方法包括：应用程序启动后，获取应用程序的资源包，校验资源包的目录下是否存在新的JS补丁包，若存在，则确定JS补丁包中的脚本文件版本与应用程序正在使用的脚本文件版本是否相同，若不同，则加载JS补丁包中的脚本文件，运行应用程序。该方案在程序加载过程中对补丁包进行校验决定使用补丁包中的脚本文件还是原来的脚本文件运行应用程序，能够不依赖发布新的版本来实现逻辑功能和界面的动态化，能及时的覆盖最新的版本，可以保证足够的稳定性和兼容性，尽量不受系统版本的影响。

Description

应用程序的动态更新方法和装置

技术领域

本发明涉及计算机技术领域，尤其涉及一种应用程序的动态更新方法和装置。

背景技术

随着智能终端设备的广泛应用，终端设备上的应用程序(Application，APP)也随着用户的需求变动，APP需要根据用户的需求进行资源更新。

现有技术中，提供一种插件化的方式对APP进行动态更新，该方式可以在不重新安装新包的情况下，来动态改变应用程序的内容。主要原理是使用Android内部的ClassLoader来动态加载新的类，来实现动态化。很多应用程序可以下载可选的插件来扩展程序的内容。还提供一种热修复的方式对APP进行动态更新，该方式多用于及时修复线上的已知问题，而不依赖发布新的版本。原理跟插件化类似，不同的是热修复可以动态修改原有的类，甚至有的框架可以直接修改具体的资源文件。

然而，插件化一般应用于动态下发新的插件，即意味只能动态添加，要实现的动态更新成本较高，稳定性不足。热修复强烈依赖于已添加的空白组件且实现极为复杂，稳定性上有欠缺，性能消耗比较大，综上所述，目前的APP动态更新的方案更新成本较高，且稳定性较差。

发明内容

本发明提供一种应用程序的动态更新方法和装置，用于解决目前的APP动态更新的方案更新成本较高，且稳定性较差的问题。

本发明第一方面提供一种应用程序的动态更新方法，包括：

根据应用程序的客户端发送的接口请求，使用预先配置的灰度策略，生成与所述接口请求对应的配置文件；

根据所述配置文件获取JS补丁包，所述JS补丁包包括更新的所述应用程序的脚本文件；

将所述JS补丁包发送给所述客户端。

可选的，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本发明第二方面提供一种应用程序的动态更新方法，包括：

应用程序启动后，获取所述应用程序的资源包；

校验所述资源包的目录下是否存在新的JS补丁包；

若存在，则确定所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本是否相同；

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本不同，则加载所述JS补丁包中的脚本文件，运行所述应用程序。

可选的，所述方法还包括：

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本相同，则加载所述本地使用的脚本文件，运行所述应用程序。

可选的，所述方法还包括：

所述应用程序启动后，校验所述应用程序的运行目录中的版本信息；

若所述运行目录中版本信息为空，则从资源文件夹获取所述应用程序的资源包；

若所述运行目录中版本信息不为空，则直接获取所述运行目录中存储的所述资源包。

可选的，所述方法还包括：

检测所述资源包的目录下是否存在新版本的JS补丁包；

若存在，则将所述JS补丁包解压至所述应用程序的运行目录下；

否则，从服务器下载所述应用程序的JS补丁包。

可选的，所述从服务器下载所述应用程序的JS补丁包之前，所述方法还包括：

向所述服务器发送接口请求，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本发明第三方面提供一种应用程序的动态更新装置，包括：

处理模块，用于根据应用程序的客户端发送的接口请求，使用预先配置的灰度策略，生成与所述接口请求对应的配置文件；

所述处理模块还用于根据所述配置文件获取JS补丁包，所述JS补丁包包括更新的所述应用程序的脚本文件；

发送模块，用于将所述JS补丁包发送给所述客户端。

可选的，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本发明第四方面提供一种应用程序的动态更新装置，包括：

获取模块，用于应用程序启动后，获取所述应用程序的资源包；

校验模块，用于校验所述资源包的目录下是否存在新的JS补丁包；

处理模块，用于若存在，则确定所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本是否相同；

所述处理模块还用于若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本不同，则加载所述JS补丁包中的脚本文件，运行所述应用程序。

可选的，所述处理模块还用于：

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本相同，则加载所述本地使用的脚本文件，运行所述应用程序。

可选的，所述处理模块还用于：

删除所述补丁包。

可选的，所述获取模块具体用于：

所述应用程序启动后，校验所述应用程序的运行目录中的版本信息；

若所述运行目录中版本信息为空，则从资源文件夹获取所述应用程序的资源包；

若所述运行目录中版本信息不为空，则直接获取所述运行目录中存储的所述资源包。

可选的，所述处理模块还用于：

检测所述资源包的目录下是否存在新版本的JS补丁包；

若存在，则将所述JS补丁包解压至所述应用程序的运行目录下；

否则，从服务器下载所述应用程序的JS补丁包。

可选的，所述装置还包括：

发送模块，用于向所述服务器发送接口请求，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本发明第五方面提供一种服务器，包括：存储器、处理器和发送器；所述存储器用于存储计算机程序；

所述处理器用于：

根据应用程序的客户端发送的接口请求，使用预先配置的灰度策略，生成与所述接口请求对应的配置文件；

根据所述配置文件获取JS补丁包，所述JS补丁包包括更新的所述应用程序的脚本文件；

所述发送器用于将所述补丁包发送给所述客户端。

可选的，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本发明第六方面提供一种终端设备，包括：存储器、处理器和接收器；所述存储器用于存储计算机程序；

所述处理器用于：

应用程序启动后，获取所述应用程序的资源包；

校验所述资源包的目录下是否存在新的JS补丁包；

若存在，则确定所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本是否相同；

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本不同，则加载所述JS补丁包中的脚本文件，运行所述应用程序。

可选的，所述处理器还用于：

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本相同，则加载所述本地使用的脚本文件，运行所述应用程序。

可选的，所述处理器还用于：

删除所述补丁包。

可选的，所述处理器具体用于：

所述应用程序启动后，校验所述应用程序的运行目录中的版本信息；

若所述运行目录中版本信息为空，则从资源文件夹获取所述应用程序的资源包；

若所述运行目录中版本信息不为空，则直接获取所述运行目录中存储的所述资源包。

可选的，所述处理器还用于：

检测所述资源包的目录下是否存在新版本的JS补丁包；

若存在，则将所述JS补丁包解压至所述应用程序的运行目录下；

否则，从服务器下载所述应用程序的JS补丁包。

可选的，所述终端设备还包括：发送器，用于向所述服务器发送接口请求，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本发明第七方面提供一种存储介质，包括：可读存储介质和计算机程序，所述计算机程序存储在所述可读存储介质中，所述计算机程序用于实现上述第一方面的一种应用程序的动态更新方法。

本发明第八方面提供一种存储介质，包括：可读存储介质和计算机程序，所述计算机程序存储在所述可读存储介质中，所述计算机程序用于实现上述第二方面的一种应用程序的动态更新方法。

本发明实施例提供的应用程序的动态更新方法和装置，应用程序启动后，获取应用程序的资源包，校验资源包的目录下是否存在新的JS补丁包，若存在，则确定JS补丁包中的脚本文件版本与应用程序正在使用的脚本文件版本是否相同，若不同，则加载JS补丁包中的脚本文件，运行应用程序。该方案在程序加载过程中对补丁包进行校验决定使用补丁包的脚本文件还是原来的脚本文件运行应用程序，能够不依赖发布新的版本来实现逻辑功能和界面的动态化，能及时的覆盖最新的版本，可以保证足够的稳定性和兼容性，尽量不受系统版本的影响。

附图说明

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

图1为本发明实施例提供的应用程序的动态更新方法实施例一的流程图；

图2为本发明实施例提供的应用程序的动态更新方法实施例二的流程图；

图3为本发明实施例提供的灰度系统的示意图；

图4为本发明实施例提供的客户端加载的流程示意图；

图5为本发明实施例提供的应用程序的动态更新装置实施例的结构示意图；

图6为本发明实施例提供的应用程序的动态更新装置实施例的结构示意图。

具体实施方式

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

针对现有技术中，插件化进行应用程序的更新的方式，插件化一般应用于动态下发新的插件，即意味只能动态添加，要实现的动态更新成本较高，稳定性不足。这也决定了它很难实现灰度系统。另外由于Android的清单文件的影响，只能添加已声明的组件。现在多采用填加空白组件来提前添加，但这样在数量上和灵活性上受到了很大的限制。热修复比插件化灵活，但是新添加组件的限制与插件化一致，强烈依赖于已添加的空白组件。另外热修复虽然功能强大，但是实现极为复杂，稳定性上有欠缺，性能消耗比较大。虽然可以实现灰度方案，但是下发包的生成较复杂，一般还是多应用于修复问题上，不应用于灰度。

针对上述问题，本发明提供一种应用程序的动态更新方法，能够不依赖发布新的版本来实现逻辑功能和界面的动态化，能及时的覆盖最新的版本，并且受各个系统(特别是Android系统)版本限制较小。另外可以保证足够的稳定性和兼容性，尽量不受系统版本的影响。同时可以实现更灵活的发布，可实现版本的灰度。下面通过几个具体实施方式，对本方案进行详细说明。

图1为本发明实施例提供的应用程序的动态更新方法实施例一的流程图，如图1所示，该应用程序的动态更新方法具体可在应用程序的服务器中，该应用程序的动态更新方法具体包括以下步骤：

S101：根据应用程序的客户端发送的接口请求，使用预先配置的灰度策略，生成与所述接口请求对应的配置文件。

在本步骤中，应用程序的客户端在请求接口的时候，会通过接口请求将自己的版本号、渠道号等内容作为参数传递被服务端的服务器，以便服务器能够根据这些内容，生成该客户端对应的配置文件。

该方案的一种具体的实现中，接口请求还可以携带该用户的VIP信息，即会员信息，以及所处城市信息等。

服务器在接收到终端设备通过应用程序客户端发送的版本号、渠道号、VIP信息、城市信息中的至少一个信息之后，可以根据预先设置的灰度策略，生成对应的配置文件。

S102：根据配置文件获取JS补丁包，JS补丁包包括更新的应用程序的脚本文件。

在本步骤中，服务器在确定了配置文件之后，可根据该配置文件引导这部分用户下载灰度包来实现灰度，然后获取该应用程序的更新的脚本文件，得到JavaScaript补丁包，即JS补丁包，这里的脚本文件指的是可以直接运行的程序文件，不需要在进行编译，一般来说JS补丁包打包过程中也不需要进行编译，这样补丁包的生成也比较容易，整个发布过程比较简洁。

S103：将补丁包发送给客户端。

在上述步骤中，用户可以根据该配置文件获取该应用程序对应的最新版本的补丁包，该补丁包并不是JAVA类的补丁包，而是JavaScaript补丁包，JS本身就是脚本语言，客户端可以直接进行加载。

本实施例提供的应用程序的动态更新方法，服务器根据接收到的客户端的接口请求，根据接口请求中信息生成对应的配置文件，然后根据配置文件获取补丁包并进行打包，打包成为JS脚本语言的补丁包，下发给客户端，以便客户端能够更容易的加载，整个发布过程也比较容易。

图2为本发明实施例提供的应用程序的动态更新方法实施例二的流程图，如图2所示，本实施例提供的应用程序的动态更新方法应用的用户的手机、平板电脑、电脑等终端设备中，即应用在应用程序的客户端中，该方法具体包括以下步骤：

S201：应用程序启动后，获取应用程序的资源包。

在本步骤中，应用程序启动之后，需要获取该应用程序的资源包，以便进行程序的启动运行，一种具体的获取方式包括：所述应用程序启动后，校验本地版本信息，其含义是校验应用程序的运行目录中的版本信息；若运行目录中的版本信息为空，则从资源文件夹(即Asset目录文件中进行解压)，获取所述资源包；若所述运行目录中的版本信息不为空，则直接获取该运行目录下存储的所述资源包。

该方案的含义是，客户端可以通过校验本地的版本信息的方式等确定获取应用程序的资源包的方式，如果本地版本为空，则可以从下载的资源文件夹(Asset目录文件)中进行解压获取该应用程序的资源到本地，如果本地版本不是空，则意味着本地文件中存在该资源包，直接获取即可。

S202：校验资源包的目录下是否存在新的JS补丁包。

S203：若存在，则确定JS补丁包中的脚本文件版本与应用程序正在使用的脚本文件版本是否相同。

在上述步骤中，确定获取到的资源包，即资源文件中是否有新的JS补丁包，如果有，则需要确定该JS补丁包中的脚本文件的版本与当前应用的APP的脚本文件版本是否一致，如果不一致，那么则需要将该已经下载的该JS补丁包中的文件解压至本地，即应用程序的运行目录下。

S204：若JS补丁包中的脚本文件版本与应用程序正在使用的脚本文件版本不同，则加载JS补丁包中的脚本文件，运行应用程序。

S205：若JS补丁包中的脚本文件版本与应用程序正在使用的脚本文件版本相同，则加载本地使用的脚本文件，运行应用程序。

在上述两个步骤中，其含义是如果JS补丁包中的脚本文件版本与本地使用的脚本文件版本不同，则可以知道当前使用的脚本文件版本并不是最新的版本，而且已经下载了较新版本的JS补丁包，因此可以将该JS补丁包进行解压，并加载解压后的脚本文件运行该应用程序。

如果版本相同，则直接加载本地的脚本文件运行该应用程序，同时说明该JS补丁包并不是最新版本，因此在加载应用程序的同时，可以将该JS补丁包删除。

在该方案的一种具体实现中，应理解，无论是应用解压的JS补丁包的脚本文件加载运行应用程序，还是应用之前的脚本文件加载应用程序，均可在加载同时或者之前之后进入异步补丁包下载流程，下载所述应用程序的新的JS补丁包。以便在程序下次启动时能够使用最新版本的脚本文件。对此本方案不做限制。具体实现过程中：终端设备检测该应用程序的资源包的目录下是否存在新版本的JS补丁包；若存在，则将JS补丁包解压至应用程序的运行目录下；否则，从服务器下载应用程序的JS补丁包。

该方案的具体实现中，为了能够从服务器下载JS补丁包，需要在应用程序启动的时候，向该服务器发送接口请求，用来请求访问接口，该接口请求至少包括应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本实施例提供的应用程序的动态更新方法，在应用程序启动后，获取应用程序的资源包，校验资源包的目录下是否存在新的补丁包，若存在，则确定JS补丁包中的脚本文件版本与本地使用的脚本文件版本是否相同，若JS补丁包的脚本文件版本与本地使用的脚本文件版本不同，则加载丁包中的JS脚本文件，运行应用程序。该方案在程序加载过程中对JS补丁包进行校验决定使用JS补丁包的脚本文件还是原来的脚本文件运行应用程序，能够不依赖发布新的版本来实现逻辑功能和界面的动态化，能及时的覆盖最新的版本，可以保证足够的稳定性和兼容性，尽量不受系统版本的影响。

图3为本发明实施例提供的灰度系统的示意图，如图3所示，在上述两个实施例的技术上，可知本发明提供的应用程序的动态更新方法分为两部分，一部分是动态的代码的下发，另外一部分是客户端补丁包的加载。

在版本包的下发上，可以直接使用自己的服务器下对应的补丁包。这样提高了发布新的版本的效率，类似于可以像Web端一样，依靠不同的版本号和渠道号实现的灰度系统。灰度系统的的结构如图1所示，客户端在请求接口的时候，会把自己的版本号，渠道号，VIP信息，城市信息等内容作为参数传递给服务端。服务端根据这些信息使用具体的灰度策略，来生成对应的配置文件。例如：要求版本号大于2.0，城市是北京的用户进行灰度，这样服务端只把对应客户端的配置文件改成对应的配置，引导这部分用户下载灰度包来实现灰度得到配置文件，然后进行打包得到JS补丁包进行下发。

由于本方案下发的是JavaScaript补丁包，并非java的类补丁包。由于js本身就是脚本语言，这样加载就比较容易。不需要像动态加载类那样复杂的流程。另外打包js补丁包的时候不需要的编译，这样补丁包的生成也比较容易，整个的发布都比较容易进行。

图4为本发明实施例提供的客户端加载的流程示意图，如图4所示，该在补丁包的加载上，客户端采用异步方式，思路如下：客户端第一次进入，会通过校验版本信息的方式来判断是否需要从Asset获得对应的资源包，因为JS补丁包网络下发是异步的，所以这里必须在Asset中内置一份，使得第一次打开或者清理过数据的用户能有使用的资源包。然后需要校验下载的资源包的目录下是否有新的补丁包，如果有，校验JS补丁包的版本与本地使用中最新的JavaScaript版本是否不同，不同就应用新的资源包，相同就放弃并删除。最后正式加载JavaScaript文件，并同时异步请求新的资源包数据。

图4中的补丁包指的是JS补丁包，虚线框中的上班部分是JS补丁包的加载过程，均是在本地进行执行的，与服务器侧没有交互，虚线框的下半部分为JS补丁包的异步下载过程，可以在任何时候进行下载，检测该应用程序的资源包的目录下是否存在新版本的JS补丁包；若存在，则将JS补丁包解压至应用程序的运行目录下；否则，从服务器下载应用程序的JS补丁包。

本方案不需要重新发布新版本再进行重新安装，可以动态下发，对于频繁更新也能够完美兼容，并且可以在短时间内覆盖大部分版本，更新比较及时。依靠本方案实现的灰度系统能快速的实现版本灰度。本方案比较灵活轻便，方便集成，并且受Android系统限制较小。同时，异步加载方案相比同步的好处是让用户无感知，运行时在异步线程中处理，不占用用户的时间。

图5为本发明实施例提供的应用程序的动态更新装置实施例的结构示意图，如图5所示所示，本实施例提供的应用程序的动态更新装置10包括：

处理模块11，用于根据应用程序的客户端发送的接口请求，使用预先配置的灰度策略，生成与所述接口请求对应的配置文件；

所述处理模块11还用于根据所述配置文件获取JS补丁包，所述JS补丁包包括更新的所述应用程序的脚本文件；

发送模块12，用于将所述JS补丁包发送给所述客户端。

可选的，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本实施例提供的应用程序的动态更新装置，用于实现前述任一实施例提供的应用程序的动态更新方法的服务器侧的技术方案，其实现原理和技术效果类似，在此不再赘述。

图6为本发明实施例提供的应用程序的动态更新装置实施例的结构示意图。如图6所示，该应用程序的动态更新装置20包括：

获取模块21，用于应用程序启动后，获取所述应用程序的资源包；

校验模块22，用于校验所述资源包的目录下是否存在新的JS补丁包；

处理模块23，用于若存在，则确定所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本是否相同；

所述处理模块23还用于若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本不同，则加载所述JS补丁包中的脚本文件，运行所述应用程序。

本实施例提供的应用程序的动态更新装置，用于实现前述任一实施例提供的应用程序的动态更新方法客户端侧的技术方案，其实现原理和技术效果类似，在此不再赘述。

可选的，所述处理模块23还用于：

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本相同，则加载所述本地使用的脚本文件，运行所述应用程序。

可选的，所述处理模块23还用于：

删除所述补丁包。

可选的，所述获取模块21具体用于：

所述应用程序启动后，校验所述应用程序的运行目录中的版本信息；

若所述运行目录中版本信息为空，则从资源文件夹获取所述应用程序的资源包；

若所述运行目录中版本信息不为空，则直接获取所述运行目录中存储的所述资源包。

可选的，所述处理模块23还用于：

检测所述资源包的目录下是否存在新版本的JS补丁包；

若存在，则将所述JS补丁包解压至所述应用程序的运行目录下；

否则，从服务器下载所述应用程序的JS补丁包。

可选的，所述装置还包括：

发送模块，用于向所述服务器发送接口请求，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

上述任一实施例提供的应用程序的动态更新装置，用于实现前述任一实施例提供的应用程序的动态更新方法客户端侧的技术方案，其实现原理和技术效果类似，在此不再赘述。

本发明实施例还提供一种服务器，包括：存储器、处理器和发送器；所述存储器用于存储计算机程序；所述处理器用于：

根据应用程序的客户端发送的接口请求，使用预先配置的灰度策略，生成与所述接口请求对应的配置文件；

根据所述配置文件获取JS补丁包，所述JS补丁包包括更新的所述应用程序的脚本文件；

所述发送器用于将所述补丁包发送给所述客户端。

可选的，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本发明实施例还提供一种终端设备，包括：存储器、处理器和接收器；所述存储器用于存储计算机程序；

所述处理器用于：

应用程序启动后，获取所述应用程序的资源包；

校验所述资源包的目录下是否存在新的JS补丁包；

若存在，则确定所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本是否相同；

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本不同，则加载所述JS补丁包中的脚本文件，运行所述应用程序。

可选的，所述处理器还用于：

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本相同，则加载所述本地使用的脚本文件，运行所述应用程序。

可选的，所述处理器还用于：

删除所述补丁包。

可选的，所述处理器具体用于：

所述应用程序启动后，校验所述应用程序的运行目录中的版本信息；

若所述运行目录中版本信息为空，则从资源文件夹获取所述应用程序的资源包；

若所述运行目录中版本信息不为空，则直接获取所述运行目录中存储的所述资源包。

可选的，所述处理器还用于：

检测所述资源包的目录下是否存在新版本的JS补丁包；

若存在，则将所述JS补丁包解压至所述应用程序的运行目录下；

否则，从服务器下载所述应用程序的JS补丁包。

可选的，所述终端设备还包括：发送器，用于向所述服务器发送接口请求，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

本发明实施例还提供一种存储介质，包括：可读存储介质和计算机程序，所述计算机程序存储在所述可读存储介质中，所述计算机程序用于实现上述服务器侧的应用程序的动态更新方法。

本发明实施例还提供一种存储介质，包括：可读存储介质和计算机程序，所述计算机程序存储在所述可读存储介质中，所述计算机程序用于实现上述终端设备，即客户端侧应用程序的动态更新方法。

终端设备与服务器通过通信接口进行数据交互，来执行上述各方面的各种实施方式提供的应用程序的动态更新方法，可选的，存储器还可以集成在处理器内部。

在上述终端设备或者服务器的具体实现中，应理解，处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：ApplicationSpecific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：只读存储器(英文：read-only memory，缩写：ROM)、RAM、快闪存储器、硬盘、固态硬盘、磁带(英文：magnetictape)、软盘(英文：floppy disk)、光盘(英文：optical disc)及其任意组合。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (14)

1.一种应用程序的动态更新方法，其特征在于，包括：

根据应用程序的客户端发送的接口请求，使用预先配置的灰度策略，生成与所述接口请求对应的配置文件；

根据所述配置文件获取JS补丁包，所述JS补丁包包括更新的所述应用程序的脚本文件；

将所述JS补丁包发送给所述客户端。

2.根据权利要求1所述的方法，其特征在于，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

3.一种应用程序的动态更新方法，其特征在于，包括：

应用程序启动后，获取所述应用程序的资源包；

校验所述资源包的目录下是否存在新的JS补丁包；

若存在，则确定所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本是否相同；

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本不同，则加载所述JS补丁包中的脚本文件，运行所述应用程序。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本相同，则加载所述本地使用的脚本文件，运行所述应用程序。

5.根据权利要求3所述的方法，其特征在于，所述应用程序启动后，获取所述应用程序的资源包，包括：

所述应用程序启动后，校验所述应用程序的运行目录中的版本信息；

若所述运行目录中版本信息为空，则从资源文件夹获取所述应用程序的资源包；

若所述运行目录中版本信息不为空，则直接获取所述运行目录中存储的所述资源包。

6.根据权利要求3至5任一项所述的方法，其特征在于，所述方法还包括：

检测所述资源包的目录下是否存在新版本的JS补丁包；

若存在，则将所述JS补丁包解压至所述应用程序的运行目录下；

否则，从服务器下载所述应用程序的JS补丁包。

7.根据权利要求6所述的方法，其特征在于，所述从服务器下载所述应用程序的JS补丁包之前，所述方法还包括：

向所述服务器发送接口请求，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

8.一种应用程序的动态更新装置，其特征在于，包括：

处理模块，用于根据应用程序的客户端发送的接口请求，使用预先配置的灰度策略，生成与所述接口请求对应的配置文件；

所述处理模块还用于根据所述配置文件获取JS补丁包，所述JS补丁包包括更新的所述应用程序的脚本文件；

发送模块，用于将所述JS补丁包发送给所述客户端。

9.根据权利要求8所述的装置，其特征在于，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。

10.一种应用程序的动态更新装置，其特征在于，包括：

获取模块，用于应用程序启动后，获取所述应用程序的资源包；

校验模块，用于校验所述资源包的目录下是否存在新的JS补丁包；

处理模块，用于若存在，则确定所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本是否相同；

所述处理模块还用于若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本不同，则加载所述JS补丁包中的脚本文件，运行所述应用程序。

11.根据权利要求10所述的装置，其特征在于，所述处理模块还用于：

若所述JS补丁包中的脚本文件版本与所述应用程序正在使用的脚本文件版本相同，则加载所述本地使用的脚本文件，运行所述应用程序。

12.根据权利要求10所述的装置，其特征在于，所述获取模块具体用于：

所述应用程序启动后，校验所述应用程序的运行目录中的版本信息；

若所述运行目录中版本信息为空，则从资源文件夹获取所述应用程序的资源包；

若所述运行目录中版本信息不为空，则直接获取所述运行目录中存储的所述资源包。

13.根据权利要求10至12任一项所述的装置，其特征在于，所述处理模块还用于：

检测所述资源包的目录下是否存在新版本的JS补丁包；

若存在，则将所述JS补丁包解压至所述应用程序的运行目录下；

否则，从服务器下载所述应用程序的JS补丁包。

14.根据权利要求13所述的装置，其特征在于，所述装置还包括：

发送模块，用于向所述服务器发送接口请求，所述接口请求至少包括所述应用程序的版本号、渠道号，用户的会员信息、城市信息中的至少一项。