合并程序代码的方法及装置与流程

本发明涉及程序开发领域，特别涉及一种合并程序代码的方法及装置。

背景技术：

在应用程序的开发过程中，为了能让应用程序被灵活地应用于多种应用场景，往往会在程序代码中设计很多的配置项，来让用户可以通过修改这些配置项的数值来实现自身使用时的最优化配置。而对于一个复杂的应用程序，往往由多位开发人员各自编写一个或多个模块的程序代码，并在编写过程中各自定义所需要使用的配置项。由于开发人员在编写过程中一般无法知晓自己规定的配置项的名称在其他部分的程序代码中是否已经被使用，所以在将各模块的程序代码进行合并后，很容易出现由不同开发人员所定义的配置项名称重复而产生的程序错误，此后往往需要再花费大量的开发资源去进行相应的纠错过程，严重影响了开发效率。

技术实现要素：

针对现有技术中的缺陷，本发明提供一种合并程序代码的方法及装置，可以解决由不同开发人员各自定义的配置项容易命名冲突的问题。

第一方面，本发明提供一种合并程序代码的方法，包括：

合并一个以上的模块的程序代码时，获取与每一所述模块对应的配置定义文件，所述配置定义文件中以所对应的模块的模块名称为顶级节点的第一属性定义了至少一个在程序代码中所使用的配置项，所述配置项的名称由顶级节点的第一属性和顶级节点之下的至少一级的子节点的第一属性依序组成；

将所述一个以上的模块各自对应的配置定义文件合并为全局配置定义文件，所有所述配置定义文件中的顶级节点在所述全局配置定义文件中相互并列。

在一种可能的实现方式中，所述方法还包括：

根据所述全局配置定义文件生成配置项说明文件，所述配置项说明文件包含至少一个配置项的名称和说明字符，所述说明字符是所述全局配置定义文件中与所述配置项对应的最下级的子节点的第二属性。

在一种可能的实现方式中，所述根据所述全局配置定义文件生成配置项说明文件，包括：

创建文本文件；

遍历所述全局配置定义文件中的最下级的子节点，以在历经任一最下级的子节点时依次执行下述步骤：

组合当前子节点的第一属性、当前子节点之上的所有子节点的第一属性，以及当前子节点之上的顶级节点的第一属性，以按照预置文本格式向所述文本文件中写入当前子节点所对应的配置项的名称；

获取当前子节点的第二属性，以按照预置文本格式向所述文本文件中写入当前子节点所对应的配置项的说明字符。

在一种可能的实现方式中，所述方法还包括：

根据所述全局配置定义文件生成用户配置文件，所述用户配置文件包含至少一个配置项的名称和配置项值，所述配置项值是所述全局配置定义文件中与所述配置项对应的最下级的子节点的第三属性。

在一种可能的实现方式中，所述方法还包括：

在合并后的程序代码中，将用于返回配置项值的代码中的源文件地址变更为所述用户配置文件的文件地址。

第二方面，本发明还提供了一种合并程序代码的装置，包括：

获取单元，用于在合并一个以上的模块的程序代码时，获取与每一所述模块对应的配置定义文件，所述配置定义文件中以所对应的模块的模块名称为顶级节点的第一属性定义了至少一个在程序代码中所使用的配置项，所述配置项的名称由顶级节点的第一属性和顶级节点之下的至少一级的子节点的第一属性依序组成；

合并单元，用于将所述一个以上的模块各自对应的配置定义文件合并为全局配置定义文件，所有所述配置定义文件中的顶级节点在所述全局配置定义文件中相互并列。

在一种可能的实现方式中，所述装置还包括：

第一生成单元，用于根据所述全局配置定义文件生成配置项说明文件，所述配置项说明文件包含至少一个配置项的名称和说明字符，所述说明字符是所述全局配置定义文件中与所述配置项对应的最下级的子节点的第二属性。

在一种可能的实现方式中，所述第一生成单元包括：

创建子单元，用于创建文本文件；

