http://pingguohe.net/2013/02/14/version_2_0/

移動網際網路如火如荼，iOS 應用+ Android 應用+ 手機站似乎成了所有網際網路公司的標配，你的網站要是還沒有個iOS 應用，似乎都不好意思跟人打招呼。

iOS 應用誕生畢竟才只有不到5年的時間，各個方面還都處在起步階段。不管是出於團隊缺乏經驗，還是那個“唯快不破”的鐵律，往往這些iOS 應用的第一個版本都比較簡陋，尤其在技術架構上。這篇文章，我想跟大家探討的就是這個問題，當你的iOS應用已經有一個版本線上的情況下，如何去構建一款可以支援高效迭代，快速響應的2.0版。

首先，應用的架構要層次清晰。把不依賴版本更新變化的，以來版本更新變化的，不需要變化的，業務邏輯，檢視邏輯，工具，等這些內容梳理清楚，單獨處理。


圖1，應用整體架構

自下而上，最底層的是API Server ，也就是服務端，和經常踩到大便一般的網路，這篇文章著重討論客戶端架構，對這兩層不多說。

Network 和Local Storage 是整個應用的資料來源。Local Storage 除了儲存資源資料，還快取來自Network 的資料。在這一層中，所有資料都以原始的未經格式化的結構存在，或是文字，或是文字的陣列和字典。

Network 是客戶端與服務端的溝通橋樑，一般建議使用開源控制元件（如：AFNetworking）實現。在大便一樣的網路情況下，請求會出現各種異常，因此這些控制元件中提供的請求控制方法會提供很多便利，去處理這些問題。

Local Storage 除以檔案形式直接儲存圖片等資原始檔外，資訊類資料，如：使用者資訊，配置資訊等，建議使用Cocoa 框架中提供的Core Data，對SQLite 的一個非常好的封裝。直接使用檔案儲存要注意寫入頻率，高頻率的I/O 操作非常佔用資源，一般來說把資料直接放在記憶體中，只有需要的時候，如：關閉應用或關鍵資料寫入（使用者密碼）才進行回寫。

Items 是整個應用中對資料物件的封裝，某種程度上就是Value Object 的集合。 一個數據型別的Item 可以是最原始的陣列或字典，也可以是封裝成如Java 中的POJO 一般，或者更復雜的帶有基本處理方法的資料物件。 Data Center 是Items 的控制中心，把網路請求，網路異常處理，快取機制，等完全封裝起來。Data Center 響應上層的資料請求，向Network 或Local Storage 索取原始資料，並拼裝成Items 中定義的資料結構，返回給上層。

Services 是對業務邏輯的封裝，Data Center 關注如何獲取Items，Services 則關注如何組織Items，如：怎麼構建搜尋引數，如何翻頁，列表排序等。Services 把複雜的業務邏輯封裝成類名，方法名和引數，供上層呼叫。這一層的變化較上面提到的幾層要頻繁的多，因為Services 隨著業務變化而變化，已經不是純技術層面了。
View Controllers 顧名思義，就是Cocoa 框架中的ViewController，在這些ViewController 裡只有展示邏輯。這一層並不關心返回的Items 是什麼含義，為什麼要如此組合，View Controllers 只關心什麼Items 需要什麼檢視，採用是什麼顏色，等。

Tools 是幾乎貫穿整個應用的工具和擴充套件集合，工具如：字串md5 加密，陣列扁平化，等；擴充套件如：UIView 框架設定，URL 拼裝，等。

在這個架構下，Items 和Tools 幾乎是靜態的，沒有邏輯。Network、Data Center和Local Storage 從技術角度封裝邏輯，在版本迭代過程中幾乎不發生變化。Services 這一層是版本迭代中調整的重點，他的厚度取決於這款應用的業務複雜度。View Controllers 的內容改變更加頻繁，甚至不依賴版本更新，需要通過API Server 的的資訊修改介面展示，需要較高的可定製性。