CN106648725B - 终端、服务器及配置文件升级方法 - Google Patents

Abstract

本发明公开了一种终端，所述终端包括：提取模块，用于从服务器中获取到配置文件升级包时，对所述配置文件升级包进行解析以提取出下载地址；下载模块，用于根据提取的所述下载地址下载配置文件；确定模块，用于确定下载的所述配置文件的类型，所述配置文件的类型包括：系统内部的配置文件和内置应用的配置文件；升级模块，用于基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级。本发明还公开了一种服务器及配置文件升级方法。本发明提高了配置文件的升级效率。

Description

终端、服务器及配置文件升级方法

技术领域

本发明涉及通信技术领域，尤其涉及一种终端、服务器及配置文件升级方法。

背景技术

目前，对手机中的配置文件进行升级时，一般都是对ROM(手机操作系统)进行升级，这种升级方式，需要等到ROM版本整体发布才能进行配置文件的升级，并且对ROM版本进行升级，所花费的时间也比较长，从而导致配置文件的升级效率低。

发明内容

本发明的主要目的在于提出一种终端、服务器及配置文件升级方法，旨在解决现有的配置文件方式，升级效率低的技术问题。

为实现上述目的，本发明提供了一种终端，用于对配置文件进行升级，所述终端包括：

提取模块，用于从服务器中获取到配置文件升级包时，对所述配置文件升级包进行解析以提取出下载地址；

下载模块，用于根据提取的所述下载地址下载配置文件；

确定模块，用于确定下载的所述配置文件的类型，所述配置文件的类型包括：系统内部的配置文件和内置应用的配置文件；

升级模块，用于基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级。

可选地，所述从服务器中获取配置文件升级包的方式包括：

接收服务器推送的配置文件升级包；或者

定时在所述服务器的内存中拉取配置文件升级包。

可选地，所述升级模块包括：

备份单元，用于对与所述配置文件的类型匹配的所述本地配置文件进行备份；

测试单元，用于通过下载的所述配置文件中预存的测试代码，对所述配置文件进行测试；

升级单元，用于在所述配置文件测试成功时，基于下载的所述配置文件，对所述本地配置文件进行升级。

此外，为实现上述目的，本发明提供了一种服务器，所述服务器包括：

处理模块，用于确定待升级的配置文件类型，并提取出确定类型的配置文件名；

添加模块，用于对提取的所述配置文件名添加版本号；

生成模块，用于在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包；

传送模块，用于将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级。

可选地，所述将生成的所述配置文件升级包传送至预设区域的方式包括：

将生成的所述配置文件升级包推送至所述终端；或者

将生成所述配置文件升级包存储到所述服务器的内存中，以供所述终端在所述内存中拉取所述配置文件升级包。

可选地，所述配置文件升级装置还包括：

调用模块，用于所述传送模块将生成的所述配置文件升级包传送至预设区域时，调用ZK网页应用程序开发框架创建节点，其中，节点名称为配置文件的标识信息；

启动模块，用于基于所述ZK创建的节点启动API调用接口，以供所述API在配置文件升级包对应的配置哈希表中缓存所述配置文件升级包，便于所述服务器下次发布配置文件升级包时，从所述配置哈希表中获取缓存的所述配置文件升级包进行发布。

此外，为实现上述目的，本发明提供了一种配置文件升级方法，应用于终端，所述配置文件升级方法包括：

终端从服务器中获取到配置文件升级包时，对所述配置文件升级包进行解析以提取出下载地址；

根据提取的所述下载地址下载配置文件；

确定下载的所述配置文件的类型，所述配置文件的类型包括：系统内部的配置文件和内置应用的配置文件；

基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级。

可选地，所述终端从服务器中获取配置文件升级包的方式包括：

所述终端接收服务器推送的配置文件升级包；或者

所述终端定时在所述服务器的内存中拉取配置文件升级包。

可选地，所述基于下载的所述配置文件，对确定类型的本地配置文件进行升级的步骤包括：

对与所述配置文件的类型匹配的所述本地配置文件进行备份；

通过下载的所述配置文件中预存的测试代码，对所述配置文件进行测试；

在所述配置文件测试成功时，基于下载的所述配置文件，对所述本地配置文件进行升级。

此外，为实现上述目的，本发明提供了一种配置文件升级方法，应用于服务器，所述配置文件升级方法包括：

服务器确定待升级的配置文件类型，并提取出确定类型的配置文件名；

对提取的所述配置文件名添加版本号；

在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包；

将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级。

可选地，所述将生成的所述配置文件升级包传送至预设区域的方式包括：

所述服务器将生成的所述配置文件升级包推送至所述终端；或者

所述服务器将生成所述配置文件升级包存储到所述服务器的内存中，以供所述终端在所述内存中拉取所述配置文件升级包。

可选地，执行所述将生成的所述配置文件升级包传送至预设区域的同时，执行以下步骤：

所述服务器调用ZK网页应用程序开发框架创建节点，其中，节点名称为配置文件的标识信息；

基于所述ZK创建的节点启动API调用接口，以供所述API在配置文件升级包对应的配置哈希表中缓存所述配置文件升级包，便于所述服务器下次发布配置文件升级包时，从所述配置哈希表中获取缓存的所述配置文件升级包进行发布。

本发明提出的终端、服务器及配置文件升级方法，终端从服务器中获取到配置文件升级包时，对所述配置文件升级包进行解析以提取出下载地址，然后根据提取的所述下载地址下载配置文件，再确定下载的所述配置文件的类型，最终基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级，实现了终端从服务器中获取的是配置文件升级包，后续对配置文件升级包进行解析得到下载地址后，即可下载对应的配置文件进行升级，不需要等到ROM系统整体发布时，才能进行配置文件的升级，提高了配置文件升级的效率。

附图说明

图1为实现本发明各个实施例一个可选地终端的硬件结构示意图；

图2为如图1所示的终端的无线通信装置示意图；

图3为本发明终端第一实施例的模块示意图；

