CN106547576A - 配置文件的获取方法及装置 - Google Patents

Abstract

本发明公开了一种配置文件的获取方法，包括步骤：向服务器发送配置文件请求；在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；解析所述配置文件，将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。本发明还公开一种配置文件的获取装置。本发明提供一种无须更新应用版本的方式，在后台完成新的展示信息或功能的推送。

Description

配置文件的获取方法及装置

技术领域

本发明涉及到计算机技术领域，特别涉及到配置文件的获取方法及装置。

背景技术

随着终端技术的不断发展，越来越多的终端进入人们的日常生活和工作当中，所述终端以手机为例。目前，手机上能实现的功能越来越多，例如，微信、QQ等即时通讯，浏览器、游戏等App应用也越来越多。在App有新的展示信息或新的功能需要推送时，需要向对应服务器下载升级包或者新功能安装包，并更新App的版本才能在手机上体验所述App新的展示信息或新的功能。

发明内容

本发明实施例提供一种配置文件的获取方法及装置，旨在解决现有的App应用在App有新的展示信息或新的功能需要推送时，需要向对应服务器下载升级包或者新功能安装包，并更新App的版本才能在手机上体验所述App新的展示信息或新的功能的问题。

为实现上述目的，本发明实施例提出一种配置文件的获取方法，包括步骤：

向服务器发送配置文件请求；

在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；

解析所述配置文件，将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。

为了实现上述目的，本发明实施例还进一步提出一种配置文件的获取装置，包括：

发送模块，用于向服务器发送配置文件请求；

获取模块，用于在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；

解析模块，用于解析所述配置文件；

更新模块，用于将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。

本发明通过在后台发起配置文件请求，通过配置文件ID和版本信息从服务器获取配置文件，解析配置文件，根据配置文件ID和版本信息将配置文件在后台更新至数据库中，以应用在前端运行时，调用更新后的配置文件完成应用的运行。提供一种无须更新应用版本的方式，在后台完成新的展示信息或功能的推送。

附图说明

图1为本发明实施例配置文件的获取装置所涉及的硬件架构示意图；

图2为本发明配置文件的获取方法的第一实施例的流程示意图；

图3为本发明配置文件的更新过程一实施例的流程示意图；

图4为本发明一实施例中配置文件合并过程的流程示意图；

图5为本发明一实施例中配置文件合并过程细化流程示意图；

图6为本发明配置文件的获取方法的第二实施例的流程示意图；

图7为本发明一实施例配置文件更新的框架示意图；

图8为本发明一实施例配置文件更新的细化流程示意图；

图9为本发明配置文件的获取装置的第一实施例的功能模块示意图；

图10为本发明配置文件的获取装置的第二实施例的功能模块示意图；

图11为图10中合并模块一实施例的细化功能模块示意图；

图12为图10中更新模块一实施例的细化功能模块示意图。

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

具体实施方式

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

本发明实施例的主要解决方案是：向服务器发送配置文件请求；在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；解析所述配置文件，将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。通过在后台发起配置文件请求，通过配置文件ID和版本信息从服务器获取配置文件，解析配置文件，根据配置文件ID和版本信息将配置文件在后台更新至数据库中，以应用在前端运行时，调用更新后的配置文件完成应用的运行。提供一种无须更新应用版本的方式，在后台完成新的展示信息或功能的推送。

由于现有的App应用在App有新的展示信息或新的功能需要推送时，需要向对应服务器下载升级包或者新功能安装包，并更新App的版本才能在手机上体验所述App新的展示信息或新的功能的问题

本发明实施例架构一配置文件的获取装置，该配置文件的获取装置通过在后台发起配置文件请求，通过配置文件ID和版本信息从服务器获取配置文件，解析配置文件，根据配置文件ID和版本信息将配置文件在后台更新至数据库中，以应用在前端运行时，调用更新后的配置文件完成应用的运行。提供一种无须更新应用版本的方式，在后台完成新的展示信息或功能的推送。

其中，本实施例配置文件的获取装置可以承载于PC端，也可以承载于手机、平板电脑等可以使用游戏等网络应用的电子终端。该配置文件的获取装置所涉及的硬件架构可以如图1所示。

