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的调用方式便于后期拓展。

附简图：