引入问题
在某某公司从事ios开发时一个「某某」app项目，其中用到sqlite进行本地化存储，存储内容为服务端透传的通知消息，获得消息的方式有两种
- API获取消息列表
- 透传消息（一条一条过来）
消息结构大致如下
class NotificationEntry: NSObject {
var msgId:Int! 消息id
var msgGroup:Int! 消息分组
var msgType:Int! 消息类型-子分组
var msgTime:Int? 消息时间戳
var msgRead:Int! 消息是否已读
var msgContent:NSDictionary? 消息主体内容
var contentObj:NSObject? 消息主体内容对象
}
根据msgGroup和msgType 对应不同的消息主体
譬如msgGroup为评论，则msgType分为主评论和回复评论
msgGroup为账户消息，那么msgType分为支付，提现，充值等。
需要实现的需求为
- 消息首页显示个分组列表，并显示每个分组的未读数
2.点击分组，进入另一页显示分组中所有消息（并且将msgType相同的消息再进行一次聚合，点击聚合item才显示聚合中所有消息）
3.消息首页根据分组排序
4.具体消息点击可进入相应页面
实现功能，本地使用两张表
let sql_notification_table = "create table if not exists \(TABLE_NAME_NOTIFICATION)(serial integer primary key,userid text,msgid integer,grouptype integer,messagetype integer,content text,msgtime datatime,isread integer,videoId integer,commentId integer)"
let sql_group_table = "create table if not exists \(TABLE_NAME_GROUP)(userid text,groupid integer,message text,unreadcount integer,count integer,latestmsgid integer,serial interger)"
一些问题整理
-
UI上要实现两次聚合针对于msgGroup和msgType
* 首页数据的聚合依赖sql_group_table表，从中查询即可，但是每次 sql_notification_table的更新需要同时计算并更新sql_group_table表。在程序初始化的时候，通过API获取消息列表时同时更新sql_group_table和sql_group_table即可。每次通过透传收到的消息也需要更新这两张表。 使用sql_group_table表目的是为了减少首页显示时的大量计算。将时间分散在更新sql_group_table表。 * msgType分组通过查询sql_notification_table表实现。 数据库的多线程运行
io操作放在后台线程运行，所以我将我的数据库实现为线程安全，使用的是smdb
var fmdbQueue:FMDatabaseQueue!;
self.fmdbQueue.inDatabase({ (db) in
//do db operation
})
将所有操作都提交到一个队列中执行
- 数据增长时效率的问题
- 初始化时通过API获取消息列表
* 数据对象后台实例化 * 数据库写入优化--使用事务
//异步更新Notification表中的items
self.fmdbQueue.inTransaction({ (db, rollback) in
db.open()
db.beginTransaction()
self.updateNotificationItems(items, db: db, userid: userid)
db.commit()
db.close()
})
2. 展开聚合时有大量数据的展示问题，虽然是在后台线程，不过时间太长依然会影响体验
* 数据库查询分页，每次取10条
* 在后台运行查询
- 数据结构修改后和服务端兼容的问题
-
数据结构修改后，本地数据库支持升级
-
// 先判断是否初始化过数据库
let dbCurrentVersion:Int? = readProperties(SK_NOTIFICATION_CURRENT_VERSION) as? Int
if(dbCurrentVersion != nil && dbCurrentVersion >= m_dbMinVersion) {
return;
}
self.dropTables();
self.createTables();
// 设置一个最小版本号，如果低于这个版本，就需要执行升级
saveProperties(SK_NOTIFICATION_CURRENT_VERSION, val: m_dbMinVersion);
```
* 服务端API接口向前兼容，这样解决老客户端数据结构不可用的问题
* 服务端API接口分版本，客户端提示版本不兼容提示用户升级app
- 由于这块功能多变，所以需要随时应对数据修改和视觉修改
定义接口
@objc protocol NoticeCommon:class {
func title()->String
optional func cell(tableView: UITableView,row: Int,datas:NSArray,controller:NoticeCellDelegate?)->UITableViewCell
func cellheight(data:NotificationEntry)->CGFloat
func didClick(msgType:Int,data:NotificationEntry,controller:UIViewController)
func createContentObj(val:NSDictionary,msgType:Int)
func getListWithGroup()->NSArray;
func groupId()->Int;
//for set
optional func setcell(tableView: UITableView,row: Int,datas:NSArray,controller:ENoticeSetCellDelegate?)->UITableViewCell
//获取集合数据源
optional func createSet()->NSArray;
//集合cell的高度
optional func setCellHeight(data:NoticeSetEntry)->CGFloat;
//点击集合
optional func doClickSet(data:NoticeSetEntry,controller:UIViewController)
//获取单一集合对应的数据源
//optional func getNotices(getid:Int)->NSArray
}
对于二次聚合类实现这些方法，这样对视觉的修改就集中到一处进行。
class NoticeFactory: NSObject {
class func create(groupid:Int) -> NoticeCommon?
{
if(groupid == GroupTypeAccount)
{
return AccountNoticeUtility()
}
else if(groupid == GroupTypeComment)
{
return CommentNoticeUtility()
}
else if(groupid == GroupTypeAudit)
{
return AuditNoticeUtility()
}
else if(groupid == GroupTypeForward)
{
return ForwardNoticeUtility()
}
else if(groupid == GroupTypeAttend)
{
return AttendNoticeUtility()
}
else if(groupid == GroupTypeLike)
{
return LikeNoticeUtility()
}
else if(groupid == GroupTypeAuthen)
{
return AuthenNoticeUtility()
}
else if(groupid == GroupTypeShare)
{
return ShareNoticeUtility()
}
else if(groupid == GroupTypeSysterm)
{
return SystemNoticeUtility()
}
return nil
}
}
根据group获取对应的对象，新加消息类型时在此处添加即可
* 数据结构调整时暂时不考虑数据迁移问题。服务端保存完整的数据，每次启动都拉取数据。
###在开发中的一些衍生问题的思考
* 通过API获取数据列表时在用tableview显示数据时如避免初始化数据对象时的耗时（列表比较大，数据比较复杂）
* 拉取条数进行分页，这样在获取数据后进行初始化等应该也能在一个合理可接受范围
* 将数据结构初始化分散到显示时，由于tableview的重用机制，这个耗时应该是在可接受范围，有待测试
* 如我这个case，如果数据达到几千上万条，在app初始化拉取数据时，API请求耗时+上对象初始化耗时，再加上数据库写入耗时，这个时间应该会很长，这个如何解决？由于我获取到数据后必须要解析并写入数据库，那么API请求时间和初始化对象时间和数据库写入 这三块时间是必须消耗的， 如何解呢？
* app初始化时拉取服务端数据只在首次打开时执行，以后就不需要再拉取了，因为以后的是通过透传过来的。当然也存在app第一次安装时就存在大量数据的情况（之前用账号使用过导致许多数据存在），这个情况再app打开消息页面时做的和微信一样拉取数据再更新UI。然后显示未读条数。这个体验获取可以接受。增加一个拉取group的API，保证进入消息首页时能看到group分组。 拉取所有数据后再更新本地group。
###其他一些数据库优化策略整理
希望可以相互交流切磋. 附上我的微信号关注我哈