遍历子单元，用于遍历所述全局配置定义文件中的最下级的子节点，以在历经任一最下级的子节点时依次执行下述步骤：

组合当前子节点的第一属性、当前子节点之上的所有子节点的第一属性，以及当前子节点之上的顶级节点的第一属性，以按照预置文本格式向所述文本文件中写入当前子节点所对应的配置项的名称；

获取当前子节点的第二属性，以按照预置文本格式向所述文本文件中写入当前子节点所对应的配置项的说明字符。

在一种可能的实现方式中，所述装置还包括：

第二生成单元，用于根据所述全局配置定义文件生成用户配置文件，所述用户配置文件包含至少一个配置项的名称和配置项值，所述配置项值是所述全局配置定义文件中与所述配置项对应的最下级的子节点的第三属性。

在一种可能的实现方式中，所述装置还包括：

变更单元，用于在合并后的程序代码中，将用于返回配置项值的代码中的源文件地址变更为所述用户配置文件的文件地址。

由上述技术方案可知，本发明通过在各配置项的名称的最前面添加模块名称，可以将不同模块的程序代码中的配置项名称通过模块名称相互区分开，使得合并后的程序代码不容易出现配置项之间命名冲突的问题，从而可以节省为发现和调试其所导致的程序错误所花费的开发资源，有助于开发效率的提升。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一个实施例中一种合并程序代码的方法的流程图；

图2是本发明又一实施例中一种合并程序代码的方法的流程图；

图3是本发明一个实施例中一种生成配置项说明文件的流程图；

图4是本发明一个实施例中一种合并程序代码的装置的结构框图；

图5是本发明一个实施例中一种合并程序代码的终端结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

图1是本发明一个实施例中一种合并程序代码的方法的流程图，如图1所示，该方法包括以下步骤：

步骤101：合并一个以上的模块的程序代码时，获取与每一所述模块对应的配置定义文件。

其中，所述配置定义文件中以所对应的模块的模块名称为顶级节点的第一属性定义了至少一个在程序代码中所使用的配置项，所述配置项的名称由顶级节点的第一属性和顶级节点之下的至少一级的子节点的第一属性依序组成。例如，配置定义文件包含具有高低层级之分的一个顶级节点和至少一个子节点，形成文件内部的层级结构——顶级节点处在最高层级，比最高层级低一级的所有子节点(简称“一级子节点”)均从属于顶级节点，比最高层级低两级的所有子节点(简称“二级子节点”)中的每一个均从属于一个一级子节点，比最高层级低三级的所有子节点(简称“三级子节点”)中的每一个均从属于一个二级子节点，依此类推。顶级节点和每个子节点均具有各自的第一属性，从顶级节点开始到没有从属子节点的子节点为止形成一条从属关系链，每条从属关系链中顶级节点和所有子节点的第一属性依序组成一个配置项的名称。作为一种示例，一种配置定义文件的内部结构如下表1所示。

表1配置定义文件的内部结构示例

如表1所示，上述配置定义文件中包含一个顶级节点、三个一级子节点和三个二级子节点，其中三个一级子节点从属于顶级节点，而序号为3和4的两个二级子节点从属于序号为2的一级子节点，序号为6的二级子节点单独从属于序号为5的一级子节点，序号为7的一级子节点没有从属子节点。可以看出，上述配置定义文件中包含四条从属关系链，每条从属关系链对应于一个配置项，每条从属关系链中顶级节点和所有子节点的第一属性依序组成一个配置项的名称。比如，一条从属关系链顶级节点开始经过序号为2的一级子节点，终止于序号为3的二级子节点，所对应的配置项的名称由顶级节点的第一属性“store1”、一级子节点的第一属性“index”，以及二级子节点的第一属性“config1”以下划线“_”为间隔依序组成为“store1_index_config1”。按照相同方式，可推知四个配置项的名称分别为“store1_index_config1”、“store1_index_config2”、“store1_data1_config1”和“store1_data2”。此外，根据顶级节点的第一属性“store1”，可知表1示出的配置定义文件与模块名称为“store1”的模块对应。

