Android仿QQ聊天系统课程设计：Bmob云数据库实现即时通信

简介：这份仿QQ聊天系统课程设计文档面向计算机相关专业学生与课程设计开发者，围绕仿照QQ架构实现一套具备注册、登录、实时聊天等核心功能的聊天系统展开，适合作为软件工程、数据库、网络编程等课程的课设参考或答辩材料。压缩包内共1个doc文件，约1.04MB，内容按绪论、需求分析、总体设计、数据库设计、详细设计、编码、结论与学习体会等章节组织，涵盖软件功能与安全需求分析、软件结构图、注册/登录/聊天功能概要、身份验证与访问控制等安全设计，以及概念、逻辑、物理三层数据库设计和用户聊天模块流程图、服务端与客户端模块说明。目前已有1391人学习下载，可帮助读者快速理清聊天系统的设计思路、模块划分与文档撰写框架，对照完成自己的课程设计任务。

1. 从一份课程设计文档说起：仿QQ聊天系统到底能跑通什么

如果你手头正躺着一份《仿QQ聊天系统课程设计.doc》，打开一看目录从绪论、需求分析一路排到编码和参考文献，却不知道这份文档里的东西能不能变成真能跑起来的 App，那这篇笔记就是写给你的。这份资源本质上是一套基于 Android 的移动即时通信系统设计文档，核心是用 Java 在 Android 端实现注册、登录、一对一聊天、添加好友、修改个人信息这几个模块，服务端数据操作交给 Bmob 云数据库来扛。它解决的不是"从零教你写安卓"的问题，而是给了一个已经拆解到数据库字段级别的完整方案——用户表 Users 里 objectId、Username、Password、sex、nick、头像六个字段怎么定，会话表 Bmobmsg 里 messageId、好友账号、发送接收时间、消息内容怎么存，文档里都列清楚了。适合谁？正在做课程设计、需要一份能照着复现的聊天系统骨架的在校开发者，或者想快速理解 C/S 架构下消息转发链路的后端新手。但要注意，文档给的是设计蓝图和关键代码片段，不是一键运行的完整工程，中间有不少需要自己补全的地方，这也是后面几章要重点拆的。

2. 需求与架构拆解：C/S 模式下消息怎么从 A 走到 B

2.1 功能边界与三个核心模块的职责划分

这份设计把整个系统划成三个单元：程序启动、用户界面、后台服务。程序启动负责初始化 Bmob SDK 和全局上下文，用户界面承载会话、联系人、设置三个主 Tab，后台服务则处理消息的接收、封装和转发。功能需求上，注册要求用户填入账号、密码、昵称、性别等信息，后台验证格式完整性和唯一性后写入 Users 表；登录时客户端把账号密码发给 Bmob 做校验，成功后拉取好友列表并返回会话界面；聊天模块是重头，用户选定对象后消息经后台转发，对方在线则实时显示，不在线则存库等下次登录拉取。

这里有个容易被忽略的设计点：文档明确写了"用户可以退出主界面，将聊天软件在后台运行，当有消息传入时，消息会用广播的形式显示"。这意味着消息接收不是靠界面轮询，而是靠 BroadcastReceiver 监听 Bmob 推送。这个选择直接决定了后面代码里为什么要注册 NewBroadcastReceiver，也决定了离线消息和在线消息的处理路径完全不同。

从选型理由看，用 Bmob 而不是自建服务端，对课程设计场景是合理的——它把增删改查和批量处理都封装好了，省掉了写 REST 接口和部署服务器的工作量。但代价是你会被 Bmob 的数据模型和推送机制绑死，比如 objectId 自动分配 10 位标识这个规则，就是 Bmob 特有的，换成自建后端就得自己设计主键生成策略。

2.2 数据库三张核心表的字段设计与关系

文档里数据库设计分了三层：概念结构设计给出总体 E-R 图，逻辑结构设计抽象出用户信息和会话信息两个实体，物理结构设计落到具体字段类型。我把关键字段整理成表，方便你对照建表：

