最近几个月一直在做IM的项目,遇到很多技术难点,查阅很多资料,请教了很多大神级别的开发者,入了很多坑,终于搞定了一个IM的项目,也算是在IM开发中积累了一些小经验.基本实现了消息(文本,语音,图像,视频,位置)收发,未发的消息草稿功能,消息的转发,消息的复制,消息列表的置顶等功能。
IM项目在服务端不具备消息漫游功能,这样需要在移动端,将大量信息保存到本地,iOS选择了使用FMDB来实现。
FMDB是对sqlite3.0的封装的数据库框架,用OC方式封装了sqlite C的API,FMDB相比于iOS平台的sqlite和Core Data来讲优势明显:
(1) 使用起来更加面向对象，省去了很多麻烦、冗余的C语言代码。
(2) 对比苹果自带的Core Data框架，更加轻量级和灵活。
(3) 提供了多线程安全的数据库操作方法，有效地防止数据混乱。
在此之前,我也在项目使用到了数据库的持久化,比如像接口json文件的持久化,历史搜索,推送数据的缓存等,而这些数据库创建,往往显得简答而单一;只需创建一个静态数据库(DB),在添加表1,表2,表3。对于大多数App而言,一个数据库不超过5张表,这些表之间没有任何关联,平常也就注意版本升级就可以了;似乎客户端数据库持久化尽在掌握中。 ...
我们知道IM会产生大量的数据,这些数据不是一两张表就能完成数据存储,而且表与表之间相互关联,操作了其中一张表,可能需要引起另外一张表数据的改变; IM的UI界面搭建和数据库的关联保持一致,这样才能有效去实现需求的开发。显然简单掌握数据库表的增删改查操作是无法满足IM数据持久化的。
上图是项目中数据库框架,结构相比一般项目中数据库明显复杂了很多,遇到的技术难点归纳如下:
1 创建消息列表界面;需要将conversationalist(单聊列表) groupChatslist(群聊列表) rmsdetail(聊天详情)的数据,通过字段update_date进行排序处理并用UITabView显示在界面上,如果对3张单独处理,很难到达预期的效果,而且数据查询速度慢,处理逻辑复杂,可读性和可维护性非常差,为了解决这些问题这里引入了数据库视图。
数据库视图是由一张表或两张以上的表导出的表,视图和表不同;视图是个虚表,不能存储数据。
数据库视图根据表多少可以分为单表视图和多表视图,单表视图一般用于查询和修改会改变基本表的数据; 多表视图一般用于查询不会改变基本表的数据。
视图的优点:
(1) 简化操作,把经常用的表定义成视图。
(2) 安全可靠,用户只能查询和修改能看到的数据。
(3) 逻辑上的独立性，屏蔽了真实表的结构带来的影响。
视图的缺陷:
(1) 在视图上多表查询,将数据库变成一个复杂的结合体,需要花费一定的时间。
(2) 当用户试图修改视图的某些信息时，数据库必须把它转化为对基本表的某些信息的修改，对于简单的视图来说,这是很方便的;但是对于比较复杂的试图，可能是不可修改的。
FMDB 创建视图:(view_conversations)
@"CREATE VIEW IF NOT EXISTS view_conversations AS SELECT \
conversationalist._id AS conv_id, \
create_date, \
update_date, \
type, \
is_stick, \
stick_time, \
conversationalist.ower_iphone_number AS ower_iphone_number, \
userlogin_number, \
recipient_numbers, \
recipient_number_ids, \
unread_message_count, \
priority, \
is_notification, \
conversationalist.is_black AS is_black, \
is_delete, \
groupChatslist._id AS group_id, \
name, \
groupChatslist.status AS status, \
organizer_number, \
chairman_number, \
owner_number, \
session_identity, \
groupChatslist_id, \
is_show_in_contact, \
group_type, \
group_version, \
rmsdetail._id AS rms_id, \
// AS 视图查询按照该字段,需要AS 声明
sender_number, \
peer_numbers, \
date, \
timestamp, \
is_read, \
rmsdetail.is_black AS rms_is_black, \
rmsdetail.status AS rms_status, \
box_type, \
content, \
message_type, \
error_code, \
file_name, \
file_type, \
file_path, \
file_expire_date, \
file_thumb_path, \
file_trans_id, \
file_media_duration, \
file_size, \
file_trans_size, \
file_download_url, \
geo_latitude, \
geo_longitude, \
geo_radius, \
geo_free_text, \
imdn_msg_id, \
imdn_type, \
is_burn_after_reading, \
is_silence, \
is_direct, \
is_carbon_copy, \
is_at_msg \
FROM conversationalist LEFT OUTER JOIN groupChatslist ON conversationalist._id = groupChatslist \
LEFT OUTER JOIN rmsdetail ON conversationalist.latest_ rmsdetail _id = rmsdetail._id;"
view_conversations的数据查询( 如查询当前用户的所有聊天信息)
+ (NSArray *)loadAllMessage
{
// 查询sql
NSString* where = [NSString stringWithFormat:@"(owner_number is null or compare_number('%@',owner_number)==1) and is_delete!=1",@"当前用户手机号136........."];
// 查询结果 FMDBMessage 封装类 sharedInstance单例
NSArray* array = [[FMDBMessage sharedInstance] query:@"view_conversations"
columns:@"*"
where:where
orderBy:@" update_date desc "];
return array;
}
删除view_conversations视图
DROP VIEW view_conversations
2 在做消息列表删除等操作时,需要触发2张表,对于操作需要修改2张以上表的我们使用了数据库触发器 ,sql触发器是一种特殊类型的存储过程,不由用户直接调用,它是在指定的表中发送改变自动生效。
FMDB生成触发器:
+ (NSString *)sqlWithRmsTigger
{
return @"CREATE TRIGGER IF NOT EXISTS rms_update_conversation_read_on_update AFTER UPDATE OF is_read ON rms \
BEGIN \
UPDATE conversationalist SET unread_message_count = (SELECT count(*) FROM rmsdetail WHERE is_read = 0 AND rmsdetail.conv_id = NEW.conv_id) \
WHERE conversationalist._id = NEW.conv_id; \
END;";
}
结语:
客户端选择使用FMDB本地数据持久化,实现简单的IM数据存储还是比较方便的,但随着项目的深入,FMDB在使用起来还是有很多缺陷,如数据库迁移非常麻烦,大量的sql语句,给后期维护代码增加了难度,我们正在考虑使用Realm,在客户端数据库持久化道路上还需要很长路要走,因本人技术水平有限,可能有错误的地方,希望多多指教,大家一起学习进步!