图1示出了本发明实施例配置文件的获取装置所涉及的硬件架构。如图1所示，所述配置文件的获取装置所涉及的硬件包括：处理器301，例如CPU，网络接口304，用户接口303，存储器305，通信总线302。其中，通信总线302用于实现该配置文件获取中各组成部件之间的连接通信。用户接口303可以包括显示屏(Display)、键盘(Keyboard)、鼠标等组件，用于接收用户输入的信息，并将接收的信息发送至处理器305进行处理。显示屏可以为LCD显示屏、LED显示屏，也可以为触摸屏，用于显示配置文件的获取装置需要显示的数据，例如显示配置文件的获取、配置文件的更新等操作界面。可选用户接口303还可以包括标准的有线接口、无线接口。网络接口304可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器305可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器305可选的还可以是独立于前述处理器301的存储装置。如图1所示，作为一种计算机存储介质的存储器305中可以包括操作系统、网络通信模块、用户接口模块以及配置文件的获取程序。

在图1所示的配置文件的获取装置所涉及的硬件中，网络接口304主要用于连接应用平台，与应用平台进行数据通信；用户接口303主要用于连接客户端，与客户端进行数据通信，接收客户端输入的信息和指令；而处理器301可以用于调用存储器305中存储的配置文件的获取程序，并执行以下操作：

向服务器发送配置文件请求；

在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；

解析所述配置文件，将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。

进一步地，在一个实施例中，处理器301调用存储器305中存储的配置文件的获取程序可以执行以下操作：

在应用首次安装时，从应用本地配置文件夹中读取最新配置文件的ID、版本信息及配置文件；

将所读取的ID、版本信息及配置文件保存至所述数据库中。

进一步地，在一个实施例中，处理器301调用存储器305中存储的配置文件的获取程序可以执行以下操作：

在首次进行数据库的配置文件更新操作时，从数据库中读取从本地文件夹拷贝的配置文件的ID作为第二ID及读取所述已更新的配置文件的版本信息作为第二版本信息；

从应用本地配置文件夹中读取已保存的配置文件的ID作为第三ID和所述已保存的配置文件的版本信息作为第三版本信息；

合并所述第二ID和第三ID，并合并所述第二版本信息和所述第三版本信息，以生成合并后的ID和版本信息，将合并后的ID、版本信息及对应的配置文件更新至数据库。

进一步地，在一个实施例中，处理器301调用存储器305中存储的配置文件的获取程序可以执行以下操作：

判断所述第二版本信息的版本是否高于所述第三版本信息的版本；

在所述第二版本信息的版本低于所述第三版本信息的版本时，将所述第三版本信息对应的ID和版本作为合并后的版本，遍历应用本地配置文件夹，得到应用本地打包的配置文件列表；

将所述配置文件列表中的ID、版本信息及配置文件内容解析到所述数据库中。

进一步地，在一个实施例中，处理器301调用存储器305中存储的配置文件的获取程序可以执行以下操作：

在所述数据库中保存有与所述第一ID关联的配置文件时，确定所述数据库中与所述第一ID关联的配置文件的版本信息作为第四版本信息；

在所述第一版本信息的版本高于第四版本信息的版本时，将所述解析后的配置文件替换所述数据库中与所述第一ID关联的配置文件；

在所述第一版本信息的版本低于所述第四版本信息的版本时，不进行所述配置文件的更新操作；

在所述数据库中不存在与所述第一ID关联的配置文件时，直接将所述解析后的配置文件保存在所述数据库中。

基于上述硬件架构，提出本发明配置文件的获取方法实施例。

如图2所示，提出本发明一种配置文件的获取方法的第一实施例，所述配置文件的获取方法包括：

步骤S10，向服务器发送配置文件请求；

在本实施例中，提前预设一时间，所述时间可以是1天或7天等，根据用户需求和App的性能设置。在预设时间到达时，向服务器发送配置文件请求，优选为在后台发出所述配置文件请求。在本发明一实施例中，也可以是基于用户指令，根据用户指令向服务器发送配置文件请求。

在发出所述配置文件请求后，表示需要向所述服务器请求新的配置文件。所述配置文件请求由事先配置好的协议及/或格式构建一个请求数据包，所述数据包包括所对应请求的App的标识信息，所述标识信息包括但不限于App的名称。在本发明一实施例中，获取到配置文件的更新时间，在所述更新时间离当前时间达到一定时间(例如，2天或4天等)时，在后台向服务器发送配置文件请求；或在App的运行过程出现问题时，在后台向服务器发送配置文件请求。以上所列举出的触发在后台向服务器发送配置文件请求的方式仅仅为示例性的，本领域技术人员利用本发明的技术思想，根据其具体需求所提出的其它触发在后台向服务器发送配置文件请求的方式均在本发明的保护区间内，在此不进行一一穷举。