建表时有几个坑要提前避开。第一，Username 在 Users 表里既是唯一索引又是登录凭据，意味着注册时如果没做唯一性校验，两个用户用同一个账号注册会直接覆盖或报错，文档在注册流程里提了"验证信息完整性验证信息格式"，但没明说唯一性检查，这是需要自己补的。第二，Bmobmsg 表的 Username 字段设了唯一约束，但聊天场景下同一个好友会有多条消息，这个唯一约束在逻辑上是矛盾的——实际实现时应该去掉唯一限制，或者用 messageId 做唯一键，Username 只做普通索引。第三，S/Rtime 用 data 类型存时间戳，查询历史消息时按时间倒序排列，Bmob 的查询 API 支持 order 排序，但要注意时区问题，服务端存 UTC 还是本地时间得统一。

2.3 消息转发的完整链路与安全设计落点

把消息从发送方到接收方的路径画清楚，后面写代码才不会乱。用户 A 登录成功后进入主界面，点击好友 B 进入 ChatActivity，输入内容点发送。客户端做三件事：把消息内容、发送时间、接收方 targetId 封装成 BmobMsg 对象；调用 Bmob 的保存接口写入 Bmobmsg 表；同时通过 Bmob 的推送通道通知 B 端。B 端如果在线，NewBroadcastReceiver 收到广播后从消息表拉取这条消息，判断 fromId 是否等于当前聊天对象，是则添加到界面并重置未读标记，否则只更新未读数。如果 B 不在线，消息就躺在表里，等 B 下次登录时通过 initMsgData 查询历史消息加载出来。

安全设计这块，文档提了身份验证、访问控制、数据加密、防火墙四个方向，但落到实处的只有"为不同用户设计不同视图"和"每个登录用户设置密码"。这在课程设计层面够用，但你要清楚边界：密码是明文存还是哈希存，文档没写；Bmob 的传输通道默认是 HTTPS，但应用层没有额外的加密；访问控制靠的是 Bmob 的 ACL 权限，如果没配，理论上任何客户端都能查到全量消息。我一般会建议在保存消息时给 Bmobmsg 对象加上 ACL，只允许发送方和接收方读写，这一步文档里没提，但属于合格从业者应该补上的。

3. 从文档到可运行工程：客户端与服务端代码落地

3.1 聊天界面 ChatActivity 的初始化与消息加载

文档给了一段 ChatActivity.java 的代码，但它是片段式的，直接复制编译不过。我把它补成能跑的骨架，关键部分保留原逻辑：

public class ChatActivity extends ActivityBase implements OnClickListener, IXListViewListener, EventListener { private Button btn_chat_send; private XListView mListView; private EmoticonsEditText edit_user_comment; private String targetId = ""; private BmobChatUser targetUser; private static int MsgPagerNum; private MessageChatAdapter mAdapter; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_chat); // 从 Intent 取出聊天对象，序列化传递 targetUser = (BmobChatUser) getIntent().getSerializableExtra("user"); if (targetUser == null) { finish(); return; } targetId = targetUser.getObjectId(); initNewMessageBroadCast(); initView(); } private void initView() { mListView = findViewById(R.id.mListView); edit_user_comment = findViewById(R.id.edit_user_comment); btn_chat_send = findViewById(R.id.btn_chat_send); btn_chat_send.setOnClickListener(this); mListView.setPullLoadEnable(true); mListView.setXListViewListener(this); initOrRefresh(); } /** 从本地数据库分页读取历史消息 */ private List<BmobMsg> initMsgData() { List<BmobMsg> list = BmobDB.create(this).queryMessages(targetId, MsgPagerNum); return list; } /** 界面刷新：区分锁屏期间新消息和普通刷新 */ private void initOrRefresh() { if (mAdapter != null) { if (MyMessageReceiver.mNewNum != 0) { int news = MyMessageReceiver.mNewNum; int size = initMsgData().size(); for (int i = (news - 1); i >= 0; i--) { mAdapter.add(initMsgData().get(size - (i + 1))); } mListView.setSelection(mAdapter.getCount() - 1); } else { mAdapter.notifyDataSetChanged(); } } else { mAdapter = new MessageChatAdapter(this, initMsgData()); mListView.setAdapter(mAdapter); } } @Override public void onClick(View v) { if (v == btn_chat_send) { String content = edit_user_comment.getText().toString().trim(); if (TextUtils.isEmpty(content)) return; // 封装消息并发送 BmobMsg msg = BmobMsg.createSendMessage(this, content, targetId); BmobChatManager.getInstance(this).sendMessage(msg, new SaveListener() { @Override public void onSuccess() { mAdapter.add(msg); mListView.setSelection(mAdapter.getCount() - 1); edit_user_comment.setText(""); } @Override public void onFailure(int code, String err) { ShowLog("发送失败：" + err); } }); } } }