可以看出的是，为了使同一配置定义文件内的配置项的名称彼此区分开，从属于顶级节点的各个一级子节点之间须具有不同的第一属性(比如表1中序号分别为5和7的一级子节点分别具有不同的第一属性“data1”和“data2”)，而从属于同一子节点的各个子节点之间须具有不同的第一属性(比如表1中序号分别为3和5的二级子节点分别具有不同的第一属性“config1”和“config2”)。而从属于不同子节点的同一层级的子节点之间则可以具有相同的第一属性(比如序号分别为3和6的二级子节点具有相同的第一属性“config1”)。此外，同一配置文件所定义的各个配置项的名称所包含的子节点的第一属性的数量可以不同，比上例中一个配置项的名称“store1_data2”仅包含一个一级子节点的第一属性，而其他配置项的名称则包含两个子节点的第一属性。当然，在其他可能的实现方式中，配置定义文件还可以仅包含一级的子节点、或者包含两级以上的子节点(即一个或一个以上的二级子节点之下还有至少一级的从属子节点)，本发明对此不做限制。

步骤102：将所述一个以上的模块各自对应的配置定义文件合并为全局配置定义文件。

其中，所有所述配置定义文件中的顶级节点在所述全局配置定义文件中相互并列。需要说明的是，配置定义文件中的顶级节点并不需要在全局配置定义文件中处于最高级别，比如可使各个配置定义文件中的顶级节点均从属于全局配置定义文件中的根节点，本发明对此不做限制。

可以看出的是，不同模块显然会具有不同的模块名称，因此本实施例中各个模块的程序代码中出现的配置项的名称必然会通过模块名称相互区分开，使得合并后的程序代码不容易出现配置项之间命名冲突的问题，从而可以节省为发现和调试其所导致的程序错误所花费的开发资源，有助于开发效率的提升。

需要说明的是，本实施例中的方法可以应用于任意一种包括处理器的电子设备，例如计算机、智能手机、平板电脑、笔记本电脑、个人数字助理(Personal Digital Assistant，PDA)等等。

还需要说明的是，本实施例中的配置定义文件可以由开发人员在相应的编写规范的指导下编写，也可以由根据开发人员输入的相应形式的配置项名称通过字符串处理自动生成，本发明对此不做限制。相对应的，获取与每一所述模块对应的配置定义文件的方式可以是来自于开发人员所使用的终端设备的发送，也可以是来自于同一电子设备内的自动生成单元的输出，还可以来自于其他设备内的自动生成单元的生成和发送等等，本发明对此不做限制。

可以理解的是，在将每个模块各自对应的配置定义文件合并为全局配置定义文件之后，由这些模块所组成的应用程序的所有配置项就被统一整合到了全局配置定义文件当中。从而，与配置项有关的信息就可以一并添加或者链接到全局配置定义文件的对应部分，使得任何人都可以通过全局配置定义文件了解到应用程序中所有配置项的相关信息。

作为一种示例，图2是本发明又一实施例中一种合并程序代码的方法的流程图。参见图2，该方法在上述步骤101和步骤102的基础之上，还包括：

步骤103：根据全局配置定义文件生成配置项说明文件。

其中，配置项说明文件包含至少一个配置项的名称和说明字符，说明字符是全局配置定义文件中与配置项对应的最下级的子节点的第二属性。需要说明的是，本文中所述的与配置项对应的最下级的子节点即与配置项对应的所有子节点中没有从属子节点的子节点，也即配置项所对应的从属关系链中的最后一个子节点。

步骤104：根据全局配置定义文件生成用户配置文件。

其中，用户配置文件包含至少一个配置项的名称和配置项值，配置项值是全局配置定义文件中与配置项对应的最下级的子节点的第三属性。

步骤105：在合并后的程序代码中，将用于返回配置项值的代码中的源文件地址变更为用户配置文件的文件地址。

作为一种示例，一种全局配置定义文件的内部结构如下表2所示。