所述服务器在接收到所述配置文件请求时，找出所述App最新的配置文件，将所找出的最新的配置文件发送至发出配置文件请求所在的终端或所述APP所在的终端。所述配置文件可以以预先协定的协议和格式下发，所述配置文件可以以列表的形式下发，所述列表中包括但不限于配置文件ID，版本信息、内容类型及具体的内容。所述配置文件为CSC(common sever config，通用服务器配置文件)，所述配置文件的格式优选为JOSN(JavaScript ObjectNotation，一种轻量级的数据交换格式)。

步骤S20，在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；

在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，按照配置文件的ID拉取配置文件，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息。配置文件的ID用于区分不同的配置文件，例如，同一个应用存在多个配置文件，需要用不同的配置文件的ID进行区分；版本信息用于区分不同功能或不同展示信息的配置文件。所述服务器下发的配置文件可能是相对于已经下发的配置文件(即，已经在请求的终端中存在的配置文件，当前的请求只是对所述终端存在的配置文件进行更新)的更新，或者是全新的配置文件，在为全新的配置文件时，即下发的配置文件不为已有配置文件的更新或修改文件，所述全新的配置文件与下发的配置文件为不存在共同点的配置文件，所述请求的配置文件ID与已下发的配置文件的ID不同；在下发的配置文件为已保存配置文件的更新时，配置文件的ID不同但为关联的ID，配置文件的内容也为相互关联的内容，即所述配置文件为已有配置文件的更新文件或修改文件，内容中存在共同的部分，只是存在版本或者一些功能扩充的配置文件。

步骤S30，解析所述配置文件，将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。

在接收到服务器下发的配置文件后，解析所述配置文件，优选为解析所述配置文件中的配置内容，将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。在本发明一实施例中，所述配置文件为CSC文件，一个CSC文件为一个JOSN文件，加载在终端的应用客户端需要拉取该文件进行解析，并在客户端做一些信息展示，当客户端版本发布后，只需在后台更新该JOSN文件，客户端会自动拉取最新的CSC文件并控制一些逻辑行为，从而达到不发布客户端版本就可以运营应用的能力。

本实施例通过在后台发起配置文件请求，通过配置文件ID和版本信息从服务器获取配置文件，解析配置文件，根据配置文件ID和版本信息将配置文件在后台更新至数据库中，以应用在前端运行时，调用更新后的配置文件完成应用的运行。提供一种无须更新应用版本的方式，在后台完成新的展示信息或功能的推送。

可选地，参考图3，首次进行配置文件的更新时，更新过程包括：

步骤S00，在应用安装后首次进行配置文件更新时，从数据库中读取已更新的配置文件的ID作为第二ID及读取所述已更新的配置文件的版本信息作为第二版本信息；

步骤S01，从应用本地配置文件夹中读取已保存的配置文件的ID作为第三ID及读取所述已保存的配置文件的版本信息作为第三版本信息；

步骤S02，合并所述第二ID和第三ID，并合并所述第二版本信息和所述第三版本信息，以生成合并后的ID和版本信息，将合并后的ID、版本信息及对应的配置文件更新至数据库。

在应用首次安装时，从应用本地配置文件夹中读取最新配置文件的ID、版本信息及配置文件；将所读取的ID、版本信息及配置文件保存至所述数据库中。具体的，App首次安装或者用户选择清除数据之后，DB内应该为空，将配置文件夹中的配置文件内容解析到DB中。在应用首次安装时，将配置文件从服务器下载至本地配置文件夹，即，应用本地已保存的配置文件保存在应用本地的配置文件夹中，所述配置文件夹中保存的配置文件以预先协定的格式打包，作为配置文件打包信息。从服务器获取到的配置文件先保存在所述配置文件夹中，然后应用安装后，将配置文件从所述本地配置文件夹发送至数据库中，所述数据库在应用安装后建立。

在应用安装后，首次进行配置文件的更新时，更新过程包括：在进行配置文件的更新过程中，需要将数据库中的配置文件与配置文件夹中的配置文件进行版本的比较，以判定哪个保存的配置文件的最新。具体的，从数据库中读取已更新的配置文件的ID作为第二ID和所述已更新的配置文件的版本信息作为第二版本信息；从应用本地配置文件夹中读取已保存的配置文件的ID作为第三ID和所述已保存的配置文件的版本信息作为第三版本信息；合并所述第二ID和第三ID，并合并所述第二版本信息和所述第三版本信息，以生成合并后的ID和版本信息，将合并后的ID、版本信息及对应的配置文件更新至数据库。

