iOS IM開發建議（一）App架構設計，iosapp

iOS IM開發建議（一）App架構設計，iosapp

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

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

附簡圖：