表2全局配置定义文件的内部结构示例

表2所示的全局配置定义文件包含两个相互并列的顶级节点，可见该全局配置定义文件来自于模块名称为“store1”所对应的配置定义文件和模块名称为“store2”所对应的配置定义文件的合并。其中，序号为1的顶级节点之下存在两个从属于顶级节点的一级子节点，和两个从属于序号为2的一级子节点的二级子节点，定义了名称分别为“store1_index_config1”、“store1_index_config2”和“store1_data1”的三个配置项；而序号为6的顶级节点之下只存在一个从属于顶级节点的一级子节点，定义了名称为“store2_data1”的配置项。可以看出，由于顶级节点的第一属性不同，因此即使一级子节点的第一属性相同，也不会使两个模块所对应的配置项产生命名冲突。

根据表2所示的全局配置定义文件，上述步骤103中所生成的配置项说明文件示例如下：

#配置项说明

#store1_index_config1——最大内存占用量

#store1_index_config2——内存溢出时是否警告

#store1_data1——数据抽样比率

#store2_data1——数据单元所占字节数

#结束

可以看出，该配置项说明文件包含全局配置定义文件中的四个配置项的名称，以及每个配置项的说明字符。其中，配置项的说明字符是全局配置定义文件中与配置项对应的最下级的子节点的第二属性。例如，对于配置项名称为“store2_data1”的配置项而言，其最下级子节点为表2中序号为7的一级子节点，故该配置项的说明字符为一级子节点的第二属性“数据单元所占字节数”。基于配置项说明文件的生成，开发人员或使用者可以通过配置项说明文件了解到每个配置项的含义。而在现有技术中，开发人员各自向程序代码中添加自行定义的配置项的情况下，配置项说明需要向每个开发人员一一确认才能得到，而本发明实施例中说明字符作为配置项定义的一个环节设置在配置定义文件中，从而基于文本处理实现配置项说明文件的自动生成，可以使开发人员方便地了解到其他开发人员所定义的配置项的含义，有助于开发效率的提升。

根据表2所示的全局配置定义文件，上述步骤104中所生成的用户配置文件示例如下：

#最大内存占用量

store1_index_config1＝1024

#内存溢出时是否警告

store1_index_config2＝True

#数据抽样比率

store1_data1＝0.25

#数据单元所占字节数

store2_data1＝4

可以看出，该用户配置文件包含全局配置定义文件中的四个配置项的名称，以及每个配置项的配置项值。其中，配置项值是全局配置定义文件中与配置项对应的最下级的子节点的第三属性。例如，对于配置项名称为“store1_data1”的配置项而言，其最下级子节点为表2中序号为5的一级子节点，故该配置项的配置项值为该一级子节点的第三属性“0.25”。可理解的是，相比于全局配置定义文件，用户配置文件直接列出了各个配置项的名称和对应的配置项值，使得查找配置项值的代码实现更加简单。

在上述步骤105中，在生成了用户配置文件之后，可以使合并后的程序代码中直接从用户配置文件中获取配置项值，因此例如可将程序代码：

GetPrivateProfileInt("store1_index_config1","Memosize",1024,"\\setting.ini")中的用于返回配置项值的代码中的源文件地址“\\setting.ini”变更为用户配置文件的文件地址“\\Configs.ini”，其中用户配置文件的文件名为“Configs.ini”。基于文件地址的变更，可以将用户配置文件设置为更利于返回配置项值的格式，从而简化程序代码中返回配置项值所实际执行的计算流程。

此外，作为上述步骤103的一种具体示例，图3是本发明一个实施例中一种生成配置项说明文件的流程图。参见图3，上述步骤103在本实施例中包括：

步骤1031：创建文本文件。

例如，在内存中申请一定大小的空间，用于对指定路径的文件进行写入操作。在一种可能的实现方式中，创建文本文件的同时还可以加载预置文本格式，比如加载列表格式，使得每个配置项对应于一个列表行。