这段代码的逻辑说明：onCreate 里先取 targetUser，为空直接 finish，避免空指针；initMsgData 调 BmobDB 的 queryMessages 按 targetId 和分页号查本地缓存；initOrRefresh 里那个倒序循环是处理锁屏期间来了多条消息的场景，MyMessageReceiver.mNewNum 记录新消息数，循环从后往前取保证界面顺序正确。参数上 MsgPagerNum 控制分页，初始为 0，上拉加载时递增。容易翻车的地方是 targetUser 的序列化——BmobChatUser 必须实现 Serializable，否则 getSerializableExtra 返回 null，界面直接白屏。

3.2 新消息广播接收器的注册与消息去重

消息接收靠广播，注册和处理的代码文档里给了片段，我补全成完整实现：

private void initNewMessageBroadCast() { NewBroadcastReceiver receiver = new NewBroadcastReceiver(); IntentFilter filter = new IntentFilter(BmobConfig.BROADCAST_NEW_MESSAGE); filter.setPriority(IntentFilter.SYSTEM_HIGH_PRIORITY); registerReceiver(receiver, filter); } private class NewBroadcastReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { String from = intent.getStringExtra("fromId"); String msgId = intent.getStringExtra("msgId"); String msgTime = intent.getStringExtra("msgTime"); // 消息已入库，直接按 id 和时间取 BmobMsg msg = BmobChatManager.getInstance(ChatActivity.this) .getMessage(msgId, msgTime); if (msg == null) return; // 不是当前聊天对象的消息，不处理界面 if (!from.equals(targetId)) return; mAdapter.add(msg); mListView.setSelection(mAdapter.getCount() - 1); // 取消未读标记 BmobDB.create(ChatActivity.this).resetUnread(targetId); // 终结广播，防止重复处理 abortBroadcast(); } }

逻辑说明：注册时把优先级设成 SYSTEM_HIGH_PRIORITY，是为了让这个接收器比其他监听同一广播的组件先拿到消息，配合 abortBroadcast 截断，避免同一条消息被多个界面重复消费。参数上 fromId 是发送方 objectId，msgId 和 msgTime 联合定位消息记录。这里有个血泪经验：如果忘记调 abortBroadcast，主界面和聊天界面可能同时收到广播，导致消息在会话列表和聊天页各显示一次，看起来像重复发送。另外 registerReceiver 要在 onDestroy 里 unregister，否则 Activity 销毁后广播还在，内存泄漏是小事，崩溃是常事。

3.3 服务端数据操作与好友关系维护

服务端这块文档说"利用 Bmob 实现 Android 端与 Bmob 服务端的数据操作"，具体到代码就是几个封装好的 API 调用。注册时创建 BmobUser 并保存：

BmobUser user = new BmobUser(); user.setUsername(account); user.setPassword(password); user.setSex(sex); user.setNick(nick); user.signUp(this, new SaveListener() { @Override public void onSuccess() { // 注册成功，objectId 已自动分配 toast("注册成功"); finish(); } @Override public void onFailure(int code, String err) { // code 202 表示用户名已存在 toast("注册失败：" + err); } });

登录用 BmobUser.loginByAccount，成功后返回的 BmobUser 对象里带 objectId，这个 id 就是后续聊天时的 targetId。好友关系的维护，文档说"将各用户间的关系保存在服务器端"，实际做法是在 Bmob 里建一张 Relation 表，存 fromUser 和 toUser 两个字段，添加好友时插入一条记录，查询好友列表时按 fromUser 查。参数上要注意 Bmob 的查询默认最多返回 100 条，好友多了得分页。常见坑是注册时没处理 code 202 错误，用户重复注册直接崩，得在 onFailure 里判断错误码给友好提示。

4. 避坑与排查：那些文档没写但一定会遇到的问题

4.1 消息发送成功但对方收不到

现象：A 端显示"已发送"，B 端界面没反应，退出重进才看到消息。原因通常是 B 端的广播接收器没注册成功，或者 Bmob 的推送通道在后台被系统杀了。Android 8.0 以后后台服务限制变严，如果没做前台服务或没申请忽略电池优化，应用切后台几分钟推送就断了。解决办法是在 Application 里初始化 Bmob SDK 时开启推送，并在主界面启动一个前台服务保活，或者引导用户把应用加入电池优化白名单。排查时先看 B 端 logcat 有没有收到 BROADCAST_NEW_MESSAGE，没有就是推送没到，有就是接收器逻辑问题。

4.2 聊天记录重复显示

现象：发一条消息，聊天界面出现两条一模一样的。原因有两个可能：一是发送成功后本地 add 了一次，广播回来又 add 了一次；二是广播没 abortBroadcast，多个接收器都处理了。解决是在发送成功的回调里给消息打个本地标记，广播接收时判断 msgId 是否已在 adapter 里，已存在就跳过。更彻底的做法是发送时不直接 add，统一走广播更新界面，保证单一数据源。

4.3 好友搜索搜不到已注册用户

现象：明明对方已经注册，搜索 456 用户提示不存在。原因是 Bmob 的查询默认只返回当前用户有权限读的数据，如果 Users 表的 ACL 设成了仅自己可读，那搜谁都搜不到。解决是在 Bmob 后台把 Users 表的读权限放开给所有登录用户，或者单独建一张公开的用户索引表只存 objectId 和 Username。参数上查询时用BmobQuery<BmobUser>().addWhereEqualTo("username", keyword)，注意 username 大小写敏感，用户输入得统一转小写再查。

4.4 退出登录后还能收到消息

现象：用户点了退出，回到登录页，结果还能收到之前账号的消息推送。原因是退出时只清了本地用户缓存，没解绑 Bmob 的推送绑定。解决是在 logout 回调里调 BmobPush 的 unbind 方法，把当前设备的推送绑定解除，同时 unregister 所有广播接收器。这个坑在课程设计答辩时特别容易被问到，因为演示时一般只登一个账号，不会暴露，但实际多账号切换就翻车。

4.5 聊天时间显示错乱

现象：消息列表里时间一会儿是今天，一会儿是 1970 年。原因是 S/Rtime 存的是 data 类型，客户端格式化时没做时区转换，或者从 Bmob 取出来的是 UTC 时间戳直接当本地时间用了。解决是统一在客户端做一次时区转换，用 SimpleDateFormat 设成 GMT+8 再格式化，或者存的时候就直接存格式化好的字符串。参数上注意 Bmob 的 Date 类型返回的是 UTC 毫秒数，跟 System.currentTimeMillis() 差 8 小时。

5. 进阶技巧：把课程设计改成能拿得出手的作品

如果你想让这份课程设计从"能跑"变成"能看"，有几个投入产出比很高的改造点。第一是消息列表的分页加载，文档里 MsgPagerNum 只提了概念没实现，你可以在 XListView 的 onLoadMore 里把 MsgPagerNum 加 1 再调 initMsgData，配合 Bmob 的 limit 和 skip 参数做真分页，数据量大了也不会卡。第二是消息状态的回执，文档代码里有 STATUS_SEND_SUCCESS 和 progress_load 的切换，但没做"已读"回执，你可以在 Bmobmsg 表加一个 isRead 字段，对方进入聊天界面时批量更新，发送方通过查询这个字段显示"已读"。

第三是本地缓存策略。现在每次进聊天界面都从 Bmob 拉全量消息，网络一差就转圈。我一般会先用 BmobDB 查本地 SQLite 缓存立即渲染，再异步拉服务端增量更新，这样冷启动体验会好很多。BmobDB 的 queryMessages 本身就支持分页，把 MsgPagerNum 用起来就行。

第四是安全加固。前面提过 Bmobmsg 的 ACL 要配，具体做法是在保存消息时调msg.setACL(new BmobACL())，给发送方和接收方各授一个读写权限，其他用户查不到。密码这块，Bmob 的 BmobUser 默认会对密码做哈希，不用自己再加密，但如果你自己建表存密码，记得用 BCrypt 或 SHA-256 加盐。

验证改造是否成功，我习惯用两个账号在真机上互发 50 条消息，然后杀掉一个进程再发 10 条，看离线消息能不能在重进后按时间顺序完整加载，同时检查有没有重复和乱序。这个测试能覆盖广播、分页、缓存、时间格式化四条链路，跑通了基本就没大问题。

从那以后我每次拿到这种课程设计文档，都强制先跑一遍"双账号+杀进程+离线消息"的验证流程，再动手改代码，不然改到一半发现消息链路本身就有问题，返工成本太高。希望这份拆解能帮你少走点弯路，把这份仿 QQ 聊天系统真正跑起来。

本文还有配套的精品资源，点击获取