具体的，参考图4，合并的过程包括：步骤S021，判断所述第二版本信息的版本是否高于所述第三版本信息的版本；

步骤S022，在所述第二版本信息的版本低于所述第三版本信息的版本时，将所述第三版本信息对应的ID和版本作为合并后的版本，遍历应用本地配置文件夹，得到应用本地打包的配置文件列表；

步骤S023，将所述配置文件列表中的ID、版本信息及配置文件内容解析到所述数据库中。

具体的，参考图5，所述合并示意图包括：

1、从DB中读取上一次合并的App版本号；2、判断App当前版本号是否比DB中的新；3、若是，则遍历assets/csc文件夹中的*.csc文件；4、获取本地打包的List(ID、版本信息和配置文件内容)；5、更新ID、版本信息至DB，并解析配置文件内容更新到DB。

App升级之后，如果Assets(配置文件夹)里的某个CSC版本号比DB里的新，则更新该CSC到DB；每次去Server(服务器)请求更新信息后，如果拉回来CSC成功，则更新版本号及内容到DB；如果CSC有更新，那么老版本会拉取更新并使用最新的配置。如果有新版本打包了这个更新，我们先安装新版本(新的CSC信息会写入DB)，再覆盖安装旧版本，旧版本会沿用新版本的CSC——因为只要CSC打包在安装包，说明这个CSC是一个全量更新，即使不是新版本引入该CSC,旧版本的更新机制肯定也会保证触发更新，所以旧版本使用新版本打包的CSC，没有什么问题。

本实施例通过配置文件ID和版本信息从服务器获取到配置文件更新至数据库中，使得更新过程更加准确。

在本发明其他实施例中，在后续的配置文件的更新操作中，只需从服务器下载配置文件到数据库，进行数据库配置文件版本的比较即可，在数据库中服务器请求的配置文件对应的版本低于服务器的版本时，将服务器的配置文件更新至数据库；在高于服务器的版本时，不更新配置文件至数据库，只通过服务器和数据库完成配置文件的更新过程，而不再从本地配置文件夹中读取配置文件。

进一步地，基于上述配置文件的获取方法的第一实施例，提出本发明配置文件的获取方法的第二实施例。如图6所示，在所述更新数据库配置文件的过程不为首次更新操作时，所述步骤S30可以包括：

步骤S31，在所述数据库中保存有与所述第一ID关联的配置文件时，确定所述数据库中与所述第一ID的配置文件关联的版本信息作为第四版本信息；

步骤S32，在所述第一版本信息的版本高于第四版本信息的版本时，将所述解析后的配置文件替换所述数据库中与所述第一ID关联的配置文件；

步骤S33，在所述数据库中不存在与所述第一ID关联的配置文件时，直接将所述解析后的配置文件保存在所述数据库中。

在本实施例中，在后台从服务器获取到配置文件后，即获取到CSC打包文件后，判断在DB(DataBase，数据库)中是否保存有与所述第一ID关联的配置文件，即，所述保存有的配置文件为所述第一ID的配置文件的高或低版本的配置文件，所述保存有的配置文件ID与所述第一ID不同，用以区分不同的配置文件，即使配置文件为关联的内容，但ID也不同。所述关联的内容为所述两个配置文件的内容存在相同的部分，或者其中一个配置文件的内容为另一个配置文件的功能扩展或数据的升级。在分配配置文件ID时，会提前判断所述配置文件是否为已下发配置文件的高版本或低版本的配置文件，若是，则将所述配置文件与对应高或低版本的配置文件的ID和内容设置为相关联的配置文件，例如，设置关联的标签，所述标签为字符串或数字等。

在所述数据库中存在与所述第一ID关联的配置文件时，确定所述数据库中与所述第一ID关联的配置文件的版本信息作为第四版本信息；判断所述第一版本信息的版本是否高于第四版本信息的版本，例如，判断是否存在新的功能的配置文件或新的展示信息的配置文件。在本发明一实施例中，所述判断过程包括：根据更新时间判断版本信息的高低，或者根据版本信息的版本标识来判断版本信息的高低。

