称作配置系统未免太大了一点，不过它的配置管理这一块确实有加以设计，一方面以增加灵活性，另一方面以支持第三方扩展。通过分析源码，粗略画出如下的结构图：

　　

　　一、类分析

　　SharedPreference

　　一切的基础都是com.csipsimple_preferences.xml这个文件，它存在于app_packagename/shared_prefs文件夹下——它是SharedPerference类型对应的存储文件。里面存储了用户一些配置值，这些值有string、float、boolean、integer类型。

　　PreferenceWrapper

　　为了对这些值有一些比较通用的接口进行读取和修改，因此建了一个PreferenceWrapper类。PreferenceWrapper有四个HashMap，分别对应四种类型，每个HashMap中的key-value与SharedPreference中的key-value一一对应。

　　除了基本操作key-value的函数，还包括一些工具函数，例如判断用户类型、设置编解码等。当然这些函数进一步还是对SharedPreference进行操作。不过我觉得还是另建一个类进行这些操作会好一些，让每个类的功能明确一点。

　　PreferenceProvider

　　PreferenceProvider继承自ContentProvider，是为了提供一个统一的增删改查接口。它指定了authorities为com.csipsimple.prefs，并将preferenceWrapper中的内容抽象为preference表。ContentProvider/ContentResolver是android提供的数据共享机制，可以用于跨进程数据共享，同时也作为一种数据交换标准。

　　SipConfigManager

　　调用ContentResolver的接口对数据增删改查。数据通过Uri来标识。

　　PreferenceProviderWrapper

　　就是这货让人很难理解。我一度以为PreferenceProviderWrapper是一个ContentProvider，其实本质来说，它却是一个ContentResolver，因为它调用SipConfigManager的函数，从而间接调用了ContentResolver的接口。它的作用也是为了方便数据的访问，从这点来说，和PreferenceWrapper没什么区别。

　　二、总结

　　通过上述分析，我们可以通过两个入口来访问配置选项，一个是PreferenceWrapper，另一个是PreferenceProviderWrapper。整个工程中，确实有些地方使用前者，有些地方使用后者，就这一点还是挺乱的。其实整套设计来说，就用PreferenceWrapper就好了。后者我们且认为是给第三方使用提供了一个示例吧。