Android IM即时通讯多进程中间件规划与完成
IM数据库的规划在移动端，往往和事务是高度耦合的，换句话说便是，数据库的结构直接决议你的事务怎样完成，所以在IM开发中，数据库的规划直接联系到整个IM的完成方式。
咱们能够清晰一下，在客户端中哪些需求运用数据库的场景或者说条件有哪些，这有助于咱们决议数据库的规划逻辑。当然，咱们能够规划很杂乱的数据库，当规划后的数据库出现在你面前时，你或许能知道你不需求哪些，此刻你能够删去不需求的。
客户端运用数据库的条件
- 数据需求耐久化。假如事务数据需求长时间保存，且不能跟着程序的完毕而消失，那么需求运用数据库进行耐久化存储。
- 数据需求频繁查询。假如事务数据需求频繁查询，例如通过某些关键字进行搜索，那么需求运用数据库进行高效的查询。
- 数据需求修改。假如事务数据需求频繁修改，例如增加、删去、更新等操作，那么需求运用数据库进行数据的修改。
- 数据需求跨过多个用户和体系。假如事务数据需求跨过多个用户和体系，那么需求运用数据库进行数据的共享和传递。
在进行数据库规划时，需求依据事务需求进行规划，并考虑数据结构、数据访问、功能等因素，保证数据的安全性、完整性和可用性。一起，也需求考虑数据库的扩展性，保证能够应对事务发展的需求。
咱们能够以此为参考决议是否需求一张表。
剖析
以微信为例
首要咱们剖析一下IM客户端的事务有哪些，然后再结合事务梳理 哪些需求落库，然后再规划数据库。 咱们剖析时要紧扣它的事务场景和数据来历。
1.1 客户端谈天列表
咱们记为im_chat_list.
-
用处：用于展示IM 谈天记录
-
数据来历：在线数据 + 离线数据
- 在线数据： 当用户在线时，数据通过长衔接推送，此刻数据称为在线数据
- 离线数据： 当用户不在线时，音讯会缓存到服务器，当用户在此在线时，需求同步离线音讯，此刻称为离线数据
-
剖析： 这个列表的数据是增量增加的，也是批量增加的，也有可能是一次性的，对应以下几个状况，
- 当本地存在数据时，咱们期望只更新新增的数据
- 当本地没有数据时，咱们需求悉数的数据（按需求而定）
但归结起来，咱们需求一张表，一张用于储存谈天列表的表，该表中的数据元素有：
- 头像
- 用户名
- 最新一条谈天内容
- 时间
- 未读数
- 群、订阅号、私聊（类型）
表1 音讯列表
然后咱们剖析一下这个表，从面向对象的角度来看，他是不符合单一指责原则的，由于它既有用户音讯又有谈天内容，还有音讯列表。所以咱们需求精简一下这张表，解析剖析，看怎样精简。
- 服务端面临上述“既有用户音讯又有谈天内容，还有音讯列表”的状况是愈加糟糕的，由于他需求查询多张表才干拼出一条对应的数据，
- 咱们发现，每创建一条音讯列表，不管是什么类型，都会出现对应的“用户概念”：
- 私聊： 用户便是对方的信息
- 群聊： 用户便是群的信息（群头像、昵称）
- 订阅号： 用户便是订阅号的信息
当用户信息发生变化时，咱们需求更新用户信息，这是一个很独立的概念，所以咱们需求一张表，用以存储用户信息（当然，就微信而言，存在好友联系时，咱们必须有一张表用来存储一切用户的信息）
那怎样优化上述表呢？，很简单，咱们将在表中增加一个谈天对方的id, 这个id 便是用户的id,在整个体系中，它是能表示用户的仅有属性，然后咱们利用id 相关两个表，
更新音讯列表
表2 音讯列表
1.2 用户表
树立用户表
这样操作后，音讯列表的责任变为音讯列表和会话信息了，咱们是为音讯列表规划的，所以直接去剖析音讯，怎样去除它。
音讯在IM项目中，肯定是需求独自存储的，由于用户谈天是增量的，咱们必须耐久化，才干防止大量的网络请求。此刻咱们剖析音讯列表和音讯的联系，他们一起的元素是：
-
音讯列表id
-
会话方id(用户id)
所以咱们能够直接用音讯列表中的user_id 相关谈天音讯的表，以此完成最后一条音讯的显现。此刻音讯列表变为：
1.3 谈天记录表
谈天记录表：
部分事务流程
更新的中心思想便是主要处理谈天记录表，其他表在谈天记录表的驱动下被迫更新，但是同步离线音讯场景需求独自处理。
流程图
首要清晰一下需求参加的对象
- 发送者A，接收者B
- 音讯表
- im_chat_list: 列表
- im_chat_0: 谈天记录表（假如涉及到群聊，谈天记录表能够分表处理，依照用户属性分表，后续有机会共享）
- im_user: 谈天与话方用户信息表
这个文章智能剖析到此，这是最简单的一个场景，在IM中，离线音讯，音讯连续检测等都需求处理，有需求具体了解的能够直接私我。
