第一次纪录东西，也没有特别的顺序，想到哪里就随手画了一下，后续会继续整理～
6.2消息页面动作流程
6.2.1 消息页面初始化的总体思路
1.页面数据的填充更新直接由页面主线程从本地数据库请求
2.数据库数据的填充由后台线程异步方式从网络请求
3.前台线程每次按照18条记录读取数据库数据，后台线程按照每次18*3从网络请求数据
4.后台线程数据的请求由主线程满足一定的条件后发送总线事件，在 oneventbackgroudthread 中处理，具体条件（或的关系）如下：
1>第一次请求
2>本地数据库没有加载到数据
3>请求次数是3的倍数（为了满足本地数据能够及时读取到）
5.后台异步线程读取网络信息有目前两个接口，分别是
1>CID_MSG_LIST_REQUEST_VALUE 即：传入一个最后的消息id（lastmsgid）和 请求的数量（msgcnt），从服务端请求数据
2>CID_MSG_GET_BY_MSG_ID_REQ_VALUE 即 传入需要请求的消息id列表，从服务端请求数据
目前使用方式：
［第一次］从数据库请求的［当屏消息列表（18条或少）］,全部都是［本地发送失败］的消息时，采用第一种方式，传入一个很大的数字和请求数量，去服务端拉取数据，否则，按照最后一个成功消息的msgid 和 请求数量（18*3）作为条件，从本地数据库读取消息列表（beginid －> endid）,然后，按照该列表和 msgid 与 msgid－18*3 的区间过滤出本地没有的msgid，进而按照第二种方式去服务端请求数据。(因为从服务端是按照消息倒序的形式拉取的)
6.向下拉动时传入当前页面的第一个消息实体（msgid最新的实体）和拉动次数（pulltimes）作为参数，从本地数据库读取新数据，数据获取成功后，拉动次数加1.
6.2.2 消息接收的逻辑说明
1>总体实质：接收到服务端的pb数据转换为greendao生成的实体类messageentity及其子类（按照展示形式和业务分为textMessage,imageMessage,audioMessage,mixMessage[图文混合],并且子类利用重写messageEntity的getContent 等字段获取方法），并且存储messageEntity消息到数据库,及时更新数据库和本地缓存sessionmap，然后发送接收消息的事件，通知ui线程重新读取数据并刷新界面，当然，更新session的过程，也同样伴随数据库和界面数据的更新。
2>messageEntity子类的差异主要在于按照业务和展现形式的分类，具体子类按照具体形式扩充字段，例如：imagemessage，需要扩充字段 path，url，loadstatus。在数据库存储时都会序列化为json，存储在content字段内，从数据库读取数据时再反序列为不同的消息对象，这个正是orm框架的优势所在。
3>需要知道的，目前语音消息是通过socket发送的，所以就直接存储了，图片发送的是一个url，在页面展示时，再去请求地址。
6.2.3 消息发送的逻辑说明
1>构建发送对象（TextMessage,ImageMessage,AudioMessage）
2>存储消息对象到数据库
3>更新或创建Session缓存及存储数据库，并发送事件通知，更新session相关ui
4>更新消息界面（文本消息直接更新了，其他复杂一些）
5>发送消息到服务器，并添加检测队列。
6>ack返回后的处理
（1）更新本地消息数据库
(2) 更新session相关（sessionmap 以及db）
（3）发送总线事件（messageevent），通知界面更新。
6.2.4 图片消息的发送过程