iOS IM開發建議（一）App框架設計

　　先說一下爲何要講框架的設計。

　　第1、IM應用通常是基於長鏈接的，也就是後臺一直在收發數據，那這裏就有一個後臺的概念；

　　第2、若是用戶是一我的羣裏面的中心人物的話，那麼他的的數據量就會很大。頁面的顯示及數據庫的處理就須要關注了；

　　第3、分解app有利於咱們下降耦合，在後期維護和升級時，稍微容易一點。

 

　　我以爲框架就是先拆解部件再創建聯繫。框架有不少種，我借鑑的是依賴注入。

依賴

　　這個模塊是全部部件運行的中間節點，負責app內的信息傳遞和數據處理。所以，app運行時他就必須存在。那這裏有兩個合適的人選，一個是AppDelegate，一個是他的RootViewController。這裏我選擇的是RootViewController，緣由我說一下一下：一、我使用了CoreData，也須要處理APNS，因此AppDelegate已經很魁梧了；二、個人app是基於TabBarViewController，而TabBarViewController對用戶是不可見的，他不須要處理UI，並且幾個主要頁面都是他的viewcontrollers，方便調用。

　　選好了以後，咱們須要明確他的做用。我給他分配了這幾件事情：處理網絡模塊推送來的數據，存入數據庫，推送數據更新的通知到各個頁面。也就是外部的數據，到這裏就止步了，不會直接操做UI界面。

網絡通信

　　這個模塊負責和服務器的數據傳輸，app運行階段都不能夠被銷燬。因此，這個模塊須要使用單利模式來建立，而且放在全局線程中。這個模塊對外就是收發數據；對內就是傳遞數據到依賴和接受UI界面的發送指令。也就是他只管收發數據，不操做UI和數據庫。

數據庫

　　他負責增刪改查。。。（他好輕鬆，只要出個API就行了）

UI界面

　　這裏指app全部可視、可交互頁面。全部你想掐死產品的緣由都展現在這裏。然而這是用戶可見的，也就是說，不能卡頓，要好操做等等。有些頁面會有不少的UI交互，爲此咱們不能給他太多負擔。那我就讓他作兩件事，展現和發送請求。展現是他原本的工做，取一下數據庫，更新UI；請求是一個接口，他只要抓取頁面的數據填進去就行了。

 

　　總結一下：將每一個模塊拆開以後，他們所作的事情就很明確，數據的來源也獲得了保證，UI的處理邏輯也簡單。全API的調用方式便於後期拓展。

附簡圖：