在所述第一版本信息的版本高于第四版本信息的版本时，将所述解析后的配置文件替换所述数据库中与所述第一ID关联的配置文件，即将高版本的配置文件更新至DB中；在所述第一版本信息的版本低于所述第四版本信息的版本时，不进行所述配置文件的更新操作；在所述数据中不存在与所述第一ID关联的配置文件时，直接将所述解析后的配置文件保存在所述数据库中。

为了更好的描述本发明实施例，参考图7，更新架构包括：

管理后台和移动App，所述移动App端包括本地数据库和打包CSC文件。

基于图7中的架构，参考图8，整个更新过程包括：

100、从DB读取ID、版本信息，读取本地配置文件夹中的打包信息；200、两份信息合并得到统一的ID、版本号(即得到同一ID最新的版本号作为统一的版本号)；300、取得Map(包括配置文件ID、版本信息Version)；400、发包去Server查询更新；500、返回有更新的List(ID，Version，ContentType内容类型，Content)；600、按ID拉取配置文件；700、更新ID、Version至DB，解析Content字段并更新至DB。

上述第一和第二实施例的配置文件的获取方法的执行主体均可以为终端。更进一步地，该配置文件的获取方法可以由安装在终端上的客户端配置文件的获取程序实现，其中，该终端包括但不限于手机、pad、笔记本电脑等。

对应地，提出本发明配置文件的获取装置的第一实施例。参考图9，所述配置文件的获取装置包括发送模块10、获取模块20、解析模块30及更新模块40。

所述发送模块10，用于向服务器发送配置文件请求；

在本实施例中，提前预设一时间，所述时间可以是1天或7天等，根据用户需求和App的性能设置。在预设时间到达时，在后台向服务器发送配置文件请求，优选为在后台发出所述配置文件请求。在本发明一实施例中，也可以是基于用户指令，根据用户指令向服务器发送配置文件请求。

在发出所述配置文件请求后，表示需要向所述服务器请求新的配置文件。所述配置文件请求由事先配置好的协议及/或格式构建一个请求数据包，所述数据包包括所对应请求的App的标识信息，所述标识信息包括但不限于App的名称。在本发明一实施例中，获取到配置文件的更新时间，在所述更新时间离当前时间达到一定时间(例如，2天或4天等)时，在后台向服务器发送配置文件请求；或在App的运行过程出现问题时，在后台向服务器发送配置文件请求。以上所列举出的触发在后台向服务器发送配置文件请求的方式仅仅为示例性的，本领域技术人员利用本发明的技术思想，根据其具体需求所提出的其它触发在后台向服务器发送配置文件请求的方式均在本发明的保护区间内，在此不进行一一穷举。

所述服务器在接收到所述配置文件请求时，找出所述App最新的配置文件，将所找出的最新的配置文件发送至发出配置文件请求所在的终端或所述APP所在的终端。所述配置文件可以以预先协定的协议和格式下发，所述配置文件可以以列表的形式下发，所述列表中包括但不限于配置文件ID，版本信息、内容类型及具体的内容。所述配置文件为CSC(common sever config，通用服务器配置文件)，所述配置文件的格式优选为JOSN(JavaScript ObjectNotation，一种轻量级的数据交换格式)。

所述获取模块20，用于在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；

在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，按照配置文件的ID拉取配置文件，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息。配置文件的ID用于区分不同的配置文件，例如，同一个应用存在多个配置文件，需要用不同的配置文件的ID进行区分；版本信息用于区分不同功能或不同展示信息的配置文件。所述服务器下发的配置文件可能是相对于已经下发的配置文件(即，已经在请求的终端中存在的配置文件，当前的请求只是对所述终端存在的配置文件进行更新)的更新，或者是全新的配置文件，在为全新的配置文件时，即下发的配置文件不为已有配置文件的更新或修改文件，所述全新的配置文件与下发的配置文件为不存在共同点的配置文件，所述请求的配置文件ID与已下发的配置文件的ID不同；在下发的配置文件为已保存配置文件的更新时，配置文件的ID不同但为关联的ID，配置文件的内容也为相互关联的内容，即所述配置文件为已有配置文件的更新文件或修改文件，内容中存在共同的部分，只是存在版本或者一些功能扩充的配置文件。

所述解析模块30，用于解析所述配置文件；

所述更新模块40，用于将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。

