框架設(shè)計(jì)
第一、IM應(yīng)用一般是基于長連接的，也就是后臺一直在收發(fā)數(shù)據(jù)，那這里就有一個后臺的概念；
第二、如果用戶是一個人群里面的中心人物的話，那么他的的數(shù)據(jù)量就會很大。頁面的顯示及數(shù)據(jù)庫的處理就需要關(guān)注了；
第三、分解app有利于我們降低耦合，在后期維護(hù)和升級時(shí)，稍微容易一點(diǎn)。
依賴
這個模塊是所有部件運(yùn)行的中間節(jié)點(diǎn)，負(fù)責(zé)app內(nèi)的信息傳遞和數(shù)據(jù)處理。因此，app運(yùn)行時(shí)他就必須存在。那這里有兩個合適的人選，一個是AppDelegate，一個是他的RootViewController。這里我選擇的是RootViewController，原因我說一下一下：1、我使用了CoreData，也需要處理APNS，所以AppDelegate已經(jīng)很魁梧了；2、我的app是基于TabBarViewController，而TabBarViewController對用戶是不可見的，他不需要處理UI，而且?guī)讉€主要頁面都是他的viewcontrollers，方便調(diào)用。
選好了之后，我們需要明確他的作用。我給他分配了這幾件事情：處理網(wǎng)絡(luò)模塊推送來的數(shù)據(jù)，存入數(shù)據(jù)庫，推送數(shù)據(jù)更新的通知到各個頁面。也就是外部的數(shù)據(jù)，到這里就止步了，不會直接操作UI界面。
網(wǎng)絡(luò)通訊
這個模塊負(fù)責(zé)和服務(wù)器的數(shù)據(jù)傳輸，app運(yùn)行階段都不可以被銷毀。所以，這個模塊需要使用單利模式來創(chuàng)建，并且放在全局線程中。這個模塊對外就是收發(fā)數(shù)據(jù)；對內(nèi)就是傳遞數(shù)據(jù)到依賴和接受UI界面的發(fā)送指令。也就是他只管收發(fā)數(shù)據(jù)，不操作UI和數(shù)據(jù)庫。
數(shù)據(jù)庫
他負(fù)責(zé)增刪改查。。。（他好輕松，只要出個API就好了）
UI界面
這里指app所有可視、可交互頁面。所有你想掐死產(chǎn)品的原因都展示在這里。然而這是用戶可見的，也就是說，不能卡頓，要好操作等等。有些頁面會有很多的UI交互，為此我們不能給他太多負(fù)擔(dān)。那我就讓他做兩件事，展示和發(fā)送請求。展示是他本來的工作，取一下數(shù)據(jù)庫，更新UI；請求是一個接口，他只要抓取頁面的數(shù)據(jù)填進(jìn)去就好了。
總結(jié)一下：將每個模塊拆開之后，他們所做的事情就很明確，數(shù)據(jù)的來源也得到了保證，UI的處理邏輯也簡單。全API的調(diào)用方式便于后期拓展。
