先说一下为什么要讲框架的设计。
第一、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的调用方式便于后期拓展。
附简图：
