GCONF中大量字符串如何操作？

要想使用GCONF读取数据，就必须构造这个数据的路径。

当数据条目比较少的时候，可以将这些条目硬编码在程序中，方便的进行读写。

 

但是当条目比较多的时候，特别是数据分层级的情况下，比如/system下面有20个app的目录，这20个app下面又分别有10条数据的情况，此时就不再适合使用硬编码了，如果非要用的话，得在程序中define 20*10 = 200 个字符串变量，在添加、删除应用程序以及增删改条目的时候，会带来很大的工作量。

 

为了解决这个问题，我采用了2种方法实现：

1、先把每一级的字符串使用define定义好，然后针对每一级来为其创建一个enum索引，同时根据这个索引，将这些字符串和其相关信息，比如是否可写、数据类型等写入一个结构体数组中。

在构造最终的字符串时，使用sprint的方式，分层将几级数据打入字符串变量中。

 

这种方法是为了避免在应用程序使用时，到处使用define字符串，而导致程序空间变大，以及担心使用字符串会比使用enum索引的速度慢的情况。

同时，为了能把这个GConf模块封装好，还提供了以index作为参数的get方法从这些结构体数组中获取gconf条目的名称、读写类型、数据类型等的函数。

开始的时候，发现这种方法还很不错，程序封装性好，外部使用的时候，仅仅使用index就可以解决问题了。

但是到了后来，发现这种方法及其的不灵活，index和key_name的耦合性非常的强。而且经常会需要通过index来获取key_name的情况。

 

特别是到了后来，编写另一个只有一层的GCONF模块时，如果采用和上面模块相同的架构，则程序代码量会比较大，而且这两个模块代码之间的可重用性很低。

 

为了解决这个问题，转而使用方案二。

 

这个方案就是同意用户在调用gconf模块的接口时，可以使用define的字符串常量做为参数。

采用这种方法后，就完全抛弃了为每个字符串常量创建ennum index 的方法，同时少了很多类似于get_name(index)的函数，代码量急剧减少，且可维护性增强。

 

同时考虑到编译器在对待使用define的字符串时，会做一定的优化处理，不会在应用程序数据段中保存多份享用的字符串，这种方案是比较理想的。

 

结论就是：

如果为了照顾大量的字符串，而使用了和字符串耦合性相当强索引后，程序代码量急剧增多，且可维护性下降的情况下，可以考虑不使用index，而单纯使用字符串常量来作为系统间交互的依据。

这种方式虽然封装性较index的差些，但是灵活性更强，更容易维护。