一种更新数据包的推送方法及服务器与流程
本发明属于信息处理技术领域，尤其涉及一种更新数据包的推送方法及服务器。
背景技术：
更新数据包，例如补丁，作为热修复的重要手段，被广泛用于各种应用程序或系统在运行中出现的故障修复。现有的更新数据包的推送方式，采用的是全局统一推送的发布方式，即向安装了更新数据包所需修复的应用程序或系统的所有用户终端统一进行的软件更新，以修改软件中所存在的漏洞。
然而上述方式，要求同时向所有用户终端推送更新数据包，若部分用户终端并未出现故障情况，也需要下载更新数据包，则浪费了该部分用户的数据流量，造成资源浪费，还可能因为安装了更新数据包而引起新的故障情况，降低用户的使用体验以及软件的稳定性。
技术实现要素：
有鉴于此，本发明实施例提供了一种更新数据包的推送方法及服务器，以解决现有的更新数据包的推送技术，对于并未出现故障情况的用户终端，也统一进行更新数据包推送，容易造成资源浪费以及降低终端稳定性的问题。
本发明实施例的第一方面提供了一种更新数据包的推送方法，包括：
接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识；
基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录；
根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数；
若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包；
向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
本发明实施例的第二方面提供了一种服务器，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现第一方面的各个步骤。
本发明实施例的第三方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现第一方面的各个步骤。
实施本发明实施例提供的一种更新数据包的推送方法及服务器具有以下有益效果：
本发明实施例在接收到故障信息后，会根据故障信息包含的设备信息，从故障信息库中提取该设备信息对应的历史故障记录，继而根据历史故障记录以及故障信息计算该设备信息的异常系数，从而能够基于异常系数的数值大小，判定该应用程序与该设备信息对应的用户终端之间是否存在兼容问题，若该异常系数大于预设的推送阈值，则表示多个该设备信息对应的用户终端均与应用程序存在异常冲突情况，需要获取该设备信息关联的用户终端列表，并统一向该用户终端列表内的所有用户终端发送更新数据包，以修改应用程序与该类型用户终端之间的兼容问题。与现有的更新数据包的统一推送方式相比，本实施例只有在异常系数较大时，才对设备信息对应的用户终端进行更新数据包的推送操作，从而实现定向推送的目的，而并不会对未发生异常的设备型号的用户终端发送更新数据包，减少了用户数据流量的浪费，提高了用户的使用体验以及软件的稳定性。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1是本发明第一实施例提供的一种更新数据包的推送方法的实现流程图；
图2是本发明第二实施例提供的一种更新数据包的推送方法s103具体实现流程图；
图3是本发明第三实施例提供的一种更新数据包的推送方法s105具体实现流程图；
图4是本发明第四实施例提供的一种更新数据包的推送方法具体实现流程图；
图5是本发明第五实施例提供的一种更新数据包的推送方法具体实现流程图；
图6是本发明一实施例提供的一种服务器的结构框图；
图7是本发明另一实施例提供的一种服务器的示意图。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
本发明实施例在接收到故障信息后，会根据故障信息包含的设备信息，从故障信息库中提取该设备信息对应的历史故障记录，继而根据历史故障记录以及故障信息计算该设备信息的异常系数，从而能够基于异常系数的数值大小，判定该应用程序与该设备信息对应的用户终端之间是否存在兼容问题，若该异常系数大于预设的推送阈值，则表示多个该设备信息对应的用户终端均与应用程序存在异常冲突情况，需要获取该设备信息关联的用户终端列表，并统一向该用户终端列表内的所有用户终端发送更新数据包，以修改应用程序与该类型用户终端之间的兼容问题，解决了现有的更新数据包的推送技术，对于并未出现故障情况的用户终端，也统一进行更新数据包推送，容易造成资源浪费以及降低终端稳定性的问题。
在本发明实施例中，流程的执行主体为服务器。该服务器包括但不限于：服务器、计算机、智能手机以及平板电脑等具有更新数据包的推送功能的设备。特别地，该服务器可以为一应用程序发布平台对应的服务器，各个用户终端可以从该服务器下载应用程序的程序文件，以及关于该应用程序的更新数据包，同样地，当用户终端发现应用程序在运行过程中存在异常，也可以向该服务器反馈故障信息。图1示出了本发明第一实施例提供的更新数据包的推送方法的实现流程图，详述如下：
在s101中，接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识。
在本实施例中，用户终端在运行已安装的应用程序时，若出现故障情况，例如程序无响应、异常关闭或按键点击异常等情况，会生成一条故障信息，该故障信息中记录有本次应用程序的具体异常内容，并将该应用程序对应的应用标识封装于该故障信息。为了确定该应用程序发生的故障是否为与设备之间的兼容性而导致的，用户终端除了将应用表添加到故障信息外，还会获取用户终端本地相关的设备信息。
具体地，在本实施例中，该设备信息包括但不限于：设备编号、设备型号、系统版本以及应用程序的运行环境类型。其中，应用程序的运行环境类型即该用户终端的系统类型，例如是基于安卓搭建的工作环境，或是基于微软搭建的工作环境，或是基于linux搭建的工作环境等。优选地，该设备信息具体包括运行环境类型以及系统版本两类信息。为了检测应用程序与该用户终端之间的故障情况是否由于兼容性的问题导致，而上述两类信息即可唯一确定该应用程序的运行环境，便于服务器可以在本地搭建对应的运行环境，以模拟用户终端的操作，继而判断该故障信息是否因设备系统兼容性而导致。其中，若故障信息中包含设备编号或设备型号等信息，服务器可以基于上述两类信息查询对应的产品信息，并通过该产品信息获取应用程序所运行的系统环境。
可选地，在本实施例中，用户终端在发送故障信息之前，会根据应用程序的下载渠道，即该应用程序所属的发布平台，确定该故障信息的目标地址。由于不同的应用程序所属开发商存在差异，用户终端在反馈故障信息之前，可以解析该应用程序的程序文件或获取该应用程序的下载记录，确定该应用程序的下载渠道，通过该下载渠道发送一个目标地址获取指令，以便该应用程序的服务器向用户终端返回其对应的目标地址，并根据该目标地址将故障信息反馈给服务器。当然，若用户终端存储有应用程序与服务器的对应关系表，则可以通过查询该对应关系表确定故障信息的目标地址，并通过该目标地址向服务器发送故障信息。
在s102中，基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录。
在本实施例中，由于应用程序发生故障有可能是偶发性，例如设备内存溢出、主线程资源不足或用户终端电量不足而导致应用程序运行异常，对于上述异常情况并非处于应用程序的程序文件存在漏洞，无需维护人员对该应用程序进行修复。因此，为了判断该故障信息是否为偶发故障，服务器会根据故障信息中包含的应用标识，确定该应用程序的故障信息库，该故障信息库主要用于该应用标识对应的应用程序所有用户终端上传的故障信息，以便维护人员在故障修复时能够通过故障信息库定位故障原因，并生成对应的更新数据包。需要说明的是，该故障信息库可以存储于服务器内，在该情况下，一个服务器可以用于发布一个或多个应用程序的更新数据包，并存储应用程序的故障信息库。当然，该故障信息库可以存储于一独立的数据库服务器，即各个用户终端会将故障信息上传至该数据库服务器，继而数据库服务器根据故障信息中包含的应用标识，将该故障信息存储于对应的故障信息库内，本实施例提供的服务器可以从该数据库内获取对应的历史故障记录。
在本实施例中，服务器在确定了应用程序的故障信息库后，会根据该故障信息的设备信息，从故障信息库内提取所有关于该设备信息的历史故障记录。由于各个故障信息库中的各个历史故障记录均为有安装有该应用程序的用户终端上传的故障信息，因此各个历史故障记录中也会记载有上传该故障信息的用户终端对应的设备信息。服务器可以通过各个历史故障记录中包含的设备信息，与本次上传的故障信息进行匹配，并选取匹配成功的历史故障记录作为该故障信息关联的历史故障记录，并执行s103的相关操作。其中，匹配的方式可以为：服务器将故障信息内的故障信息导入到预设的哈希函数内，确定该设备信息对应的哈希值，例如服务器可以基于各个产品以及该产品的设备环境的对应关系，创建一个哈希函数，从而服务器可以通过输入设备信息，得到与之对应的设备环境。对于故障信息以及历史故障记录均执行上述操作，并将输出的哈希值与故障信息的哈希值一致的历史故障信息，识别为故障信息关联的历史哈希记录。
在s103中，根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数。
在本实施例中，服务器在确定了该设备信息的历史故障记录以及本次上传的故障信息后，可以基于上述两类信息确定该设备信息的异常系数，该异常系数越大，则表示该设备信息所存在的故障情况越多，从而该故障为偶发性故障的概率较小，因此需要对该应用程序进行故障修复，并向用户终端发布用于修复该故障信息的更新数据包；反之，若该异常系数越小，则表示该设备信息所出现的故障情况较少，因此在一定范围内，可以判定该异常情况为偶发性异常，并不属于普遍存在的异常情况，对于该类情况，由于是个体设备的原因导致的异常，因此服务器无需为其配置对应的更新数据包来修复异常情况。基于此，服务器可以通过计算该设备信息的异常系数，从而能够确定是否需要向该设备渠道的应用程序下发更新数据包，来修复故障情况。
可选地，在本实施例中，计算异常系数的方式可以为：服务器可以将该设备信息包含的历史故障记录以及故障信息的总个数，作为该设备信息的异常系数，即上述两类信息的数量越大，则该设备信息的异常系数越大；服务器还可以根据各个历史故障记录的创建时间，确定各个历史故障记录的权重值，并根据各个历史故障记录的权重值进行加权运行，确定该设备信息的异常系数。
优选地，在本实施例中，计算异常系数的方式可以为：服务器提取各个历史故障记录中包含的故障模块，并统计各个故障模块出现故障的次数，基于该次数确定各个故障模块的故障权重，从而计算该设备信息的异常系数。例如，对于某一应用程序包含5个功能模块，分别为功能模块a至e，而某一设备信息的3个历史故障记录中记载了功能模块a出现故障，4个历史故障记录中记载了功能模块b出现故障，而本次获取的故障信息中也记录了功能模块a和功能模块b出现故障，即功能模块a的故障次数为4，功能模块b的故障次数为5，即根据该故障次数确定对应的故障权重，例如故障次数为4时对应的故障权重为α，而故障次数为5时对应的故障权重为β，则该设备信息的故障系数则为：4α+5β。
在s104中，若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包。
在本实施例中，服务器存储有一推送阈值，当异常系数大于该推送阈值时，则表示该设备信息与应用程序之间存在兼容性的问题，因此需要为该应用程序生成一个用于修复上述两者兼容性的更新数据包，从而能够用户终端上关于故障信息的故障问题。需要说明的是，该推送阈值可以由管理员进行设备，也可以基于该应用程序的下载量的变化进行对应的变化，从而使得该推送阈值能够动态调整，与当前的下载量相匹配，提高了更新数据包推送时机的准确性。
在本实施例中，服务器可以基于故障信息内包含的故障模块，获取各个故障模块对应的源码数据，并对该源码数据进行语法校验以及语义校验，若上述两项检测均通过，则获取该故障模块的接口信息以及线程信息，并与该设备信息中包含的接口标识以及线程标识进行匹配，是否存在接口冲突或线程冲突的情况，并基于冲突情况调整故障模块的接口信息以及线程信息，并根据修复后的源码数据生成更新数据包。
可选地，服务器可以将故障信息转发给开发人员的终端，以通知开发人员生成该故障信息的更新数据包，并将生成后的更新数据包返回给服务器，以便服务器进行更新数据包的推送操作。
可选地，在本实施例中，服务器在生成了一个故障信息或历史故障记录的更新数据包后，会将该故障信息以及该历史故障记录从故障信息库中删除，从而避免重复对该故障信息以及历史故障记录进行重复修复。
在s105中，向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
在本实施例中，服务器会为每个设备信息管理一个用户终端列表，该用户终端列表内所有用户终端的设备信息相同，例如若该设备信息为设备型号，则该用户终端列表内的所有用户终端的设备型号均一致。该用户终端列表可以通过应用程序的下载记录统计得到，用户终端在下载一个应用程序时，会发送一个下载请求，该下载请求包括有设备信息，服务器会基于该下载请求向用户终端返回该设备信息匹配的应用程序的程序文件，并生成一条下载记录，因而下载记录中记载有下载应用程序的用户终端的设备信息，从而能够统计得到该用户终端列表。当然，该设备信息还可以为应用程序的下载渠道，例如某一应用商城，终端设备则可以获取安装有该应用商城客户端的所有用户终端，生成该用户终端列表，并将生成的更新数据包向该用户终端列表内的所有用户终端进行推送，从而修复了该设备信息的所有用户终端的故障情况。
以上可以看出，本发明实施例提供的一种更新数据包的推送方法在接收到故障信息后，会根据故障信息包含的设备信息，从故障信息库中提取该设备信息对应的历史故障记录，继而根据历史故障记录以及故障信息计算该设备信息的异常系数，从而能够基于异常系数的数值大小，判定该应用程序与该设备信息对应的用户终端之间是否存在兼容问题，若该异常系数大于预设的推送阈值，则表示多个该设备信息对应的用户终端均与应用程序存在异常冲突情况，需要获取该设备信息关联的用户终端列表，并统一向该用户终端列表内的所有用户终端发送更新数据包，以修改应用程序与该类型用户终端之间的兼容问题。与现有的更新数据包的统一推送方式相比，本实施例只有在异常系数较大时，才对设备信息对应的用户终端进行更新数据包的推送操作，从而实现定向推送的目的，而并不会对未发生异常的设备型号的用户终端发送更新数据包，减少了用户数据流量的浪费，提高了用户的使用体验以及软件的稳定性。
图2示出了本发明第二实施例提供的一种更新数据包的推送方法的s103具体实现流程图。参见图2，相对于图1述实施例，本实施例提供的一种更新数据包的推送方法中s103包括：s1031～s1032，具体详述如下：
在s1031中，获取各个历史故障记录以及故障信息中各自包含的故障模块，并确定各个所述故障模块的故障权重值。
在本实施例中，应用程序中根据不同功能模块的重要程度，当该功能模块发生故障时，其对应的故障权重值也会不同。例如，若某一应用程序的主功能模块，例如实现应用程序启动以及关闭的功能模块，由于应用程序每次打开以及关闭均需要调用，若该功能模块出现异常，则无论应用程序内的其他模块是否异常，该应用程序也无法被用户正常使用，因此其对应的故障权重值较高，以便在该类型的功能模块出现故障时，能够尽快发布更新数据包，以修复该故障情况。因此，服务器可以根据应用程序内各个功能模块的优先级次序，确定各个功能模块的故障权重值，当该功能模块发生故障时，服务器则获取该功能模块的优先级信息，并查询该优先级信息对应的故障权重值，从而能够得到故障模块的故障权重值。
在本实施例中，该故障权重值可以由开发人员进行配置，则开发人员为每个功能模块配置对应的故障权重值，也可以如上述所，用户设置有一优先级转换函数，服务器基于各个功能模块的使用次数，确定各个功能模块的优先级，并将优先级导入该优先级转换函数内，计算各个功能模块对应的故障权重值，特别地，该优先级转换函数可以为一哈希函数。
在本实施例中，各个历史故障记录以及本次上传的故障信息均记录有应用程序中发生故障的故障模块，因此服务器可以根据各个故障模块的模块标识，确定与之对应的故障权重值。
在s1032中，将所述故障权重值、所述历史故障记录以及所述故障信息导入到异常系数转换模型，计算所述设备信息的异常系数；所述异常系数转换模型具体为：
其中，updatelv为所述设备信息的异常系数；errornum为所述历史故障信息的个数；currenttime为当前时刻的时间；errortimei为第i个历史故障信息的创建时间；partnumi为第i个历史故障信息包含的故障模块个数；errorpartij为第i个历史故障信息中第j个故障模块的所述故障权重值；errortime0为故障信息的发送时间；errorpart0j为故障信息中第j个故障模块的所述故障权重值；parameter0以及parameteri为预设系数。
在本实施例中，终端设备会将各个历史故障记录、本次获取得到故障信息以及上述确定的故障权重值导入到异常系数转换模型内，计算该设备信息的异常系数，其中，各个历史故障记录除了记录有故障模块外，还会记录有该历史故障记录的创建时间，由于该创建时间与当前时间的差值越大，则该历史故障记录已被修复的概率越大，从而该历史故障信息对于异常系数的贡献则越小，因此通过设置
在本发明实施例中，通过确定历史故障记录以及故障信息中各个故障模块的故障权重值，并将上述三类信息导入到异常系数转换模型内，计算设备信息的异常系数，从而能够提高异常系数的准确性。
图3示出了本发明第二实施例提供的一种更新数据包的推送方法s105的具体实现流程图。参见图3，相对于图1述实施例，本实施例提供的一种更新数据包的推送方法s105包括：s1051～s1053，具体详述如下：
在s1051中，获取所述更新数据包的数据量。
在本实施例中，服务器在发送更新数据包前，会先确定该更新数据包的数据量，并把该数据量与预设的数据量阈值进行比对，该更新数据包的数据量小于预设的数据量阈值，则执行s1052的操作；反之，若数据量大于或等于预设的数据量阈值，则执行s1053的操作。
可选地，本实施例的数据量阈值可以由管理员进行手动设置，也可以服务器根据所处网络的带宽资源自动进行调整。例如，服务器设定了发送一个更新数据包的预计时长为4秒，且占用的带宽资源不能超过50％，当前的带宽资源为100m/s，由此可见，该数据量阈值则可以为：vmax＝100m/s*50％*4＝200m。
在s1052中，若所述更新数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述用户终端列表内的所有用户终端发送所述更新数据包。
在本实施例中，若服务器确定了该更新数据包的数据量小于预设的数据量阈值，则表示该更新数据包的数据量较小，发送一个数据包所需的时间较短，并不会出现因发送更新数据包，而导致发送超出预设时长仍未发送完毕的情况，在此基础上，通过主线程进行更新数据包的发送效率较高。由于主线程可调用的硬件资源以及带宽资源较多，因此进行数据包发送的效率也较高，但由于服务器在检测主线程运行时，会设置一个最大响应时长，若该响应时长超过预设的响应阈值，则会识别该主线程处于响应异常状态，则会终止该主线程的操作，重新进行响应。因此，若更新数据包的数据量较大，服务器则会识别该主线程处于响应异常状态，并反复终止并重发，导致资源浪费以及故障数据包无法正常发送的情况。因此，当故障数据包的数据量较小时，服务器才通过主线程进行数据发布，从而提高发送的成功率。
在本实施例中，服务器在确定通过主线程向各个用户终端发送更新数据包时，可以根据用户终端上传故障信息的先后次序，作为该用户终端发送更新数据包的发送次序。
在s1053中，若所述更新数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述用户终端列表内的所有用户终端发送所述更新数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
在本实施例中，若服务器在确定了更新数据包大于或等于数据量阈值，则表示该更新数据包的数据量较大，通过主线程串行方式进行发送的话，容易产生上述的主线程因执行发送操作时间过程而识别线程超时的情况。因此，在该情况下，将通过子线程并行的方式向各个用户终端发送更新数据包。
在本实施例中，服务器查询该故障类型的对应关系中记录了用户终端的终端个数，并在主线程下创建与该终端个数相同的子线程的个数，并将各个子线程的运行模式设置为异步并行模式，从而控制各个子线程分别与各个用户终端进行通信连接，通过各个子线程分别向各个用户终端发送更新数据包。
可选地，若终端个数大于服务器最大子线程数，则创建与最大线程数数量相同的子线程，向部分用户终端进行更新数据包的发送操作，在发送完毕后，再对余下部分的用户终端进行发送，直到将该故障类型对应的用户终端均进行数据包发送操作。
在本发明实施例中，服务器根据更新数据包的数据量大小，选择合适的发送方式进行数据发送，从而提高了发送效率以及发送的成功率。
图4示出了本发明第三实施例提供的一种更新数据包的推送方法的具体实现流程图。参见图4，相对于图1-图3所述实施例，本实施例提供的一种更新数据包的推送方法中，在所述根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数之后，还包括：s401～s402，具体详述如下：
在s401中，若所述异常系数小于或等于所述推送阈值，则获取当前的时间信息，基于所述当前的时间信息以及所述故障信息，生成故障记录。
在本实施例中，由于异常系数是用于判断是否需要向用户终端推送更新数据包的参考值，当该异常系数大于推送阈值时，则生成故障信息的更新数据包并执行推送流程；而当异常系数小于或等于推送阈值时，则表示该设备信息的故障情况并不严重，可能属于偶发性异常，在该情况下，服务器并不会为该故障信息生成对应的更新数据包，而是将获取当前的时间信息，并基于该时间信息以及本次接收到的故障信息，生成故障记录。需要说明的是，该时间信息可以包括有当前的日期信息以及具体时刻信息。
在s402中，将所述故障记录添加到所述应用标识的故障信息库内，并向所述用户终端发送关于所述故障记录的故障待处理信息。
在本实施例中，服务器在生成了该故障信息对应的故障记录后，为了便于发开人员对于应用程序的故障信息进行管理，服务器会根据应用标识确定该应用程序的故障信息库，并将该故障记录存储于该故障信息库内。由于本次异常操作属于偶发性异常，服务器还会想用户终端反馈一个故障待处理信息。
在本发明实施例中，在异常系数较少时，根据故障信息生成故障记录并存储于故障信息库内，从而便于开发人员对应用程序的故障情况进行管理。
图5示出了本发明第四实施例提供的一种更新数据包的推送方法的具体实现流程图。参见图5，相对于图1-图3所述实施例，本实施例提供的一种更新数据包的推送方法在所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包之前，还包括：s501～s502，具体详述如下：
在s501中，获取所述用户终端的网络状态。
在本实施例中，服务器在向用户终端发送更新数据包之前，可以向用户终端发送一个网络状态获取请求，确定当前用户终端的网络状态。该网络状态即为与互联网进行通信联机的具体连接方式，是通过有线网络、无线局域网或是移动网络。用户终端基于当前与服务器通信的网络状态，生成一个网络状态结果返回给服务器。
在s502中，若所述网络状态满足预设的数据包下载状态，则执行所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
在本实施例中，服务器若确定当前用户终端的网络状态为预设的数据包下载状态，则向用户终端发送更新数据包。特别地，该数据包下载状态为：无线局域网状态或有线网络状态。
可选地，若服务器确定当前网络状态不满足预设的数据包下载状态，则设置一个重发计时器，在重发计时器的计数值大于重发计数值后，返回s501的相关操作，直到用户终端的网络状态满足预设的数据包下载状态，再执行下载操作。
可选地，用户终端在接收到网络状态获取请求后，当确定当前状态不满足预设的数据包下载状态时，可进入下载等待状态，当检测到用户终端的网络状态满足数据包下载状态时，主动向服务器发送一个数据包获取请求，以启动数据包下载操作。
在本发明实施例中，通过获取用户终端的网络状态，判定是否执行数据包发送，避免用户终端无意下载而浪费大量的数据流量。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。
图6示出了本发明一实施例提供的一种服务器的结构框图，该服务器包括的各单元用于执行图1对应的实施例中的各步骤。具体请参阅图1与图1所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。
参见图6，所述服务器包括：
故障信息接收单元61，用于接收用户终端反馈的故障信息；所述故障信息包含所述用户终端的设备信息以及存在故障的应用程序的应用标识；
历史故障记录获取单元62，用于基于所述应用标识确定所述应用程序的故障信息库，并从故障信息库中提取所述设备信息对应的历史故障记录；
异常系数计算单元63，用于根据所述历史故障记录以及所述故障信息计算所述设备信息的异常系数；
更新数据包获取单元64，用于若所述异常系数大于预设的推送阈值，则根据所述故障信息，获取用于修复所述故障信息的更新数据包；
更新数据包推送单元65，用于向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
可选地，所述异常系数计算单元63包括：
故障权重值确定单元，用于获取各个历史故障记录以及故障信息中各自包含的故障模块，并确定各个所述故障模块的故障权重值；
故障信息导入单元，用于将所述故障权重值、所述历史故障记录以及所述故障信息导入到异常系数转换模型，计算所述设备信息的异常系数；所述异常系数转换模型具体为：
其中，updatelv为所述设备信息的异常系数；errornum为所述历史故障信息的个数；currenttime为当前时刻的时间；errortimei为第i个历史故障信息的创建时间；partnumi为第i个历史故障信息包含的故障模块个数；errorpartij为第i个历史故障信息中第j个故障模块的所述故障权重值；errortime0为故障信息的发送时间；errorpart0j为故障信息中第j个故障模块的所述故障权重值；parameter0以及parameteri为预设系数。
可选地，所述更新数据包推送单元65包括：
数据量获取单元，用于获取所述更新数据包的数据量；
串行推送单元，用于若所述更新数据包的数据量小于预设的数据量阈值，则将主线程设置为串行运行模式，并通过所述主线程逐一向所述用户终端列表内的所有用户终端发送所述更新数据包；
并行推送单元，用于若所述更新数据包的数据量大于或等于所述数据量阈值，则在所述主线程内创建多个异步并行的子线程，并通过各个所述子线程分别向所述用户终端列表内的所有用户终端发送所述更新数据包；所述子线程的个数与所述故障类型包含的用户终端的个数相同。
可选地，所述服务器还包括：
故障记录生成单元，用于若所述异常系数小于或等于所述推送阈值，则获取当前的时间信息，基于所述当前的时间信息以及所述故障信息，生成故障记录；
故障记录导入单元，用于将所述故障记录添加到所述应用标识的故障信息库内，并向所述用户终端发送关于所述故障记录的故障待处理信息。
可选地，所述服务器还包括：
网络状态获取单元，用于获取所述用户终端的网络状态；
网络状态识别单元，用于若所述网络状态满足预设的数据包下载状态，则执行所述向与所述设备信息关联的用户终端列表内的所有用户终端推送所述更新数据包。
因此，本发明实施例提供的服务器同样可以在接收到故障信息后，会根据故障信息包含的设备信息，从故障信息库中提取该设备信息对应的历史故障记录，继而根据历史故障记录以及故障信息计算该设备信息的异常系数，从而能够基于异常系数的数值大小，判定该应用程序与该设备信息对应的用户终端之间是否存在兼容问题，若该异常系数大于预设的推送阈值，则表示多个该设备信息对应的用户终端均与应用程序存在异常冲突情况，需要获取该设备信息关联的用户终端列表，并统一向该用户终端列表内的所有用户终端发送更新数据包，以修改应用程序与该类型用户终端之间的兼容问题。
图7是本发明另一实施例提供的一种服务器的示意图。如图7所示，该实施例的服务器7包括：处理器70、存储器71以及存储在所述存储器71中并可在所述处理器70上运行的计算机程序72，例如更新数据包的推送程序。所述处理器70执行所述计算机程序72时实现上述各个更新数据包的推送方法实施例中的步骤，例如图1所示的s101至s105。或者，所述处理器70执行所述计算机程序72时实现上述各装置实施例中各单元的功能，例如图6所示模块61至65功能。
示例性的，所述计算机程序72可以被分割成一个或多个单元，所述一个或者多个单元被存储在所述存储器71中，并由所述处理器70执行，以完成本发明。所述一个或多个单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序72在所述服务器7中的执行过程。例如，所述计算机程序72可以被分割成故障信息接收单元、历史故障记录获取单元、异常系数计算单元、更新数据包获取单元以及更新数据包推送单元，各单元具体功能如上所述。
所述服务器7可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述服务器可包括，但不仅限于，处理器70、存储器71。本领域技术人员可以理解，图7仅仅是服务器7的示例，并不构成对服务器7的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述服务器还可以包括输入输出设备、网络接入设备、总线等。
所称处理器70可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器71可以是所述服务器7的内部存储单元，例如服务器7的硬盘或内存。所述存储器71也可以是所述服务器7的外部存储设备，例如所述服务器7上配备的插接式硬盘，智能存储卡(smartmediacard，smc)，安全数字(securedigital，sd)卡，闪存卡(flashcard)等。进一步地，所述存储器71还可以既包括所述服务器7的内部存储单元也包括外部存储设备。所述存储器71用于存储所述计算机程序以及所述服务器所需的其他程序和数据。所述存储器71还可以用于暂时地存储已经输出或者将要输出的数据。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
以上所述实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围，均应包含在本发明的保护范围之内。
- 还没有人留言评论。精彩留言会获得点赞！