在接收到服务器下发的配置文件后，解析所述配置文件，优选为解析所述配置文件中的配置内容，将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。在本发明一实施例中，所述配置文件为CSC文件，一个CSC文件为一个JOSN文件，加载在终端的应用客户端需要拉取该文件进行解析，并在客户端做一些信息展示，当客户端版本发布后，只需在后台更新该JOSN文件，客户端会自动拉取最新的CSC文件并控制一些逻辑行为，从而达到不发布客户端版本就可以运营应用的能力。

本实施例通过在后台发起配置文件请求，通过配置文件ID和版本信息从服务器获取配置文件，解析配置文件，根据配置文件ID和版本信息将配置文件在后台更新至数据库中，以应用在前端运行时，调用更新后的配置文件完成应用的运行。提供一种无须更新应用版本的方式，在后台完成新的展示信息或功能的推送。

可选地，提出本发明配置文件的获取装置的第二实施例。参考图10，所述配置文件的获取装置还包括读取模块50、合并模块60及保存模块70，

所述读取模块50，用于在应用安装后首次进行配置文件更新时，从数据库中读取已更新的配置文件的ID作为第二ID及读取所述已更新的配置文件的版本信息作为第二版本信息；还用于

从应用本地配置文件夹中读取已保存的配置文件的ID作为第三ID及读取所述已保存的配置文件的版本信息作为第三版本信息；

所述合并模块60，用于合并所述第二ID和第三ID，并合并所述第二版本信息和所述第三版本信息，以生成合并后的ID和版本信息，将合并后的ID、版本信息及对应的配置文件更新至数据库。

所述读取模块50，还用于在应用首次安装时，从应用本地配置文件夹中读取最新配置文件的ID、版本信息及配置文件；

所述保存模块70，用于将所读取的ID、版本信息及配置文件保存至所述数据库中。

具体的，App首次安装或者用户选择清除数据之后，DB内应该为空，将配置文件夹中的配置文件内容解析到DB中。在应用首次安装时，将配置文件从服务器下载至本地配置文件夹，即，应用本地已保存的配置文件保存在应用本地的配置文件夹中，所述配置文件夹中保存的配置文件以预先协定的格式打包，作为配置文件打包信息。从服务器获取到的配置文件先保存在所述配置文件夹中，然后应用安装后，将配置文件从所述本地配置文件夹发送至数据库中，所述数据库在应用安装后建立。

在应用安装后，首次进行配置文件的更新时，更新过程包括：在进行配置文件的更新过程中，需要将数据库中的配置文件与配置文件夹中的配置文件进行版本的比较，以判定哪个保存的配置文件的最新。具体的，从数据库中读取已更新的配置文件的ID作为第二ID和所述已更新的配置文件的版本信息作为第二版本信息；从应用本地配置文件夹中读取已保存的配置文件的ID作为第三ID和所述已保存的配置文件的版本信息作为第三版本信息；合并所述第二ID和第三ID，并合并所述第二版本信息和所述第三版本信息，以生成合并后的ID和版本信息，将合并后的ID、版本信息及对应的配置文件更新至数据库。

具体的，参考图11，所述合并模块60包括：判断单元61和合并单元62。

所述判断单元61，用于判断所述第二版本信息的版本是否高于所述第三版本信息的版本；

所述合并单元62，用于在所述第二版本信息的版本低于所述第三版本信息的版本时，将所述第三版本信息对应的ID和版本作为合并后的版本，遍历应用本地配置文件夹，得到应用本地打包的配置文件列表；

所述更新模块40，还用于将所述配置文件列表中的ID、版本信息及配置文件内容解析到所述数据库中。

具体的，参考图5，所述合并示意图包括：

1、从DB中读取上一次合并的App版本号；2、判断App当前版本号是否比DB中的新；3、若是，则遍历assets/csc文件夹中的*.csc文件；4、获取本地打包的List(ID、版本信息和配置文件内容)；5、更新ID、版本信息至DB，并解析配置文件内容更新到DB。

App升级之后，如果Assets(配置文件夹)里的某个CSC版本号比DB里的新，则更新该CSC到DB；每次去Server(服务器)请求更新信息后，如果拉回来CSC成功，则更新版本号及内容到DB；如果CSC有更新，那么老版本会拉取更新并使用最新的配置。如果有新版本打包了这个更新，我们先安装新版本(新的CSC信息会写入DB)，再覆盖安装旧版本，旧版本会沿用新版本的CSC——因为只要CSC打包在安装包，说明这个CSC是一个全量更新，即使不是新版本引入该CSC,旧版本的更新机制肯定也会保证触发更新，所以旧版本使用新版本打包的CSC，没有什么问题。

