先說一下為什麼要講框架的設計。 第一、IM應用一般是基於長連接的，也就是後臺一直在收發數據，那這裡就有一個後臺的概念； 第二、如果用戶是一個人群裡面的中心人物的話，那麼他的的數據量就會很大。頁面的顯示及資料庫的處理就需要關註了； 第三、分解app有利於我們降低耦合，在後期維護和升級時，稍微容易一點。
先說一下為什麼要講框架的設計。
第一、IM應用一般是基於長連接的，也就是後臺一直在收發數據，那這裡就有一個後臺的概念；
第二、如果用戶是一個人群裡面的中心人物的話，那麼他的的數據量就會很大。頁面的顯示及資料庫的處理就需要關註了；
第三、分解app有利於我們降低耦合，在後期維護和升級時，稍微容易一點。
我覺得框架就是先拆解部件再建立聯繫。框架有很多種，我借鑒的是依賴註入。
依賴
這個模塊是所有部件運行的中間節點，負責app內的信息傳遞和數據處理。因此，app運行時他就必須存在。那這裡有兩個合適的人選，一個是AppDelegate，一個是他的RootViewController。這裡我選擇的是RootViewController，原因我說一下一下：1、我使用了CoreData，也需要處理APNS，所以AppDelegate已經很魁梧了；2、我的app是基於TabBarViewController，而TabBarViewController對用戶是不可見的，他不需要處理UI，而且幾個主要頁面都是他的viewcontrollers，方便調用。
選好了之後，我們需要明確他的作用。我給他分配了這幾件事情：處理網路模塊推送來的數據，存入資料庫，推送數據更新的通知到各個頁面。也就是外部的數據，到這裡就止步了，不會直接操作UI界面。
網路通訊
這個模塊負責和伺服器的數據傳輸，app運行階段都不可以被銷毀。所以，這個模塊需要使用單利模式來創建，並且放在全局線程中。這個模塊對外就是收發數據；對內就是傳遞數據到依賴和接受UI界面的發送指令。也就是他只管收發數據，不操作UI和資料庫。
資料庫
他負責增刪改查。。。（他好輕鬆，只要出個API就好了）
UI界面
這裡指app所有可視、可交互頁面。所有你想掐死產品的原因都展示在這裡。然而這是用戶可見的，也就是說，不能卡頓，要好操作等等。有些頁面會有很多的UI交互，為此我們不能給他太多負擔。那我就讓他做兩件事，展示和發送請求。展示是他本來的工作，取一下資料庫，更新UI；請求是一個介面，他只要抓取頁面的數據填進去就好了。
總結一下：將每個模塊拆開之後，他們所做的事情就很明確，數據的來源也得到了保證，UI的處理邏輯也簡單。全API的調用方式便於後期拓展。
附簡圖：
