聊聊程序的配置文件

多是移動應用的普遍普及，爲了安全性的考慮如今的移動應用大都運行在一個沙箱中，不管是有系統支持的運行時沙箱仍是邏輯上的沙箱。好比如今的應用大多數只能寫本身的安裝目錄，從而將本身的運行環境和其餘應用的運行環境隔絕開來。

早些時候我寫過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