[发明专利]应用程序热更新处理方法、装置及系统

说明书

本申请实施例公开了应用程序热更新处理方法、装置及系统，该系统包括：控制中心服务端，用于为应用程序创建资源空间对象，提供资源空间对象的标识以及版本信息，所述资源空间对象中包括同一更新任务对应的至少一个资源体对象，所述资源体对象对应有条件描述信息；检查更新服务端，用于获得所述资源空间对象的可用版本信息，以及相关的网络存储地址信息；检查更新客户端，用于引入到目标应用程序客户端中，在目标事件的触发下，获得可用版本资源空间对象的网络存储地址信息，并下载，利用与本地运行环境相匹配的目标条件描述信息对应的资源体对象进行更新。通过本申请实施例，能够提高定向热更新的准确度以及及时性，避免造成大量的资源浪费。

技术领域

本申请涉及应用程序热更新技术领域，特别是涉及应用程序热更新处理方法、装置及系统。

背景技术

在热更新技术出现之前，一个已经上线的移动端应用程序(app)中如果出现了bug，即使是一个非常小的bug，不及时更新的话有可能存在风险，若要及时更新就需要将app重新打包发布到应用市场后，让用户再一次下载，这样就大大降低了用户体验。当热更新出现之后，这样的问题就不再是问题了。所谓“热更新”，是指在应用中动态下发代码，它可以让开发者在不发布新版本的状态下修复技术缺陷或增添功能，在用户打开应用时会自动提醒并下载升级，下载完成后软件会自动安装。“热更新”不需要通过应用商店软件版本更新审核，因此有很多开发者选择利用此方式修改技术缺陷，实现快速迭代。

在移动端资源变更体系里，随着一个app的发展，会出现变更资源的定向发布的情况，某应用程序提供两份资源，分别为资源A和资源B，其中，资源A只给App版本为7.1的设备，而其他版本的设备使用资源B。具体的条件设置还可能包括操作系统、机型、品牌等等。

为了达到上述目的，现有技术中常用的方案大致有两种，一种是由服务端向客户端进行资源的定向推送，另一种是由客户端主动向服务端请求具体的资源数据。而对于第一种方式而言，就涉及到服务端对终端设备进行圈选的问题，也就，服务端推送是根据设备ID投放的，在投放的时候已经决定了推送给哪些设备，如果在设备收到资源之前条件发生了变化，那么这个设备会错过或误收这个资源。例如，推送资源A给所有appVersion＝7.0的设备，某个设备X在推送任务产生时版本是6.9，因此，没有被服务端纳入到圈选范围，此时，即使该设备X后续经过应用市场更新到7.0，也是收不到这个资源的。

对于第二种方式而言，由于资源的更新通常对及时性要求比较高，因此，为了能够及时获得更新，客户端需要频繁地周期性访问服务端，而服务端就需要开对应的线程来处理这种请求，在客户端的装机量非常大，一些大型促销活动等同时在线量非常大等情况下，服务端需要开启的线程数量也是非常大的，对服务端的性能要求很高，容易造成系统崩溃。另外，有些资源可能的更新频度可能并不高，但是为了保证更新的及时性，客户端又不得不以高的频率对服务端进行访问，以此造成了大量的资源浪费。

因此，如何提高定向热更新的准确度以及及时性，避免造成大量的资源浪费，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了应用程序热更新处理方法、装置及系统，能够提高定向热更新的准确度以及及时性，避免造成大量的资源浪费。

本申请提供了如下方案：

一种应用程序热更新处理系统，包括：

控制中心服务端，用于为应用程序创建资源空间对象，提供资源空间对象的标识以及版本信息，所述资源空间对象中包括同一更新任务对应的至少一个资源体对象，所述资源体对象对应有条件描述信息；

检查更新服务端，用于获得所述资源空间对象的可用版本信息，以及相关的网络存储地址信息；