本发明涉及应用程序开发领域，尤其涉及一种电子装置、配置文件推送方法及存储介质。
背景技术：
web应用在安装或者版本升级过程中，通常需要将对应的配置文件推送至预先确定的各个客户端，而配置文件推送的效率与当前web容器可同时处理的请求数，以及响应各个请求的时间相关。对web容器来说，每一个进来的请求(request)通常都需要一个对应的线程进行处理，直到该请求结束。如果同时进来的请求多于当前可用的线程数，额外的线程如果仍旧同时接收到更多请求，这些来不及处理的请求就会被堆积起来，直到达到最大的配置值之后，任何再来的请求将会收到错误提示信息。因此在请求数量达到一定值后，web线程池的运行效率很低，导致配置文件推送的效率也很低，甚至会影响整个电子装置的性能。
技术实现要素：
有鉴于此，本发明提出一种电子装置、配置文件推送方法及存储介质，能够有效提高web线程池的运行效率，以及提高配置文件推送的效率。首先，为实现上述目的，本发明提出一种配置文件推送方法，所述方法包括如下步骤：
s1、接收到客户端发送的获取应用程序的配置文件的请求后，将所接收的请求分配给第一类型的线程处理；
s2、当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理超过所述预设数量阈值的请求；
s3、响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给该客户端。
进一步地，在所述步骤s1中，所述第一类型的线程为线程池中的工作线程，所述将所接收的请求分配给第一类型的线程处理包括：每隔第一预设时间段将所接收的请求分配给所述线程池中的工作线程进行处理。
进一步地，在所述步骤s1中，所述将所接收的请求分配给第一类型的线程处理还包括：若在第二预设时间段内接收到的所述请求数量小于所述预设数量阈值，则将所接收的请求分配给所述线程池中的工作线程进行处理。
进一步地，在所述步骤s2中，所述第二类型的线程为jvm线程，所述根据预先确定的调用规则调用第二类型的线程包括：计算所述线程池的初始最大并发线程数与线程池当前最大并发线程数之和；根据所述计算结果确定调用所述第二类型的线程的数量，调用该数量的所述第二类型的线程。
进一步地，根据第三预设时间段内接收到的请求数量，作为调用第二类型的线程的数量，所述第三预设时间段为单个请求的平均处理时间。
此外，为实现上述目的，本发明还提供一种电子装置，所述电子装置包括存储器、及处理器，所述存储器上存储有配置文件推送程序，所述处理器执行所述存储器上存储的所述配置文件推送程序时实现如下步骤：
a1、接收到客户端发送的获取应用程序的配置文件的请求后，将所接收的请求分配给第一类型的线程处理；
a2、当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理超过所述预设数量阈值的请求；
a3、响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给该客户端。
进一步地，在所述步骤a1中，所述将所接收的请求分配给第一类型的线程处理还包括：若在第二预设时间段内接收到的所述请求数量小于预设数量阈值，则将所接收的请求分配给所述线程池中的工作线程进行处理。
进一步地，在所述步骤a1中，所述将所接收的请求分配给第一类型的线程处理还包括：若在第二预设时间段内接收到的所述请求数量小于所述预设数量阈值，则将所接收的请求分配给所述线程池中的工作线程进行处理。
进一步地，在所述步骤a2中，所述根据预先确定的调用规则调用第二类型的线程包括：计算所述线程池的初始最大并发线程数与线程池当前最大并发线程数之和；根据所述计算结果确定调用所述第二类型的线程的数量，调用该数量的所述第二类型的线程。
此外，本发明还提出一种计算机可读存储介质，所述计算机可读存储介质存储有配置文件推送程序，所述配置文件推送程序可被至少一个处理器执行，以使所述至少一个处理器执行如上所述的配置文件推送方法的步骤。
相较于现有技术，本发明所提出的配置文件推送方法、电子装置及计算机可读存储介质，通过接收客户端发送的获取应用程序的配置文件的请求，将所接收的请求分配给第一类型的线程进行处理；当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理客户端的请求；响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给客户端。有效提高web线程池的运行效率，以及电子装置的性能。
附图说明
图1是本发明电子装置一可选的硬件架构的示意图；
图2是本发明电子装置较佳实施例中配置文件推送程序的程序模块示意图；
图3是本发明配置文件推送方法较佳实施例的实施流程示意图。
本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本发明，并不用于限定本发明。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
需要说明的是，在本发明中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。
参阅图1所示，是本发明电子装置1一可选的硬件架构的示意图。本实施例中，电子装置1可包括，但不仅限于，可通过系统总线14相互通信连接的存储器11、处理器12、及网络接口13。需要指出的是，图2仅示出了具有组件11-14的电子装置1，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。
其中，存储器11至少包括一种类型的可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器11可以是电子装置1的内部存储单元，例如电子装置1的硬盘或内存。在另一些实施例中，存储器11也可以是电子装置1的外部存储设备，例如电子装置1上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。当然，存储器11还可以既包括电子装置1的内部存储单元也包括其外部存储设备。本实施例中，存储器11通常用于存储安装于电子装置1的操作系统和各类应用软件，例如配置文件推送程序等。此外，存储器11还可以用于暂时地存储已经输出或者将要输出的各类数据。
处理器12在一些实施例中可以是中央处理器(centralprocessingunit，cpu)、控制器、微控制器、微处理器、或其他数据处理芯片。处理器12通常用于控制电子装置1的总体操作。本实施例中，处理器12用于运行存储器11中存储的程序代码或者处理数据，例如运行存储在存储器11中的配置文件推送程序等。
网络接口13可包括无线网络接口或有线网络接口，网络接口13通常用于在电子装置1与其他电子设备之间建立通信连接。
系统总线14用于实现这些组件之间的通信连接。
图1仅示出了具有组件11-14以及配置文件推送程序的电子装置1，但是应理解的是，并不要求实施所有示出的组件，可以替代的实施更多或者更少的组件。
可选地，电子装置1还可以包括用户接口，用户接口可以包括显示器(display)、输入单元比如键盘(keyboard)，可选的用户接口还可以包括标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是led显示器、液晶显示器、触控式液晶显示器以及oled(organiclight-emittingdiode，有机发光二极管)触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在基于社交网络的用户关键词提取装置中处理的信息以及用于显示可视化的用户界面。
进一步地，在图1所示的电子装置1的一实施例中，存储器11中存储的配置文件推送程序被处理器12执行时实现如下步骤：
a、接收到客户端发送的获取应用程序的配置文件的请求后，将所接收的请求分配给第一类型的线程进行处理；
在本实施例中，第一类型的线程为线程池中的工作线程，例如tomcat工作线程，tomcat工作线程包括以下几个参数：maxthreads、minsparethreads、maxsparethreads、acceptcount。
maxthreads表示tomcat线程池最多能起的线程数，maxconnections表示tomcat最多能并发处理的请求(连接)数量，例如maxthreads＝150、maxconnections＝100，表示某一瞬时的并发数150，tomcat调用100个线程同时处理其中的100个请求，其余50个请求进入排队。
minsparethreads表示即使没有客户端请求连接也开启等待连接的空线程数量，例如minsparethreads＝"25"表示即使没有人使用也开这么多空线程等待。
maxsparethreads表示最多可以开启的空线程数量，例如maxsparethreads＝"75"表示最多可以空75个线程，例如某时刻有80条连接请求，之后没有连接请求了，则tomcat关闭5个空线程、只保留75个空线程。
acceptcount表示当同时请求连接的数量达到maxthreads时，还可以接收排队的连接，超过这个连接的则直接返回拒绝连接，例如maxthreads＝150，acceptcount＝"100"，当同时请求的连接数量达到150时，还可以接收100个连接排队，超过100的其它连接直接返回拒绝连接tomcat的线程参数设置和tomcat的运行环境，例如硬件、内存有关。
在线程池中，待处理的请求会被抽象封装成任务(task)，新生成的任务会被分发到任务队列，而后由任务队列交给工作线程进行处理。线程池根据情况，最多创建最大并发数个子线程去处理这些待处理任务。如果任务队列中的待处理任务的数量大于线程最大并发数，那么队列中一部分待处理任务就会长时间处于等待状态。当有任务被处理完成时，等待状态的待处理任务才会交由线程池中的工作线程执行。此外，任务队列中待处理任务可以关联有优先级信息，可以根据优先级信息，优先执行高优先级的待处理任务。
在本实施例的一些可选实现方式中，接收客户端获取应用程序的配置文件的请求，将所接收的请求分配给第一类型的线程处理，包括：每隔第一预设时间段将所接收的请求分配给线程池中的工作线程处理。
在本实现方式中，第一预设时间段可以根据实际需要设置，例如，对于接收到的获取应用程序的配置文件的请求的数量较为稳定的电子装置，第一预设时间段可以较长，对于接收到的获取应用程序的配置文件的请求的数量波动较大的电子装置，第一预设时间段可以较短。对于不同时间段也可以设置不同的第一预设时间段，例如，针对客户端，当有多个用户同时开启应用程序，则在用于程序开启后的一段时间内，发送获取应用程序的配置文件的请求的数量会增加的较快，此时第一预设时间段可以较短，等应用平稳运行后，第一预设时间段可以较长。每隔第一预设时间段将所接收到的请求分配给线程池的工作线程处理，可以根据实时分配给线程池的待处理请求的数量控制线程池中线程的数量，进一步提高了线程池的运行效率。
在本实施例的一些可选实现方式中，接收客户端获取应用程序的配置文件的请求，并将所接收的请求分配给第一类型的线程处理，包括：若在第二预设时间段内接收到的获取应用程序的配置文件的请求的数量小于预设数量阈值，则将所接收的请求分配给线程池中的工作线程。
在本实现方式中，可以监控接收到的请求的数量情况，以此仅在接收到的请求的数量小于预设数量阈值的情况下，将所接收到的请求分配给线程池中的工作线程，避免了不必要的操作，进一步提高了线程池的运行效率。
b、当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理超过所述预设数量阈值的请求；
在本实施例中，预设数量阈值可以是一个固定的数值，也可以根据当前线程池的最大并发数确定，例如，可以是预设倍数的当前最大并发线程数。预设倍数可以是一个固定的数值，也可以根据线程池创建时设置的初始的最大并发线程数确定。作为示例，预设数量阈值可以是3倍的初始的最大并发线程数与当前的最大并发数之积。
通常情况下，如果接收到的请求数量过多，大量的请求就会处于等待状态。影响了线程池的运行效率，所以需要增大线程池的最大并发线程数。但是，考虑到当前系统的cpu占用情况，所以不能无限制地增大最大并发线程数。在本实施例中，当接收到客户端发送的请求数量超过预设数量阈值后，调用第二类型的线程异步处理客户端的请求。
其中，所述第二类型的线程为jvm线程，所述jvm线程的数量取决于主机的cpu，操作系统及java版本，一台拥有现代cpu(amd或者是intel最近的几代)和1-2g内存(取决于操作系统)的集群很容易就可以支持有上千个线程的java虚拟机。绝对理论上的最大线程数是进程的用户地址空间除以线程栈的大小(现实中，如果内存全部给线程栈使用，就不会有能运行的程序了)。因此，以32位windows系统为例，每一个进程的用户地址空间是2g，假如每个线程栈的大小时128k，最多会有16384(＝2*1024*1024/128)个线程。
在本实施例的一些可选实现方式中，根据预先确定调用规则调用第二类型的线程，包括：计算线程池的初始最大并发线程数与线程池当前最大并发线程数之和；根据计算结果确定调用第二类型的线程的数量，调用该数量的第二类型的线程。在本实现方式中，计算得到的和可以是调用线程池的初始最大并发线程数的n倍，需要说明的是，线程池当前最大并发线程数通常可以是初始最大并发线程数的倍数，例如，线程池当前最大并发线程数是初始最大并发线程数的2倍，那么计算得到的和为线程池的初始最大并发线程数的3倍。由于初始最大并发线程数是根据系统任务量的情况设置的，所以依据初始最大并发线程数调用第二类型的线程数的方法提高了线程池的运行效率。
在本实施例的一些可选实现方式中，调用预设数量的第二类型的线程，包括：根据第三预设时间段内接收到的请求数量，确定调用第二类型的线程的数量。在本实现方式中，第三预设时间段可以根据实际情况设置，例如可以是单个请求的平均处理时间，也可以根据机器学习方法确定出第三预设时间段内接受到的请求数量与调用第二类型的线程的数量之间最优的比例关系，例如确定出的调用第二类型的线程的数量为第三预设时间段内接收请求数量的0.5～1倍。这种根据第三预设时间段内接收请求数量确定出的调用第二类型的线程的数的方法提高了线程池的运行效率。
进一步地，在本实施例中第二类型的线程为jvm。
c、响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给该客户端。
在本实施例中，响应所述第二类型的线程对客户端请求的处理结果，根据所述处理结果将相应的配置文件反馈给客户端，包括：可以控制第二类型的线程直接将相应的配置文件反馈给客户端，也可以将第二类型的线程对客户端请求的处理结果发送给第一类型的线程，由第一类型的线程根据处理结果将相应的配置文件反馈给该客户端。
上述实施例，通过接收客户端发送的获取应用程序的配置文件的请求，将所接收的请求分配给第一类型的线程进行处理；当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理客户端的请求；响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给客户端。有效提高web线程池的运行效率，以及电子装置的性能。
此外，电子装置1中的配置文件推送程序依据其各部分所实现的功能不同，可用具有相同功能的虚拟程序模块进行描述。
如图2所示，是本发明电子装置较佳实施例中配置文件推送程序的程序模块示意图。本实施例中，依据配置文件推送程序各部分所实现的功能，将配置文件推送程序划分为分配模块201、调用模块202、以及响应模块203。其中，程序模块201-203所实现的功能或操作步骤均与上文类似，在此不再详述，示例性地，例如其中：
分配模块201用于接收到客户端发送的获取应用程序的配置文件的请求后，将所接收的请求分配给第一类型的线程处理；
调用模块202用于当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理超过所述预设数量阈值的请求；
响应模块203用于响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给该客户端。
此外，本发明还提出一种配置文件推送方法，如图3所示，是本发明配置文件推送方法较佳实施例的实施流程示意图。由图3可知，在本实施例中，配置文件推送方法包括步骤s301-s303。
s301、接收到客户端发送的获取应用程序的配置文件的请求后，将所接收的请求分配给第一类型的线程进行处理；
在本实施例中，第一类型的线程为线程池中的工作线程，例如tomcat工作线程，tomcat工作线程包括以下几个参数：maxthreads、minsparethreads、maxsparethreads、acceptcount。
maxthreads表示tomcat线程池最多能起的线程数，maxconnections表示tomcat最多能并发处理的请求(连接)数量，例如maxthreads＝150、maxconnections＝100，表示某一瞬时的并发数150，tomcat调用100个线程同时处理其中的100个请求，其余50个请求进入排队。
minsparethreads表示即使没有客户端请求连接也开启等待连接的空线程数量，例如minsparethreads＝"25"表示即使没有人使用也开这么多空线程等待。
maxsparethreads表示最多可以开启的空线程数量，例如maxsparethreads＝"75"表示最多可以空75个线程，例如某时刻有80条连接请求，之后没有连接请求了，则tomcat关闭5个空线程、只保留75个空线程。
acceptcount表示当同时请求连接的数量达到maxthreads时，还可以接收排队的连接，超过这个连接的则直接返回拒绝连接，例如maxthreads＝150，acceptcount＝"100"，当同时请求的连接数量达到150时，还可以接收100个连接排队，超过100的其它连接直接返回拒绝连接tomcat的线程参数设置和tomcat的运行环境，例如硬件、内存有关。
在线程池中，待处理的请求会被抽象封装成任务(task)，新生成的任务会被分发到任务队列，而后由任务队列交给工作线程进行处理。线程池根据情况，最多创建最大并发数个子线程去处理这些待处理任务。如果任务队列中的待处理任务的数量大于线程最大并发数，那么队列中一部分待处理任务就会长时间处于等待状态。当有任务被处理完成时，等待状态的待处理任务才会交由线程池中的工作线程执行。此外，任务队列中待处理任务可以关联有优先级信息，可以根据优先级信息，优先执行高优先级的待处理任务。
在本实施例的一些可选实现方式中，接收客户端获取应用程序的配置文件的请求，将所接收的请求分配给第一类型的线程处理，包括：每隔第一预设时间段将所接收的请求分配给线程池中的工作线程处理。
在本实现方式中，第一预设时间段可以根据实际需要设置，例如，对于接收到的获取应用程序的配置文件的请求的数量较为稳定的电子装置，第一预设时间段可以较长，对于接收到的获取应用程序的配置文件的请求的数量波动较大的电子装置，第一预设时间段可以较短。对于不同时间段也可以设置不同的第一预设时间段，例如，针对客户端，当有多个用户同时开启应用程序，则在用于程序开启后的一段时间内，发送获取应用程序的配置文件的请求的数量会增加的较快，此时第一预设时间段可以较短，等应用平稳运行后，第一预设时间段可以较长。每隔第一预设时间段将所接收到的请求分配给线程池的工作线程处理，可以根据实时分配给线程池的待处理请求的数量控制线程池中线程的数量，进一步提高了线程池的运行效率。
在本实施例的一些可选实现方式中，接收客户端获取应用程序的配置文件的请求，并将所接收的请求分配给第一类型的线程处理，包括：若在第二预设时间段内接收到的获取应用程序的配置文件的请求的数量小于预设数量阈值，则将所接收的请求分配给线程池中的工作线程。
在本实现方式中，可以监控接收到的请求的数量情况，以此仅在接收到的请求的数量小于预设数量阈值的情况下，将所接收到的请求分配给线程池中的工作线程，避免了不必要的操作，进一步提高了线程池的运行效率。
s302、当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理超过所述预设数量阈值的请求；
在本实施例中，预设数量阈值可以是一个固定的数值，也可以根据当前线程池的最大并发数确定，例如，可以是预设倍数的当前最大并发线程数。预设倍数可以是一个固定的数值，也可以根据线程池创建时设置的初始的最大并发线程数确定。作为示例，预设数量阈值可以是3倍的初始的最大并发线程数与当前的最大并发数之积。
通常情况下，如果接收到的请求数量过多，大量的请求就会处于等待状态。影响了线程池的运行效率，所以需要增大线程池的最大并发线程数。但是，考虑到当前系统的cpu占用情况，所以不能无限制地增大最大并发线程数。在本实施例中，当接收到客户端发送的请求数量超过预设数量阈值后，调用第二类型的线程异步处理客户端的请求。
其中，所述第二类型的线程为jvm线程，所述jvm线程的数量取决于主机的cpu，操作系统及java版本，一台拥有现代cpu(amd或者是intel最近的几代)和1-2g内存(取决于操作系统)的集群很容易就可以支持有上千个线程的java虚拟机。绝对理论上的最大线程数是进程的用户地址空间除以线程栈的大小(现实中，如果内存全部给线程栈使用，就不会有能运行的程序了)。因此，以32位windows系统为例，每一个进程的用户地址空间是2g，假如每个线程栈的大小时128k，最多会有16384(＝2*1024*1024/128)个线程。
在本实施例的一些可选实现方式中，根据预先确定调用规则调用第二类型的线程，包括：计算线程池的初始最大并发线程数与线程池当前最大并发线程数之和；计算得到的所述初始最大并发线程数与线程池当前最大并发线程数之和为所述第二类型的线程的数量，，调用该数量的第二类型的线程。在本实现方式中，线程池当前最大并发线程数可以是初始最大并发线程数n倍，需要说明的是，线程池当前最大并发线程数通常可以是初始最大并发线程数的倍数，例如，线程池当前最大并发线程数可以是初始最大并发线程数的2倍，那么计算得到的和为线程池的初始最大并发线程数的3倍。由于初始最大并发线程数是根据系统任务量的情况设置的，所以依据初始最大并发线程数调用第二类型的线程数的方法提高了线程池的运行效率。
在本实施例的一些可选实现方式中，调用预设数量的第二类型的线程，包括：根据第三预设时间段内接收到的请求数量，作为调用第二类型的线程的数量。在本实现方式中，第三预设时间段可以根据实际情况设置，例如可以是单个请求的平均处理时间，也可以根据机器学习方法确定出第三预设时间段内接受到的请求数量与调用第二类型的线程的数量之间最优的比例关系，例如确定出的调用第二类型的线程的数量为第三预设时间段内接收请求数量的0.5～1倍。这种根据第三预设时间段内接收请求数量确定出的调用第二类型的线程的数的方法提高了线程池的运行效率。
进一步地，在本实施例中第二类型的线程为jvm。
s303、响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给该客户端。
在本实施例中，响应所述第二类型的线程对客户端请求的处理结果，根据所述处理结果将相应的配置文件反馈给客户端，包括：可以控制第二类型的线程直接将相应的配置文件反馈给客户端，也可以将第二类型的线程对客户端请求的处理结果发送给第一类型的线程，由第一类型的线程根据处理结果将相应的配置文件反馈给该客户端。
上述实施例，通过接收客户端发送的获取应用程序的配置文件的请求，将所接收的请求分配给第一类型的线程进行处理；当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理客户端的请求；响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给客户端。有效提高web线程池的运行效率，以及电子装置的性能。
此外，本发明还提出一种计算机可读存储介质，该计算机可读存储介质存储有配置文件推送程序，所述配置文件推送程序被至少一个处理器执行，以使所述至少一个处理器执行如下步骤：
接收到客户端发送的获取应用程序的配置文件的请求后，将所接收的请求分配给第一类型的线程处理；
当接收到客户端发送的请求数量超过预设数量阈值后，根据预先确定的调用规则调用第二类型的线程异步处理超过所述预设数量阈值的请求；
响应所述第二类型的线程异步处理的结果，根据所述处理的结果将相应的配置文件反馈给该客户端。
上述各步骤的具体实施过程与上述电子装置以及配置文件推送方法的具体实施过程类似，在此不再详述。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，电子装置，空调器，或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。