本实施例通过配置文件ID和版本信息从服务器获取到配置文件更新至数据库中，使得更新过程更加准确。

在本发明其他实施例中，在后续的配置文件的更新操作中，只需从服务器下载配置文件到数据库，进行数据库配置文件版本的比较即可，在数据库中服务器请求的配置文件对应的版本低于服务器的版本时，将服务器的配置文件更新至数据库；在高于服务器的版本时，不更新配置文件至数据库，只通过服务器和数据库完成配置文件的更新过程，而不再从本地配置文件夹中读取配置文件。

进一步地，参考图12，所述更新模块40包括：确定单元41和更新单元42。

所述确定单元41，用于在所述数据库中保存有与所述第一ID关联的配置文件时，确定所述数据库中与所述第一ID的配置文件关联的版本信息作为第四版本信息；

所述更新单元42，用于在所述第一版本信息的版本高于第四版本信息的版本时，将所述解析后的配置文件替换所述数据库中与所述第一ID关联的配置文件；还用于

在所述数据库中不存在与所述第一ID关联的配置文件时，直接将所述解析后的配置文件保存在所述数据库中。

在本实施例中，在后台从服务器获取到配置文件后，即获取到CSC打包文件后，判断在DB(DataBase，数据库)中是否保存有与所述第一ID关联的配置文件，即，所述保存有的配置文件为所述第一ID的配置文件的高或低版本的配置文件，所述保存有的配置文件ID与所述第一ID不同，用以区分不同的配置文件，即使配置文件为关联的内容，但ID也不同。所述关联的内容为所述两个配置文件的内容存在相同的部分，或者其中一个配置文件的内容为另一个配置文件的功能扩展或数据的升级。在分配配置文件ID时，会提前判断所述配置文件是否为已下发配置文件的高版本或低版本的配置文件，若是，则将所述配置文件与对应高或低版本的配置文件的ID和内容设置为相关联的配置文件，例如，设置关联的标签，所述标签为字符串或数字等。

在所述数据库中存在与所述第一ID关联的配置文件时，确定所述数据库中与所述第一ID关联的配置文件的版本信息作为第四版本信息；判断所述第一版本信息的版本是否高于第四版本信息的版本，例如，判断是否存在新的功能的配置文件或新的展示信息的配置文件。在本发明一实施例中，所述判断过程包括：根据更新时间判断版本信息的高低，或者根据版本信息的版本标识来判断版本信息的高低。

在所述第一版本信息的版本高于第四版本信息的版本时，将所述解析后的配置文件替换所述数据库中与所述第一ID关联的配置文件，即将高版本的配置文件更新至DB中；在所述第一版本信息的版本低于所述第四版本信息的版本时，不进行所述配置文件的更新操作；在所述数据中不存在与所述第一ID关联的配置文件时，直接将所述解析后的配置文件保存在所述数据库中。

为了更好的描述本发明实施例，参考图7，更新架构包括：

管理后台和移动App，所述移动App端包括本地数据库和打包CSC文件。

基于图7中的架构，参考图8，整个更新过程包括：

100、从DB读取ID、版本信息，读取本地配置文件夹中的打包信息；200、两份信息合并得到统一的ID、版本号(即得到同一ID最新的版本号作为统一的版本号)；300、取得Map(包括配置文件ID、版本信息Version)；400、发包去Server查询更新；500、返回有更新的List(ID，Version，ContentType，Content)；600、按ID拉取配置文件；700、更新ID、Version至DB，解析Content字段并更新至DB。

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

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

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

Claims (10)

1.一种配置文件的获取方法，其特征在于，包括步骤：

向服务器发送配置文件请求；

在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；

解析所述配置文件，将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。

2.如权利要求1所述的配置文件的获取方法，其特征在于，所述配置文件的获取方法还包括：

在应用首次安装时，从应用本地配置文件夹中读取最新配置文件的ID、版本信息及配置文件；

将所读取的ID、版本信息及配置文件保存至所述数据库中。

3.如权利要求2所述的配置文件的获取方法，其特征在于，在所述向服务器发送配置文件请求的步骤之前，还包括：

在首次进行数据库的配置文件更新操作时，从数据库中读取从本地文件夹拷贝的配置文件的ID作为第二ID及读取所述已更新的配置文件的版本信息作为第二版本信息；

从应用本地配置文件夹中读取已保存的配置文件的ID作为第三ID和所述已保存的配置文件的版本信息作为第三版本信息；