图4为图3中升级模块的细化模块示意图；

图5本发明中终端对配置文件的升级过程的较佳流程图；

图6为本发明服务器第一实施例的模块示意图；

图7为本发明中服务器生成配置文件的较佳流程图；

图8为本发明中服务器根据半路径生成全路径的较佳流程图；

图9为本发明中服务器发布配置文件的较佳流程图；

图10为本发明中配置文件升级包获取方式的较佳流程图；

图11为本发明中应用相关的配置缓存表中获取配置文件升级包的较佳流程图；

图12本发明中服务器删除配置文件的较佳流程图；

图13为本发明应用于终端的配置文件升级方法第一实施例的流程示意图；

图14为本发明基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级的细化流程示意图；

图15为本发明应用于服务器的配置文件升级方法第一实施例的流程示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，“模块”与“部件”可以混合地使用。

终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例的一个可选地终端的硬件结构示意图。

终端100可以包括无线通信单元110、A/V(音频/视频)输入单元120、用户输入单元130、感测单元140、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的终端，但是应理解的是，并不要求实施所有示出的组件。可以替代地实施更多或更少的组件。将在下面详细描述终端的元件。

无线通信单元110通常包括一个或多个组件，其允许终端100与无线通信装置或网络之间的无线电通信。

A/V输入单元120用于接收音频或视频信号。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制终端的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示单元151上时，可以形成触摸屏。

感测单元140检测终端100的当前状态，(例如，终端100的打开或关闭状态)、终端100的位置、用户对于终端100的接触(即，触摸输入)的有无、终端100的取向、终端100的加速或将速移动和方向等等，并且生成用于控制终端100的操作的命令或信号。例如，当终端100实施为滑动型移动电话时，感测单元140可以感测该滑动型电话是打开还是关闭。另外，感测单元140能够检测电源单元190是否提供电力或者接口单元170是否与外部装置耦接。

接口单元170用作至少一个外部装置与终端100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(I/O)端口、视频I/O端口、耳机端口等等。识别模块可以是存储用于验证用户使用终端100的各种信息并且可以包括用户识别模块(UIM)、客户识别模块(SIM)、通用客户识别模块(USIM)等等。另外，具有识别模块的装置(下面称为“识别装置”)可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与终端100连接。接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到终端100内的一个或多个元件或者可以用于在终端和外部装置之间传输数据。

另外，当终端100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到终端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到终端的路径。从底座输入的各种命令信号或电力可以用作用于识别终端是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。输出单元150可以包括显示单元151。

显示单元151可以显示在终端100中处理的信息。例如，当终端100处于电话通话模式时，显示单元151可以显示与通话或其它通信(例如，文本消息收发、多媒体文件下载等等)相关的用户界面(UI)或图形用户界面(GUI)。当终端100处于视频通话模式或者图像捕获模式时，显示单元151可以显示捕获的图像和/或接收的图像、示出视频或图像以及相关功能的UI或GUI等等。

