先說一下為什麼要講框架的設計。

　　第一、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的調用方式便於後期拓展。

附簡圖：