聊聊程序的配置文件

多是移动应用的普遍普及，为了安全性的考虑如今的移动应用大都运行在一个沙箱中，不管是有系统支持的运行时沙箱仍是逻辑上的沙箱。好比如今的应用大多数只能写本身的安装目录，从而将本身的运行环境和其余应用的运行环境隔绝开来。

早些时候我写过nodejs和git的库和配置文件能够选择安装位置，好比 global, system, local等。这是一个进步，他改变了咱们对配置文件存放位置的思考。同时如今的云存储，云同步更进一步改变了咱们对配置文件的思考。通俗的讲，如今的配置文件更加的偏向了Unix配置文件的风格——高内聚的配置文件，即将配置文件和使用这个配置文件的程序放在一块儿。然而这个原则也太过精简，在实际使用的时候咱们还要对他作一些扩展。

 

我分开来讲，先说说配置文件。

早些时候Windows使用注册表来统一管理程序的配置文件，并经过系统API来统一存取这些这个配置文件。随着应用数量的增加这个注册表出现了两个明显的问题，其一是注册表愈来愈大。其二是对注册表的误操做会致使应用或者的系统崩溃。在.NET做为Windows系统框架后，Windows作出了一些调整。这个调整是一个补救，那就是.NET应用大多使用app.config这个配置文件来决定应用程序的行为。这个相似于早期的ini配置文件。注册表大可能是系统级应用使用的，对于第三方应用仍是使用app.config来的方便和直接。

Unix在早期鼓励就将一个应用的配置文件放在应用的同一个目录。对于系统全局的配置还专门在文件结构中增长了/etc这个系统全局配置目录。大多数引用会使用当前用户的配置，若是找不到才去/etc目录找。在一些rc(run command)中也是先执行/etc的rc，而后再执行当前用户目录下的rc，这样当前用户有机会改变全局的设定。

其实若是你仔细看这些变化，高内聚是最值的注意的。配置文件离使用配置文件的程序更加近了。这也就是把相关的东西放在一块儿。

 

再来看看库的依赖。

在Unix上/usr/lib和/usr/local/lib是系统库于用户自安装库的目录。像nodejs更加深化了这种结构，可让库存在于三个等级，系统级，用户级和项目级。node的应用会从项目级开始依次寻找依赖的库。这样作有个优势就是一个库的不一样版本能够同时运行，同时为了节约空间，能够在用户级和系统级共享一个库。

对于库的依赖Windows早期的作法是在连接期指定，后来的DLL出现了，能够依赖注册过的DLL。.NET就更加宽泛了一点，若是你不指定DLL，程序会使用当前程序目录下的DLL，固然GAC中的DLL和本地的DLL发生冲突时Resolve到底引用的是哪一个DLL仍是很头疼。

由此来看，一个运行环境好比node或是Windows文件的loader，采用统一的，可预见的库依赖仍是颇有必要的。

 

理想的状况是，咱们将包含程序的目录随意拷贝到一个的电脑中，这个程序就能够按照预期正确的执行，而不用管这个电脑是使用了几年的电脑仍是一台新装的电脑。为了保持新安装电脑和使用了几年的电脑的行为的同步，云同步最近又流行了起来。让你惊讶的莫过于你买了一个新的iPad，当你用本身的帐号登录，没过几分钟，这台新iPad和你刚刚失去的iPad使用上如出一辙，你熟悉的应用还在，而且你对这些应用的配置还保存着，你能够和以往同样使用这台新的iPad而不用花上半天时间来装软件，配置软件。

苹果的文件规范，提到了这点。对于一个应用，首先他是一个*.app文件夹，这个文件夹包含了运行这个程序全部的依赖。所谓的安装和卸载软件就是这个文件夹拖到或是移出/Applications目录。其次*.app实际上是一个沙箱环境，他将当前应用和其余应用隔离开来。在这个沙箱环境中将数据分为“不可变”的应用程序代码及资源，须要“同步的可变”数据，好比用户配置文件，应用程序的状态记录等，还有部分是“不需同步的可变”数据，好比日志，缓存，临时文件等。

 

咱们在作架构决策的时候，或是写代码的时候，了解上面的这些，咱们能够知道配置文件是放哪里，程序怎么样打包发布，程序的数据该如何同步。而这些看似随意的决定，偏偏是体现”设计”的，最重要的他对程序产生一种不那么可见的影响，让程序变的更好，或是更坏。

 

参考：

https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html

http://unix.stackexchange.com/questions/65700/is-it-safe-to-add-to-my-path-how-come