转载

说说开发中的配置

配置无非就是把大量的参数，放在一起便于统一管理。如果从函数调用的角度来讲，传递参数其实就是进行配置，只不过粒度太小，算不上平常所说的配置。

配置的作用非常多，但归结一点就是传递约定好的信息或方式。小则一个应用程序的版本号，名称（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中读取相关的配置文件，如果有想匹配的配置文件就讲起内容读出来，然后设置的到对应的配置类中。

为什么客户端开发和服务端开发在配置仅仅在配置上就有如此大的不同？这里我大致总结了如下几点：