步骤1032：判断是否能在全局配置定义文件未查找的部分中查找到最下级的子节点。

例如，可以在如表2所示的全局配置定义文件中按照先后顺序查找没有从属子节点的子节点，比如按照序号为3、4、5、7的顺序依次执行步骤1033至步骤1034的操作。

步骤1033：若是，则将查找到的最下级的子节点作为当前子节点，组合当前子节点的第一属性、当前子节点之上的所有子节点的第一属性，以及当前子节点之上的顶级节点的第一属性，以按照预置文本格式向文本文件中写入当前子节点所对应的配置项的名称。

例如，在查找到的子节点为表2中序号为3的二级子节点时，将该二级子节点作为当前子节点，获取当前子节点的第一属性“config1”、当前子节点之上的一级子节点的第一属性“index”、以及当前子节点之上的顶级节点的第一属性“store1”，从而组合得到配置项的名称“store1_index_config1”，以按照预置的列表格式将配置项的名称“store1_index_config1”写入到当前子节点所对应的列表行中。

步骤1034：获取当前子节点的第二属性，以按照预置文本格式向文本文件中写入当前子节点所对应的配置项的说明字符，并返回步骤1032之前。

例如，在查找到的子节点为表2中序号为3的二级子节点时，将该二级子节点作为当前子节点，获取当前子节点的第二属性“最大内存占用量”，以按照预置的列表格式将当前子节点所对应的配置项的说明字符“store1_index_config1”写入到当前子节点所对应的列表行中。然后返回步骤1032之前，依次以表2中序号为4、5、7的子节点为当前子节点执行步骤1033至步骤1034，直到全局配置定义文件未查找的部分中不存在最下级的子节点。

步骤1035：若否，则将文本文件保存为配置项说明文件。

比如，在完成所有配置项的遍历之后，即可将包含了全局配置定义文件中的四个配置项的名称，以及每个配置项的说明字符的文本文件保存为配置项说明文件，得到的形式例如上文所示，在此不在赘述。

基于步骤103包含上述过程，本发明实施例可以基于程序代码的方式实现配置项说明文件的自动生成，而不需要人工处理。相比于现有技术，本发明实施例可以实现配置项说明文件的自动生成，有利于减少开发人员的工作量，提高开发效率。

图4是根据一示例性实施例示出的一种合并程序代码的装置的结构框图。参见图4，所述装置包括：

获取单元41，用于在合并一个以上的模块的程序代码时，获取与每一所述模块对应的配置定义文件，所述配置定义文件中以所对应的模块的模块名称为顶级节点的第一属性定义了至少一个在程序代码中所使用的配置项，所述配置项的名称由顶级节点的第一属性和顶级节点之下的至少一级的子节点的第一属性依序组成；

合并单元42，用于将所述一个以上的模块各自对应的配置定义文件合并为全局配置定义文件，所有所述配置定义文件中的顶级节点在所述全局配置定义文件中相互并列。

可以看出的是，不同模块显然会具有不同的模块名称，因此本实施例中各个模块的程序代码中出现的配置项的名称必然会通过模块名称相互区分开，使得合并后的程序代码不容易出现配置项之间命名冲突的问题，从而可以节省为发现和调试其所导致的程序错误所花费的开发资源，有助于开发效率的提升。

需要说明的是，本实施例中的装置可以应用于任意一种包括处理器的电子设备，例如计算机、智能手机、平板电脑、笔记本电脑、个人数字助理(Personal Digital Assistant，PDA)等等。

还需要说明的是，本实施例中的配置定义文件可以由开发人员在相应的编写规范的指导下编写，也可以由根据开发人员输入的相应形式的配置项名称通过字符串处理自动生成，本发明对此不做限制。相对应的，获取与每一所述模块对应的配置定义文件的方式可以是来自于开发人员所使用的终端设备的发送，也可以是来自于同一电子设备内的自动生成单元的输出，还可以来自于其他设备内的自动生成单元的生成和发送等等，本发明对此不做限制。

在一种可能的实现方式中，所述装置还包括：