同时，当显示单元151和触摸板以层的形式彼此叠加以形成触摸屏时，显示单元151可以用作输入装置和输出装置。显示单元151可以包括液晶显示器(LCD)、薄膜晶体管LCD(TFT-LCD)、有机发光二极管(OLED)显示器、柔性显示器、三维(3D)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为TOLED(透明有机发光二极管)显示器等等。根据特定想要的实施方式，终端100可以包括两个或更多显示单元(或其它显示装置)，例如，终端可以包括外部显示单元(未示出)和内部显示单元(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等等。而且，终端100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制终端的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。另外，控制器180可以包括用于再现(或回放)多媒体数据的多媒体模块181，多媒体模块181可以构造在控制器180内，或者可以构造为与控制器180分离。控制器180可以执行模式识别处理，以将在触摸屏上执行的手写输入或者图片绘制输入识别为字符或图像。

电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对于硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理装置(DSPD)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对于软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

至此，己经按照其功能描述了终端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型终端等等的各种类型的终端中的滑动型终端作为示例。因此，本发明能够应用于任何类型的终端，并且不限于滑动型终端。

如图1中所示的终端100可以被构造为利用经由帧或分组发送数据的诸如有线和无线通信装置以及基于卫星的通信装置来操作。

现在将参考图2描述其中根据本发明的终端能够操作的通信装置。

这样的通信装置可以使用不同的空中接口和/或物理层。例如，由通信装置使用的空中接口包括例如频分多址(FDMA)、时分多址(TDMA)、码分多址(CDMA)和通用移动通信装置(UMTS)(特别地，长期演进(LTE))、全球移动通信装置(GSM)等等。作为非限制性示例，下面的描述涉及CDMA通信装置，但是这样的教导同样适用于其它类型的装置。

参考图2，CDMA无线通信装置可以包括多个终端100、多个基站(BS)270、基站控制器(BSC)275和移动交换中心(MSC)280。MSC280被构造为与公共电话交换网络(PSTN)290形成接口。MSC280还被构造为与可以经由回程线路耦接到基站270的BSC275形成接口。回程线路可以根据若干己知的接口中的任一种来构造，所述接口包括例如E1/T1、ATM，IP、PPP、帧中继、HDSL、ADSL或xDSL。将理解的是，如图2中所示的装置可以包括多个BSC2750。

每个BS270可以服务一个或多个分区(或区域)，由多向天线或指向特定方向的天线覆盖的每个分区放射状地远离BS270。或者，每个分区可以由用于分集接收的两个或更多天线覆盖。每个BS270可以被构造为支持多个频率分配，并且每个频率分配具有特定频谱(例如，1.25MHz,5MHz等等)。

分区与频率分配的交叉可以被称为CDMA信道。BS270也可以被称为基站收发器子装置(BTS)或者其它等效术语。在这样的情况下，术语"基站"可以用于笼统地表示单个BSC275和至少一个BS270。基站也可以被称为"蜂窝站"。或者，特定BS270的各分区可以被称为多个蜂窝站。

如图2中所示，广播发射器(BT)295将广播信号发送给在装置内操作的终端100。如图1中所示的广播接收模块111被设置在终端100处以接收由BT295发送的广播信号。在图2中，示出了几个全球定位装置(GPS)卫星300。卫星300帮助定位多个终端100中的至少一个。

在图2中，描绘了多个卫星300，但是可以理解的是，可以利用任何数目的卫星获得有用的定位信息。如图1中所示的GPS模块115通常被构造为与卫星300配合以获得想要的定位信息。替代GPS跟踪技术或者在GPS跟踪技术之外，可以使用可以跟踪终端的位置的其它技术。另外，至少一个GPS卫星300可以选择性地或者额外地处理卫星DMB传输。

作为无线通信装置的一个典型操作，BS270接收来自各种终端100的反向链路信号。终端100通常参与通话、消息收发和其它类型的通信。特定基站270接收的每个反向链路信号被在特定BS270内进行处理。获得的数据被转发给相关的BSC275。BSC提供通话资源分配和包括BS270之间的软切换过程的协调的移动管理功能。BSC275还将接收到的数据路由到MSC280，其提供用于与PSTN290形成接口的额外的路由服务。类似地，PSTN290与MSC280形成接口，MSC与BSC275形成接口，并且BSC275相应地控制BS270以将正向链路信号发送到终端100。

目前，当需要对系统进行优化或解决某些测试发现或用户反馈的问题时，需要对各配置文件的参数进行调整时，在以往的技术方案中，需要对ROM进行升级，这种升级方式存在的问题是：

需要提示用户进行升级，且速度相对较慢，用户体验不佳；

需要等到ROM版本整体发布，更新的效率较低；

如果用户不进行ROM升级，则无法对配置文件进行更新，那么就无法为用户实现系统优化或解决已知问题。

基于上述终端硬件结构、通信装置的结构，以及现有技术存在的问题，提出本发明终端的各个实施例。

参照图3，图3为本发明终端第一实施例的模块示意图。

本实施例中的所述终端即图1中所述的终端。

需要强调的是，对本领域的技术人员来说，图3所示模块图仅仅是一个较佳实施例的示例图，本领域的技术人员围绕图3所示的终端的模块，可轻易进行新的模块的补充；各模块的名称是自定义名称，仅用于辅助理解该终端的各个程序功能块，不用于限定本发明的技术方案，本发明技术方案的核心是，各自定义名称的模块所要达成的功能。

在本实施例中，所述终端包括：

提取模块10，用于从服务器中获取到配置文件升级包时，对所述配置文件升级包进行解析以提取出下载地址；

下载模块20，用于根据提取的所述下载地址下载配置文件；

确定模块30，用于确定下载的所述配置文件的类型，所述配置文件的类型包括：系统内部的配置文件和内置应用的配置文件；

升级模块40，用于基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级。

在本实施例中，相当于是在终端中安装一套配置中控，由该配置中控从服务器(对应配置管理系统，在下文中详述)中获取配置文件升级包。配置中控在获取到配置文件升级包时，判断该配置文件升级包是属于系统内部的配置文件还是内置应用的配置文件，并根据它们的类别，对对应的配置文件进行升级，并保证配置升级的容错性。

当提取模块10从服务器中获取到配置文件升级包时，先对所述配置文件升级包进行解析以提取出下载地址，然后下载模块20根据提取的所述下载地址在所述服务器中下载对应的配置文件，在配置文件下载成功时，确定模块30再确定下载的所述配置文件的类型，最终升级模块40基于下载的所述配置文件，对确定类型的本地配置文件进行升级。

本实施例中，所述配置文件的类型包括两类，一类是系统内部与机型相关的配置文件，称为系统配置文件，例如CPU功耗参数，屏幕参数，射频参数等等；一类是与系统内置应用相关的配置文件，称为应用配置文件，例如手机管家的黑白名单等等。

进一步地，本实施例中，所述升级模块40基于下载的所述配置文件，对确定类型的本地配置文件进行升级的方式包括：全部升级或部分升级，其中，所述全部升级指的是用下载的配置文件替换本地配置文件，部分升级指的是用配置文件中升级的部分更新本地配置文件中对应的部分。

在本实施例中，所述配置文件升级包的参数信息如下表所示：

其中，所述配置文件组中配置文件的参数信息如下表所示：

也就是说，配置中控在获取到配置升级包时，对配置升级包进行解析，然后根据下载地址，对各配置文件进行下载，下载成功后，根据下载的配置文件对本地配置文件进行升级。

本实施例提出的终端，提取模块从服务器中获取到配置文件升级包时，对所述配置文件升级包进行解析以提取出下载地址，下载模块根据提取的所述下载地址下载配置文件，确定模块确定下载的所述配置文件的类型，升级模块基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级，实现了终端从服务器中获取的是配置文件升级包，后续对配置文件升级包进行解析得到下载地址后，即可下载对应的配置文件进行升级，不需要等到ROM系统整体发布时，才能进行配置文件的升级，提高了配置文件升级的效率。

进一步地，提出本发明终端的第二实施例。

终端的第二实施例与终端的第一实施例的区别在于，所述从服务器中获取配置文件升级包的方式包括：

接收服务器推送的配置文件升级包；或者

定时在所述服务器的内存中拉取配置文件升级包。

在本实施例中，所述终端先从服务器中获取配置文件升级包，其中，获取方式包括：

a、所述终端接收服务器推送的配置文件升级包。

也就是说，服务器通过推送的方式，将要升级的配置文件升级包推送至终端，由终端进行升级。

b、所述终端定时在所述服务器的内存中拉取配置文件升级包。

由于推送消息可能会因为网络信号差、手机未开启网络等原因，无法成功到达终端，为了保证配置文件升级包能到达每一个终端，终端除了要对接收到的配置升级推送消息进行处理，还可以定时在所述服务器的内存中拉取配置文件升级包，以保证未接收到服务器推送的配置文件升级包时也能进行配置文件的升级。具体地，所述终端定时在所述服务器的内存中拉取与所述终端的机型对应的配置文件升级包。对于服务器而言，就需要将配置文件升级包先缓存在内存中。

本实施例中，终端获取配置文件升级包，不仅可以通过服务器推送的方式获取，还可以自动定时从服务器的内存中拉取所述配置文件升级包，即使当前由于网络或信号故障没有接收到，也可以在后续自动进行获取，提高了配置文件升级包获取的灵活性。

进一步地，提出本发明终端的第三实施例。

终端的第三实施例与终端的第一或第二实施例的区别在于，参照图4，所述升级模块40包括：

备份单元41，用于对与所述配置文件的类型匹配的所述本地配置文件进行备份；

测试单元42，用于通过下载的所述配置文件中预存的测试代码，对所述配置文件进行测试；

升级单元43，用于在所述配置文件测试成功时，基于下载的所述配置文件，对所述本地配置文件进行升级。

在本实施例中，所述升级模块40基于下载的所述配置文件，对确定类型的本地配置文件进行升级的具体实施方式包括：首先，备份单元41先对确定类型的所述本地配置文件进行备份，然后将下载的配置文件中的配置部分更新到对应的配置文件中，测试单元42通过下载的所述配置文件中预存的测试代码，对所述配置文件进行测试，如果测试代码运行通过，即所述配置文件测试成功，升级单元43就基于下载的所述配置文件，对确定类型的所述本地配置文件进行升级，优选根据下载的配置文件替换对应的本地配置文件。

可以理解的是，当所述配置文件测试失败时，例如，下载的配置文件有问题，即可换回之前备份的本地配置文件，并将出错信息上报到服务器中，以提示服务器进行调整更换。

为更好理解本发明中，终端对配置文件的升级过程，结合第一实施例、第二实施例和第三实施例的内容，以及参照图5，对终端的配置文件升级过程进行详述：

首先，终端在接收到配置文件升级包的推送消息，或者是从服务器的内内存中拉取到配置文件升级包时，对配置文件升级包进行解析，此时，从配置文件升级包中解析出配置文件升级包的下载地址，然后从服务器中下载该配置文件升级包，接着确定配置文件包中的配置文件，然后遍历配置文件，在遍历过程中，对本地配置文件进行备份，在本地配置文件备份之后，需要确定配置文件的下载地址，并从服务器中下载对应的配置文件，再运行配置文件中的测试代码，判断测试是否通过，在测试通过时，对配置文件进行升级更新，若测试未通过，上报错误消息给服务器的配置管理系统。

在本实施例中，对所述本地配置文件进行备份，并通过下载的所述配置文件中预存的测试代码，对所述配置文件进行测试，实现了在配置文件测试成功时，才进行配置文件的升级，若是测试不成功，仍然保留原来的配置文件，防止了配置文件有误，却已经将本地的配置文件删除了，通过这种检测机制，保证了配置文件正常时才进行升级，从而提高了配置文件升级的准确性和智能性。

本发明进一步提出一种服务器。

参照图6，图6为本发明服务器第一实施例的模块示意图。

在本实施例中，所述服务器包括：

处理模块50，用于确定待升级的配置文件类型，并提取出确定类型的配置文件名；

添加模块60，用于对提取的所述配置文件名添加版本号；

生成模块70，用于在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包；

传送模块80，用于将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级。

在本实施例中，由于机型系统或内置应用优化时，有可能只涉及到配置文件的更新，因此就需要一套新系统来进行支撑，本实施中，优选通过服务器的配置管理系统实现，所述配置管理系统，对配置文件进行管理和升级发布。当有通过配置文件升级进行系统优化或解决某些问题的需求时，将对应的配置文件上传到配置管理系统，并进行小批量的内部用户推送测试，待测试通过后，再进行全量推送或缓存至内存中，以保证所有用户能够进行对应配置文件的升级。

为更好理解，参照图7，首先，处理模块50先确定待升级的配置文件类型，如是机型还是应用的配置文件，然后选择添加机型名或应用名，接着选择机型或应用的配置文件，提取机型或应用的配置文件名，再解析各级分类。本实施例中，所述各级分类，指的是配置文件的命令规则分类，具体地，可分为配置文件的命名规则为分类1_、分类2_、...分类n_、文件名称.后缀名。后台在添加配置文件的时候，根据对文件名的解析，自动生成其分类信息。在解析成功之后，添加模块60对提取的所述配置文件名添加版本号，此时，进一步确定配置文件是否为应用的配置文件，若是应用的配置文件，还会在模块表中查找应用名所对应的数据记录，判断记录是否存在，若存在，就自动填写包名，若不存在，又管理员输入包名，最终同样填写应用版本号。

在填写完成后，若检测到上传指令时，生成模块70根据添加版本号的配置文件名生成下载路径，为了灵活实现后续可能的CDN(Content Delivery Network，即内容分发网络)切换等需求，此时，配置文件的下载路径设计为半路径，即配置文件上传成功后，保存在数据库表中的路径为不带具体域名的路径，然后所述服务器保存机型名或应用名及分类信息到配置文件标识表中，并保存配置文件到配置文件表中，在保存成功时，即可生成配置文件的全路径，也就是包括域名的路径，此时，全路径就是配置文件的下载地址，进一步地，生成模块70生成包含下载地址的配置文件升级包，最终传送模块80将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级。

在本实施例中，所述生成模块70根据半路径生成全路径的方式，可参照图8：首先，所述服务器获取配置文件的半路径，然后读取域名表中的第一条记录，根据其current-_id(当前配置文件的ID)获取具体的域名，最终将域名和半路径进行拼接生成配置文件的全路径。

本实施例提出的服务器，处理模块确定待升级的配置文件类型，并提取出确定类型的配置文件名，添加模块对提取的所述配置文件名添加版本号，生成模块在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包，传送模块将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级，实现了服务器根据添加版本号的配置文件名生成包含下载地址的配置文件升级包之后，即可传送至预设区域，由终端获取到所述配置文件升级包时，对配置文件升级包进行解析得到下载地址后，下载对应的配置文件进行升级，不需要等到ROM系统整体发布时，才能进行配置文件的升级，提高了配置文件升级的效率。

进一步地，提出本发明服务器的第二实施例。

服务器的第二实施例与服务器的第一实施例的区别在于，所述将生成的所述配置文件升级包传送至预设区域的方式包括：

将生成的所述配置文件升级包推送至所述终端；或者

将生成所述配置文件升级包存储到所述服务器的内存中，以供所述终端在所述内存中拉取所述配置文件升级包。

在本实施中，为了实现最优的并发性能，配置管理系统中引入Zookeeper分布式管理服务，并实现了一套内存缓存方案，将配置文件的信息保存在内存中，供终端进行拉取。应当理解的是，在服务器内部实现了一套高效的内存缓存方案，保证能用最少的服务器实现最优的并发性能。

本实施例中，传送配置文件升级包，不仅包括服务器推送的方式，还可以由服务器将生成所述配置文件升级包存储到所述服务器的内存中，以供所述终端在所述内存中拉取所述配置文件升级包，即使当前由于网络或信号故障没有推送成功，后续也可以由终端自动拉取，提高了配置文件升级包传送的灵活性。

进一步地，提出本发明服务器的第三实施例。

服务器的第三实施例与服务器的第一或第二实施例的区别在于，所述服务器还包括：

调用模块，用于所述传送模块将生成的所述配置文件升级包传送至预设区域时，调用ZK网页应用程序开发框架创建节点，其中，节点名称为配置文件的标识信息；

启动模块，用于基于所述ZK创建的节点启动API调用接口，以供所述API在配置文件升级包对应的配置哈希表中缓存所述配置文件升级包，便于所述服务器下次发布配置文件升级包时，从所述配置哈希表中获取缓存的所述配置文件升级包进行发布。

在本实施例中，所述服务器发布配置文件时，需要通知到API(ApplicationProgram Interface)进行缓存的刷新，其具体流程如参照图9所示：

调用模块调用ZK创建节点，其中，节点名称为配置文件的标识信息，然后启动模块根据所述ZK创建的节点启动API调用接口，所述API在接收到创建节点的通知时，在配置文件升级包对应的配置哈希表中缓存所述配置文件升级包，便于所述服务器下次发布配置文件升级包时，从所述配置哈希表中获取缓存的所述配置文件升级包进行发布。值得注意的是，若为机型相关的则刷新机型相关配置文件哈希表，若为应用相关则刷新应用配置文件哈希表，进一步地，若为应用相关则根据包名刷新应用配置文件缓存表。

为了实现最优并发性能，系统使用内存级的缓存方案。缓存结构有5个：

1、机型相关的配置文件哈希表

机型相关的配置文件哈希表的键为机型ID，值为配置文件ID列表，值为该机型下各可用配置文件的最新版本：如下表所示

2、应用相关的配置文件哈希表

应用相关的配置文件哈希表的键为应用包名，值为配置文件哈希表，该哈希表的键为配置文件标识ID，值为可用配置文件ID列表，其排序规则为按照文件版本号倒序。

3、配置文件哈希表

配置文件哈希表的键为配置文件ID，值为配置文件的具体内容

4、包名缓存键哈希表

包名缓存键哈希表的键为包名，值为机型ID、包名与应用版本码缓存键列表。当发布配置文件的时候，如果配置文件为应用相关类型，则根据其包名信息找到缓存键列表，刷新对应的缓存内容。

5、包名缓存键哈希表

包名缓存键哈希表的键为包名，值为机型ID、包名与应用版本码缓存键列表。当发布配置文件的时候，如果配置文件为应用相关类型，则根据其包名信息找到缓存键列表，刷新对应的缓存内容。

根据上述5种结构的哈希表，将配置文件的内容进行缓存，其中，在一个配置文件属于一种类型时，就将该配置文件的内容缓存到该类型对应的哈希表中。

其中，各表的关系如下：

值得注意的是，所述应用相关哈希表，不针对某个版本的应用，即只要是该应用，就可以缓存到应用相关哈希表，所述应用配置文件哈希表携带包名，针对版本号应用，只要应用包名和版本号符合的才能进行缓存，所述包名缓存键哈希表是指缓存请求过的版本号，若是一类版本号应用以及被请求过，缓存到该包名缓存键哈希表，后续即可直接从该处获取。

本方案中，所共有的部分是配置包的获取方式，基本流程为参照图10：

首先根据机型获取机型相关类型所匹配的配置文件列表，然后根据各应用包名、版本号及机型的信息获取其缓存内容，若缓存存在，则直接获取其配置文件列表；若不存在，则访问各缓存表生成该配置文件列表并写入应用配置文件缓存表中，最后组成配置包返回给终端。

从应用相关的配置缓存表中获取配置包时，需要刷新该应用对应的配置文件缓存。其流程可参照图11。

进一步地，本实施例中，当所述服务器要删除配置文件时，同样需要通知到API进行缓存的刷新，其具体流程参照图12：

所述服务器调用ZK创建节点，其中，节点名称为配置文件的标识信息，然后根据所述ZK创建的节点启动API调用接口，所述API在接收到创建节点的通知时，在配置文件升级包对应的配置哈希表中删除所述配置文件升级包。值得注意的是，若为机型相关的则刷新机型相关配置文件哈希表，若为应用相关则刷新应用配置文件哈希表，进一步地，若为应用相关则根据包名刷新应用配置文件缓存表。

本发明还提供一种配置文件升级方法，应用于终端。

本发明中的终端包括手机、PC侧、平板电脑等等。

参照图13，图13为本发明应用于终端的配置文件升级方法第一实施例的流程示意图。

在本实施例中，所述配置文件升级方法包括：

步骤S10，终端从服务器中获取到配置文件升级包时，对所述配置文件升级包进行解析以提取出下载地址；

步骤S20，根据提取的所述下载地址下载配置文件；

步骤S30，确定下载的所述配置文件的类型，所述配置文件的类型包括：系统内部的配置文件和内置应用的配置文件；

步骤S40，基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级。

在本实施例中，相当于是在终端中安装一套配置中控，由该配置中控从服务器(对应配置管理系统，在下文中详述)中获取配置文件升级包。配置中控在获取到配置文件升级包时，判断该配置文件升级包是属于系统内部的配置文件还是内置应用的配置文件，并根据它们的类别，对对应的配置文件进行升级，并保证配置升级的容错性。

当终端从服务器中获取到配置文件升级包时，先对所述配置文件升级包进行解析以提取出下载地址，然后根据提取的所述下载地址在所述服务器中下载对应的配置文件，在配置文件下载成功时，再确定下载的所述配置文件的类型，最终基于下载的所述配置文件，对确定类型的本地配置文件进行升级。

本实施例中，所述配置文件的类型包括两类，一类是系统内部与机型相关的配置文件，称为系统配置文件，例如CPU功耗参数，屏幕参数，射频参数等等；一类是与系统内置应用相关的配置文件，称为应用配置文件，例如手机管家的黑白名单等等。

进一步地，本实施例中，所述终端基于下载的所述配置文件，对确定类型的本地配置文件进行升级的方式包括：全部升级或部分升级，其中，所述全部升级指的是用下载的配置文件替换本地配置文件，部分升级指的是用配置文件中升级的部分更新本地配置文件中对应的部分。

在本实施例中，所述配置文件升级包的参数信息如下表所示：

其中，所述配置文件组中配置文件的参数信息如下表所示：

也就是说，终端的配置中控在获取到配置升级包时，对配置升级包进行解析，然后根据下载地址，对各配置文件进行下载，下载成功后，根据下载的配置文件对本地配置文件进行升级。

本发明提出的应用于终端的配置文件升级方法，终端从服务器中获取到配置文件升级包时，对所述配置文件升级包进行解析以提取出下载地址，然后根据提取的所述下载地址下载配置文件，再确定下载的所述配置文件的类型，最终基于下载的所述配置文件，对与所述配置文件的类型匹配的本地配置文件进行升级，实现了终端从服务器中获取的是配置文件升级包，后续对配置文件升级包进行解析得到下载地址后，即可下载对应的配置文件进行升级，不需要等到ROM系统整体发布时，才能进行配置文件的升级，提高了配置文件升级的效率。

进一步地，提出本发明配置文件升级方法的第二实施例。

配置文件升级方法的第二实施例与配置文件升级方法的第一实施例的区别在于，所述终端从服务器中获取配置文件升级包的方式包括：

所述终端接收服务器推送的配置文件升级包；或者

所述终端定时在所述服务器的内存中拉取配置文件升级包。

在本实施例中，所述终端先从服务器中获取配置文件升级包，其中，获取方式包括：

a、所述终端接收服务器推送的配置文件升级包。

也就是说，服务器通过推送的方式，将要升级的配置文件升级包推送至终端，由终端进行升级。

b、所述终端定时在所述服务器的内存中拉取配置文件升级包。

由于推送消息可能会因为网络信号差、手机未开启网络等原因，无法成功到达终端，为了保证配置文件升级包能到达每一个终端，终端除了要对接收到的配置升级推送消息进行处理，还可以定时在所述服务器的内存中拉取配置文件升级包，以保证未接收到服务器推送的配置文件升级包时也能进行配置文件的升级。具体地，所述终端定时在所述服务器的内存中拉取与所述终端的机型对应的配置文件升级包。对于服务器而言，就需要将配置文件升级包先缓存在内存中。

本实施例中，终端获取配置文件升级包，不仅可以通过服务器推送的方式获取，还可以自动定时从服务器的内存中拉取所述配置文件升级包，即使当前由于网络或信号故障没有接收到，也可以在后续自动进行获取，提高了配置文件升级包获取的灵活性。

进一步地，提出本发明配置文件升级方法的第三实施例。

配置文件升级方法的第三实施例与配置文件升级方法的第一或第二实施例的区别在于，参照图14，所述步骤S40包括：

步骤S41，对与所述配置文件的类型匹配的所述本地配置文件进行备份；

步骤S42，通过下载的所述配置文件中预存的测试代码，对所述配置文件进行测试；

步骤S43，在所述配置文件测试成功时，基于下载的所述配置文件，对所述本地配置文件进行升级。

在本实施例中，所述基于下载的所述配置文件，对确定类型的本地配置文件进行升级的具体实施方式包括：首先，先对确定类型的所述本地配置文件进行备份，然后将下载的配置文件中的配置部分更新到对应的配置文件中，并通过下载的所述配置文件中预存的测试代码，对所述配置文件进行测试，如果测试代码运行通过，即所述配置文件测试成功，就基于下载的所述配置文件，对确定类型的所述本地配置文件进行升级，优选根据下载的配置文件替换对应的本地配置文件。

可以理解的是，当所述配置文件测试失败时，例如，下载的配置文件有问题，即可换回之前备份的本地配置文件，并将出错信息上报到服务器中，以提示服务器进行调整更换。

为更好理解本发明中，终端对配置文件的升级过程，结合第一实施例、第二实施例和第三实施例的内容，以及参照图5，对终端的配置文件升级过程进行详述：

首先，终端在接收到配置文件升级包的推送消息，或者是从服务器的内内存中拉取到配置文件升级包时，对配置文件升级包进行解析，此时，从配置文件升级包中解析出配置文件升级包的下载地址，然后从服务器中下载该配置文件升级包，接着确定配置文件包中的配置文件，然后遍历配置文件，在遍历过程中，对本地配置文件进行备份，在本地配置文件备份之后，需要确定配置文件的下载地址，并从服务器中下载对应的配置文件，再运行配置文件中的测试代码，判断测试是否通过，在测试通过时，对配置文件进行升级更新，若测试未通过，上报错误消息给服务器的配置管理系统。

在本实施例中，对所述本地配置文件进行备份，并通过下载的所述配置文件中预存的测试代码，对所述配置文件进行测试，实现了在配置文件测试成功时，才进行配置文件的升级，若是测试不成功，仍然保留原来的配置文件，防止了配置文件有误，却已经将本地的配置文件删除了，通过这种检测机制，保证了配置文件正常时才进行升级，从而提高了配置文件升级的准确性和智能性。

本发明进一步提供一种配置文件升级方法，应用于服务器。

参照图15，图15为本发明应用于服务器的配置文件升级方法第一实施例的流程示意图。

在本实施例中，所述配置文件升级方法包括：

步骤S50，服务器确定待升级的配置文件类型，并提取出确定类型的配置文件名；

步骤S60，对提取的所述配置文件名添加版本号；

步骤S70，在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包；

步骤S80，将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级。

在本实施例中，由于机型系统或内置应用优化时，有可能只涉及到配置文件的更新，因此就需要一套新系统来进行支撑，本实施中，优选通过服务器的配置管理系统实现，所述配置管理系统，对配置文件进行管理和升级发布。当有通过配置文件升级进行系统优化或解决某些问题的需求时，将对应的配置文件上传到配置管理系统，并进行小批量的内部用户推送测试，待测试通过后，再进行全量推送或缓存至内存中，以保证所有用户能够进行对应配置文件的升级。

为更好理解，参照图7，首先，服务器先确定待升级的配置文件类型，如是机型还是应用的配置文件，然后选择添加机型名或应用名，接着选择机型或应用的配置文件，提取机型或应用的配置文件名，再解析各级分类。本实施例中，所述各级分类，指的是配置文件的命令规则分类，具体地，可分为配置文件的命名规则为分类1_、分类2_、...分类n_、文件名称.后缀名。后台在添加配置文件的时候，根据对文件名的解析，自动生成其分类信息。在解析成功之后，对提取的所述配置文件名添加版本号，此时，进一步确定配置文件是否为应用的配置文件，若是应用的配置文件，还会在模块表中查找应用名所对应的数据记录，判断记录是否存在，若存在，就自动填写包名，若不存在，又管理员输入包名，最终同样填写应用版本号。

在填写完成后，若检测到上传指令时，根据添加版本号的配置文件名生成下载路径，为了灵活实现后续可能的CDN(Content Delivery Network，即内容分发网络)切换等需求，此时，配置文件的下载路径设计为半路径，即配置文件上传成功后，保存在数据库表中的路径为不带具体域名的路径，然后所述服务器保存机型名或应用名及分类信息到配置文件标识表中，并保存配置文件到配置文件表中，在保存成功时，即可生成配置文件的全路径，也就是包括域名的路径，此时，全路径就是配置文件的下载地址，进一步地，所述服务器生成包含下载地址的配置文件升级包，最终将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级。

在本实施例中，所述服务器根据半路径生成全路径的方式，可参照图8：首先，所述服务器获取配置文件的半路径，然后读取域名表中的第一条记录，根据其current-_id(当前配置文件的ID)获取具体的域名，最终将域名和半路径进行拼接生成配置文件的全路径。

本发明提出的应用于服务器的配置文件升级方法，服务器先确定待升级的配置文件类型，并提取出确定类型的配置文件名，然后对提取的所述配置文件名添加版本号，在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包，最终将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级，实现了服务器根据添加版本号的配置文件名生成包含下载地址的配置文件升级包之后，即可传送至预设区域，由终端获取到所述配置文件升级包时，对配置文件升级包进行解析得到下载地址后，下载对应的配置文件进行升级，不需要等到ROM系统整体发布时，才能进行配置文件的升级，提高了配置文件升级的效率。

进一步地，提出本发明配置文件升级方法的第二实施例。

配置文件升级方法的第二实施例与配置文件升级方法的第一实施例的区别在于，所述将生成的所述配置文件升级包传送至预设区域的方式包括：

所述服务器将生成的所述配置文件升级包推送至所述终端；或者

所述服务器将生成所述配置文件升级包存储到所述服务器的内存中，以供所述终端在所述内存中拉取所述配置文件升级包。

在本实施中，为了实现最优的并发性能，配置管理系统中引入Zookeeper分布式管理服务，并实现了一套内存缓存方案，将配置文件的信息保存在内存中，供终端进行拉取。应当理解的是，在服务器内部实现了一套高效的内存缓存方案，保证能用最少的服务器实现最优的并发性能。

本实施例中，传送配置文件升级包，不仅包括服务器推送的方式，还可以由服务器将生成所述配置文件升级包存储到所述服务器的内存中，以供所述终端在所述内存中拉取所述配置文件升级包，即使当前由于网络或信号故障没有推送成功，后续也可以由终端自动拉取，提高了配置文件升级包传送的灵活性。

进一步地，提出本发明配置文件升级方法的第三实施例。

配置文件升级方法的第三实施例与配置文件升级方法的第一或第二实施例的区别在于，执行所述将生成的所述配置文件升级包传送至预设区域的同时，执行以下步骤：

所述服务器调用ZK网页应用程序开发框架创建节点，其中，节点名称为配置文件的标识信息；

基于所述ZK创建的节点启动API调用接口，以供所述API在配置文件升级包对应的配置哈希表中缓存所述配置文件升级包，便于所述服务器下次发布配置文件升级包时，从所述配置哈希表中获取缓存的所述配置文件升级包进行发布。

在本实施例中，所述服务器发布配置文件时，需要通知到API(ApplicationProgram Interface)进行缓存的刷新，其具体流程如参照图9所示：

所述服务器调用ZK创建节点，其中，节点名称为配置文件的标识信息，然后根据所述ZK创建的节点启动API调用接口，所述API在接收到创建节点的通知时，在配置文件升级包对应的配置哈希表中缓存所述配置文件升级包，便于所述服务器下次发布配置文件升级包时，从所述配置哈希表中获取缓存的所述配置文件升级包进行发布。值得注意的是，若为机型相关的则刷新机型相关配置文件哈希表，若为应用相关则刷新应用配置文件哈希表，进一步地，若为应用相关则根据包名刷新应用配置文件缓存表。

为了实现最优并发性能，系统使用内存级的缓存方案。缓存结构有5个：

1、机型相关的配置文件哈希表

机型相关的配置文件哈希表的键为机型ID，值为配置文件ID列表，值为该机型下各可用配置文件的最新版本：如下表所示

2、应用相关的配置文件哈希表

应用相关的配置文件哈希表的键为应用包名，值为配置文件哈希表，该哈希表的键为配置文件标识ID，值为可用配置文件ID列表，其排序规则为按照文件版本号倒序。

3、配置文件哈希表

配置文件哈希表的键为配置文件ID，值为配置文件的具体内容

4、包名缓存键哈希表

包名缓存键哈希表的键为包名，值为机型ID、包名与应用版本码缓存键列表。当发布配置文件的时候，如果配置文件为应用相关类型，则根据其包名信息找到缓存键列表，刷新对应的缓存内容。

5、包名缓存键哈希表

包名缓存键哈希表的键为包名，值为机型ID、包名与应用版本码缓存键列表。当发布配置文件的时候，如果配置文件为应用相关类型，则根据其包名信息找到缓存键列表，刷新对应的缓存内容。

根据上述5种结构的哈希表，将配置文件的内容进行缓存，其中，在一个配置文件属于一种类型时，就将该配置文件的内容缓存到该类型对应的哈希表中。

其中，各表的关系如下：

值得注意的是，所述应用相关哈希表，不针对某个版本的应用，即只要是该应用，就可以缓存到应用相关哈希表，所述应用配置文件哈希表携带包名，针对版本号应用，只要应用包名和版本号符合的才能进行缓存，所述包名缓存键哈希表是指缓存请求过的版本号，若是一类版本号应用以及被请求过，缓存到该包名缓存键哈希表，后续即可直接从该处获取。

本方案中，所共有的部分是配置包的获取方式，基本流程为参照图10：

首先根据机型获取机型相关类型所匹配的配置文件列表，然后根据各应用包名、版本号及机型的信息获取其缓存内容，若缓存存在，则直接获取其配置文件列表；若不存在，则访问各缓存表生成该配置文件列表并写入应用配置文件缓存表中，最后组成配置包返回给终端。

从应用相关的配置缓存表中获取配置包时，需要刷新该应用对应的配置文件缓存。其流程可参照图11。

进一步地，本实施例中，当所述服务器要删除配置文件时，同样需要通知到API进行缓存的刷新，其具体流程参照图12：

所述服务器调用ZK创建节点，其中，节点名称为配置文件的标识信息，然后根据所述ZK创建的节点启动API调用接口，所述API在接收到创建节点的通知时，在配置文件升级包对应的配置哈希表中删除所述配置文件升级包。值得注意的是，若为机型相关的则刷新机型相关配置文件哈希表，若为应用相关则刷新应用配置文件哈希表，进一步地，若为应用相关则根据包名刷新应用配置文件缓存表。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (4)

1.一种服务器，其特征在于，所述服务器包括：

处理模块，用于确定待升级的配置文件类型，并提取出确定类型的配置文件名；

添加模块，用于对提取的所述配置文件名添加版本号；

生成模块，用于在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包；

传送模块，用于将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级；

所述服务器还包括：

调用模块，用于在所述传送模块将生成的所述配置文件升级包传送至预设区域时，调用ZK网页应用程序开发框架创建节点，其中，节点名称为配置文件的标识信息；

启动模块，用于基于所述ZK网页应用程序开发框架创建的节点启动API调用接口，以供所述API调用接口在配置文件升级包对应的配置哈希表中缓存所述配置文件升级包，便于所述服务器下次发布配置文件升级包时，从所述配置哈希表中获取缓存的所述配置文件升级包进行发布；

所述在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包的步骤包括：

在检测到上传指令时，根据添加版本号的配置文件名生成下载路径；

在配置文件表中保存机型名或应用名及分类信息，并根据配置文件表和下载路径生成下载地址。

2.如权利要求1所述的服务器，其特征在于，所述将生成的所述配置文件升级包传送至预设区域的方式包括：

将生成的所述配置文件升级包推送至所述终端，或者

将生成所述配置文件升级包存储到所述服务器的内存中，以供所述终端在所述内存中拉取所述配置文件升级包。

3.一种配置文件升级方法，应用于服务器，其特征在于，所述配置文件升级方法包括：

服务器确定待升级的配置文件类型，并提取出确定类型的配置文件名；

对提取的所述配置文件名添加版本号；

在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包；

将生成的所述配置文件升级包传送至预设区域，以便终端获取到所述配置文件升级包时，解析出下载地址，并下载对应的配置文件进行升级；

执行所述将生成的所述配置文件升级包传送至预设区域的同时，执行以下步骤：

所述服务器调用ZK网页应用程序开发框架创建节点，其中，节点名称为配置文件的标识信息；

基于所述ZK网页应用程序开发框架创建的节点启动API调用接口，以供所述API调用接口在配置文件升级包对应的配置哈希表中缓存所述配置文件升级包，便于所述服务器下次发布配置文件升级包时，从所述配置哈希表中获取缓存的所述配置文件升级包进行发布；

所述在检测到上传指令时，根据添加版本号的配置文件名生成包含下载地址的配置文件升级包的步骤包括：

在检测到上传指令时，根据添加版本号的配置文件名生成下载路径；

在配置文件表中保存机型名或应用名及分类信息，并根据配置文件表和下载路径生成下载地址。

4.如权利要求3所述的配置文件升级方法，其特征在于，所述将生成的所述配置文件升级包传送至预设区域的方式包括：

所述服务器将生成的所述配置文件升级包推送至所述终端，或者

所述服务器将生成所述配置文件升级包存储到所述服务器的内存中，以供所述终端在所述内存中拉取所述配置文件升级包。

Images