iOS-IM开发流程

2021-04-23  本文已影响0人  奔跑的喔汼

框架设计
第一、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的调用方式便于后期拓展。

705454-20160321154928120-287016102.png
上一篇下一篇

猜你喜欢

热点阅读