第一生成单元，用于根据所述全局配置定义文件生成配置项说明文件，所述配置项说明文件包含至少一个配置项的名称和说明字符，所述说明字符是所述全局配置定义文件中与所述配置项对应的最下级的子节点的第二属性。

在一种可能的实现方式中，所述第一生成单元包括：

创建子单元，用于创建文本文件；

遍历子单元，用于遍历所述全局配置定义文件中的最下级的子节点，以在历经任一最下级的子节点时依次执行下述步骤：

组合当前子节点的第一属性、当前子节点之上的所有子节点的第一属性，以及当前子节点之上的顶级节点的第一属性，以按照预置文本格式向所述文本文件中写入当前子节点所对应的配置项的名称；

获取当前子节点的第二属性，以按照预置文本格式向所述文本文件中写入当前子节点所对应的配置项的说明字符。

在一种可能的实现方式中，所述装置还包括：

第二生成单元，用于根据所述全局配置定义文件生成用户配置文件，所述用户配置文件包含至少一个配置项的名称和配置项值，所述配置项值是所述全局配置定义文件中与所述配置项对应的最下级的子节点的第三属性。

在一种可能的实现方式中，所述装置还包括：

变更单元，用于在合并后的程序代码中，将用于返回配置项值的代码中的源文件地址变更为所述用户配置文件的文件地址。

关于上述实施例中的装置，其中各个单元执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

图5是本发明一个实施例中一种合并程序代码的终端结构示意图，该终端可以用于实施上述实施例中合并程序代码的方法。具体来讲：

终端500可以包括RF(Radio Frequency，射频)电路110、包括有一个或一个以上计算机可读存储介质的存储器120、输入单元130、显示单元140、传感器150、音频电路160、WiFi(wireless fidelity，无线保真)模块170、包括有一个或者一个以上处理核心的处理器180、以及电源190等部件。本领域技术人员可以理解，图5中示出的终端结构并不构成对终端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

RF电路110可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，交由一个或者一个以上处理器180处理；另外，将涉及上行的数据发送给基站。通常，RF电路110包括但不限于天线、至少一个放大器、调谐器、一个或多个振荡器、用户身份模块(SIM)卡、收发信机、耦合器、LNA(Low Noise Amplifier，低噪声放大器)、双工器等。此外，RF电路110还可以通过无线通信与网络和其他设备通信。所述无线通信可以使用任一通信标准或协议，包括但不限于GSM(Global System of Mobile communication，全球移动通讯系统)、GPRS(General Packet Radio Service，通用分组无线服务)、CDMA(Code Division Multiple Access，码分多址)、WCDMA(Wideband Code Division Multiple Access,宽带码分多址)、LTE(Long Term Evolution,长期演进)、电子邮件、SMS(Short Messaging Service，短消息服务)等。

存储器120可用于存储软件程序以及模块，处理器180通过运行存储在存储器120的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器120可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端500的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器120可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器120还可以包括存储器控制器，以提供处理器180和输入单元130对存储器120的访问。

输入单元130可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。具体地，输入单元130可包括触敏表面131以及其他输入设备132。触敏表面131，也称为触摸显示屏或者触控板，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触敏表面131上或在触敏表面131附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触敏表面131可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器180，并能接收处理器180发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触敏表面131。除了触敏表面131，输入单元130还可以包括其他输入设备132。具体地，其他输入设备132可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元140可用于显示由用户输入的信息或提供给用户的信息以及终端500的各种图形用户接口，这些图形用户接口可以由图形、文本、图标、视频和其任意组合来构成。显示单元140可包括显示面板141，可选的，可以采用LCD(Liquid Crystal Display，液晶显示器)、OLED(Organic Light-Emitting Diode,有机发光二极管)等形式来配置显示面板141。进一步的，触敏表面131可覆盖显示面板141，当触敏表面131检测到在其上或附近的触摸操作后，传送给处理器180以确定触摸事件的类型，随后处理器180根据触摸事件的类型在显示面板141上提供相应的视觉输出。虽然在图5中，触敏表面131与显示面板141是作为两个独立的部件来实现输入和输入功能，但是在某些实施例中，可以将触敏表面131与显示面板141集成而实现输入和输出功能。