合并所述第二ID和第三ID，并合并所述第二版本信息和所述第三版本信息，以生成合并后的ID和版本信息，将合并后的ID、版本信息及对应的配置文件更新至数据库。

4.如权利要求3所述的配置文件的获取方法，其特征在于，所述合并所述第二ID和第三ID，并合并所述第二版本信息和所述第三版本信息，以生成合并后的ID和版本信息，将合并后的ID、版本信息及对应的配置文件更新至数据库的步骤包括：

判断所述第二版本信息的版本是否高于所述第三版本信息的版本；

在所述第二版本信息的版本低于所述第三版本信息的版本时，将所述第三版本信息对应的ID和版本作为合并后的版本，遍历应用本地配置文件夹，得到应用本地打包的配置文件列表；

将所述配置文件列表中的ID、版本信息及配置文件内容解析到所述数据库中。

5.如权利要求1至4任一项所述的配置文件的获取方法，其特征在于，在所述配置文件的更新操作不是安装后的首次更新操作时，所述将解析后的配置文件按照所述第一ID及所述第一版本信息更新至数据库中的步骤包括：

在所述数据库中保存有与所述第一ID关联的配置文件时，确定所述数据库中与所述第一ID关联的配置文件的版本信息作为第四版本信息；

在所述第一版本信息的版本高于第四版本信息的版本时，将所述解析后的配置文件替换所述数据库中与所述第一ID关联的配置文件；

在所述第一版本信息的版本低于所述第四版本信息的版本时，不进行所述配置文件的更新操作；

在所述数据库中不存在与所述第一ID关联的配置文件时，直接将所述解析后的配置文件保存在所述数据库中。

6.一种配置文件的获取装置，其特征在于，包括：

发送模块，用于向服务器发送配置文件请求；

获取模块，用于在接收到所述服务器下发的与所述配置文件请求对应的配置文件后，获取所述配置文件的ID作为第一ID及所述配置文件的版本信息作为第一版本信息；

解析模块，用于解析所述配置文件；

更新模块，用于将解析后的配置文件按照所述第一ID及第一版本信息更新至数据库中，以供在运行所述配置文件对应的应用时，从所述数据库中调用更新后的配置文件完成所述应用的运行。

7.如权利要求6所述的配置文件的获取装置，其特征在于，所述配置文件的获取装置还包括：

读取模块，用于在应用首次安装时，从应用本地配置文件夹中读取最新配置文件的ID、版本信息及配置文件；

保存模块，用于将所读取的ID、版本信息及配置文件保存至所述数据库中。

8.如权利要求7所述的配置文件的获取装置，其特征在于，所述配置文件的获取装置还包括：

读取模块，用于在首次进行数据库的配置文件更新操作时，从数据库中读取从本地文件夹拷贝的配置文件的ID作为第二ID及读取所述已更新的配置文件的版本信息作为第二版本信息；还用于

从应用本地配置文件夹中读取已保存的配置文件的ID作为第三ID和所述已保存的配置文件的版本信息作为第三版本信息；

合并模块，用于合并所述第二ID和第三ID，并合并所述第二版本信息和所述第三版本信息，以生成合并后的ID和版本信息；

所述更新模块，还用于将合并后的ID、版本信息及对应的配置文件更新至数据库。

9.如权利要求8所述的配置文件的获取装置，其特征在于，所述合并模块包括：

判断单元，用于判断所述第二版本信息的版本是否高于所述第三版本信息的版本；

合并单元，用于在所述第二版本信息的版本低于所述第三版本信息的版本时，将所述第三版本信息对应的ID和版本作为合并后的版本，遍历应用本地配置文件夹，得到应用本地打包的配置文件列表；

所述更新模块，还用于将所述配置文件列表中的ID、版本信息及配置文件内容解析到所述数据库中。

10.如权利要求6至9任一项所述的配置文件的获取装置，其特征在于，所述更新模块包括：

确定单元，用于在所述数据库中保存有与所述第一ID关联的配置文件时，确定所述数据库中与所述第一ID关联的配置文件的版本信息作为第二版本信息；

更新单元，用于在所述第一版本信息的版本高于第二版本信息的版本时，将所述解析后的配置文件替换所述数据库中与所述第一ID关联的配置文件；还用于

在所述数据库中不存在与所述第一ID关联的配置文件时，直接将所述解析后的配置文件保存在所述数据库中。