花了些时间研究了java后端开发，总体感觉起来与客户端与服务端开发存在非常多的不同。服务端所需要掌握的知识太多太多了，随随便便一个分布式就足够学个一年半载。这里简单记录一下自己对配置的理解。
配置的作用
配置无非就是把大量的参数，放在一起便于统一管理。如果从函数调用的角度来讲，传递参数其实就是进行配置，只不过粒度太小，算不上平常所说的配置。
配置的作用非常多，但归结一点就是传递约定好的信息或方式。小则一个应用程序的版本号，名称（iOS的plist文件），大则操作系统的网络配置（Host）、口令等。无论是大是小，配置在软件开发中都无处不在。
广义上来讲，我们所使用的操作系统就使用大量的配置文件。比如：
- UNIX主机下TCP/IP服务配置文件
- Windows系统口令配置文件
- 最常用还是数host文件
上面几种都是关于操作系统基本的配置文件，其本质和java中所用的xml，propery；iOS中的plist；node中的json是一样的。无非就是换个包装而已，只要理解到了本质，也就不难理解。
从软件开发的角度，配置完完全全可以通过运行时的来完成，为什么非要写成文件，搞一大堆的xml、json、yml？这个问题我也想了好久，比如java后端开发中，稍微大一点的项目就会遇到一大堆的配置文件非常繁琐。后面会给出自己的理解。
为什么不直接用配置类？
文件相对于运行时的配置类最大的好处就是有利于复用、便于更新及本地化。
iOS中的配置
在iOS开发中使用配置类的场景远远比使用配置文件的场景多。比如SDWebImage中缓存的配置：
@interface SDImageCacheConfig : NSObject
/**
* Decompressing images that are downloaded and cached can improve performance but can consume lot of memory.
* Defaults to YES. Set this to NO if you are experiencing a crash due to excessive memory consumption.
*/
@property (assign, nonatomic) BOOL shouldDecompressImages;
/**
* disable iCloud backup [defaults to YES]
*/
@property (assign, nonatomic) BOOL shouldDisableiCloud;
/**
* use memory cache [defaults to YES]
*/
@property (assign, nonatomic) BOOL shouldCacheImagesInMemory;
/**
* The maximum length of time to keep an image in the cache, in seconds
*/
@property (assign, nonatomic) NSInteger maxCacheAge;
/**
* The maximum size of the cache, in bytes.
*/
@property (assign, nonatomic) NSUInteger maxCacheSize;
@end
把对缓存的一些设置全部放在了SDImageCacheConfig配置类中，并且注明了默认是什么，这一点非常重要。
这是把配置写成配置类的方式，那么可不可以换成配置文件的方式呢。肯定可以，其实在iOS开发中用来保存用户偏好设置的NSUserDefaults就是使用文件配置的方式，只不过是系统帮我们读取配置文件，然后映射为NSUserDefaults对象而已。NSUserdefaults 的本质是使用了plist存储数据，将存储在NSUserdefaults中的数据写入了一个以Bundle Identifier命名的plist中。对应的路径在沙盒中为：root/Library/Preferences/xxxx.plist
就连我们平时我们所使用的xcode也使用了很多配置文件，比如Xcode中记录项目文件的project.pbxproj文件。只是我们开发过程中没有像java后端开发那样大量使用自定义的配置，更多的是系统帮我们做好了而已。
java后端开发中的配置
java中的配置远远多于iOS中的配置。毕竟服务端所要做的东西比客户端多太多。自己总结的一套java框架图，学完这些基本就离聪明绝顶不远了。
常见的java中需要配置的内容：
- 数据库配置（druid）
- 缓存框架配置(redis，enchache)
- 消息队列配置（mq）
- 日志框架配置（log4j）
- 作业调度配置（quartz）
- .....
太多了，以至于一个大的项目单单配置文件就让人摸不着头脑。而且一般情况下都是使用xml的方式。每一个层面都可能有多个配置文件，一个层面的配置对于其他层面的配置可能存在交互等等。这样基于xml配置的java开发现象让很多人开始觉得复杂。于是后面出现了基于类配置或者说基于默认xml配置规则的Spring Boot出现。
虽然在后端开发中大部分使用xml配置，其中也有一些框架也是基于类配置的，并且即使是基于xml最终落实到代码上，也是基于类配置，只不过xml将配置本地化了而已。
一般处理过程：创建一个xxxconfig，对其需要自定义的属性进行设置，然后将配置传入主类。如果是用xml方式一般是在java类加载的时候（也就是static 代码块中）从classpath中读取相关的配置文件，如果有想匹配的配置文件就讲起内容读出来，然后设置的到对应的配置类中。
为什么客户端开发和服务端开发在配置仅仅在配置上就有如此大的不同？这里我大致总结了如下几点：
- 客户端没有服务端那么多的模块。客户端就是一个单机应用，而服务端涉及到数据库，分布式等等。
- 一般情况下客户端的选择对框架的选择非常有限，比如数据库本质就sqlite。而服务端的选择各种各样，以满足不同的业务场景。
- 客户端大部分的配置基本上都已经被系统约定好，提供了，比如iOS中的NSUserDefault。而服务端由于各式各样的业务场景，所以更多的是需要自定义。
那为什么非要基于xml，而不基于配置类呢？之前解释过一些，这里在说一点其他的。其实现在java后台开发也慢慢意识到了xml配置所带来的繁琐，所以Spring Boot显示深受青睐。至于为什么之前基于xml配置如此之多，笔者认为有如下几点：
- xml能存储小量数据，仅仅是存储数据。
- xml可以跨平台，主流各种平台都对xml有支持。
- xml规范性非常强，这样就可以更好的去解释文件内的信息。
- xml不适合动态语言但非常适合强类型的语言。java 处理 xml 更容易。
- 历史问题，业界标准形成，不容易改变。
配置文本化后都有一个好处：文本形式方便浏览修改，方便更新配置，后期维护方便。比如在更改配置之后不用重新启动服务器，如果是写成配置类了，类的结构已经确定，需要重新启动。而用配置文件之后只需要重新读取配置文件就可以更新配置。