终端500还可包括至少一种传感器150，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板141的亮度，接近传感器可在终端500移动到耳边时，关闭显示面板141和/或背光。作为运动传感器的一种，重力加速度传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于终端500还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路160、扬声器161，传声器162可提供用户与终端500之间的音频接口。音频电路160可将接收到的音频数据转换后的电信号，传输到扬声器161，由扬声器161转换为声音信号输出；另一方面，传声器162将收集的声音信号转换为电信号，由音频电路160接收后转换为音频数据，再将音频数据输出处理器180处理后，经RF电路110以发送给比如另一终端，或者将音频数据输出至存储器120以便进一步处理。音频电路160还可能包括耳塞插孔，以提供外设耳机与终端500的通信。

WiFi属于短距离无线传输技术，终端500通过WiFi模块170可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图5示出了WiFi模块170，但是可以理解的是，其并不属于终端500的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器180是终端500的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器120内的软件程序和/或模块，以及调用存储在存储器120内的数据，执行终端500的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器180可包括一个或多个处理核心；优选的，处理器180可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器180中。

终端500还包括给各个部件供电的电源190(比如电池)，优选的，电源可以通过电源管理系统与处理器180逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源190还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

尽管未示出，终端500还可以包括摄像头、蓝牙模块等，在此不再赘述。具体在本实施例中，终端500的显示单元是触摸屏显示器，终端500还包括有存储器，以及一个或者一个以上的程序，其中一个或者一个以上程序存储于存储器中，且经配置以由一个或者一个以上处理器执行述一个或者一个以上程序包含用于进行以下操作的指令：

合并一个以上的模块的程序代码时，获取与每一所述模块对应的配置定义文件，所述配置定义文件中以所对应的模块的模块名称为顶级节点的第一属性定义了至少一个在程序代码中所使用的配置项，所述配置项的名称由顶级节点的第一属性和顶级节点之下的至少一级的子节点的第一属性依序组成；

将所述一个以上的模块各自对应的配置定义文件合并为全局配置定义文件，所有所述配置定义文件中的顶级节点在所述全局配置定义文件中相互并列。

在一种可能的实现方式中，所述方法还包括：

根据所述全局配置定义文件生成配置项说明文件，所述配置项说明文件包含至少一个配置项的名称和说明字符，所述说明字符是所述全局配置定义文件中与所述配置项对应的最下级的子节点的第二属性。

在一种可能的实现方式中，所述根据所述全局配置定义文件生成配置项说明文件，包括：

创建文本文件；

遍历所述全局配置定义文件中的最下级的子节点，以在历经任一最下级的子节点时依次执行下述步骤：

组合当前子节点的第一属性、当前子节点之上的所有子节点的第一属性，以及当前子节点之上的顶级节点的第一属性，以按照预置文本格式向所述文本文件中写入当前子节点所对应的配置项的名称；

获取当前子节点的第二属性，以按照预置文本格式向所述文本文件中写入当前子节点所对应的配置项的说明字符。

在一种可能的实现方式中，所述方法还包括：

根据所述全局配置定义文件生成用户配置文件，所述用户配置文件包含至少一个配置项的名称和配置项值，所述配置项值是所述全局配置定义文件中与所述配置项对应的最下级的子节点的第三属性。

在一种可能的实现方式中，所述方法还包括：

在合并后的程序代码中，将用于返回配置项值的代码中的源文件地址变更为所述用户配置文件的文件地址。

可以看出的是，不同模块显然会具有不同的模块名称，因此本实施例中各个模块的程序代码中出现的配置项的名称必然会通过模块名称相互区分开，使得合并后的程序代码不容易出现配置项之间命名冲突的问题，从而可以节省为发现和调试其所导致的程序错误所花费的开发资源，有助于开发效率的提升。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。