Skip to content

Commit

Permalink
注意事项
Browse files Browse the repository at this point in the history
  • Loading branch information
mengyaoyao committed Apr 27, 2017
1 parent f55cbfe commit 083d4c3
Showing 1 changed file with 3 additions and 1 deletion.
4 changes: 3 additions & 1 deletion CocoaAsyncSocket_TCP/ViewController.m
View file
Original file line number Diff line number Diff line change
Expand Up @@ -246,8 +246,10 @@ - (void)sendMessageTimeOutWithTag:(long)tag
解决办法：离线消息服务端全部进行拼接或者以jsonArray方式，并协议分割方式，客户端收到后仅需仅需切割，直接在角标上进行总数的相加，并直接更新最后一条消息即可。亦或者，设置包头信息，告知每条消息长度，切割方式等。
<<<<版本兼容性问题处理>>>>
其实 , 做IM遇到最麻烦的问题之一 , 就应当是版本兼容问题 . 即时通讯的功能点有很多 , 项目不可能一期所有的功能全部做完 , 那么就会涉及到新老版本兼容的问题 . 当然如果服务端经验足够丰富 , 版本兼容的问题可以交于服务端来完成 , 客户端并不需要做太多额外的事情 . 如果是并行开发 , 服务端思路不够长远 ,或者产品需求变更频繁且比较大.那么客户端也需要做一些相应的版本兼容问题 . 处理版本兼容问题并不难 , 主要问题在于当增加一个新功能时 , 服务端或许会推送过来更多的字段 , 而老版本的项目数据库如果没有预留足够的字段 , 就涉及到了数据库升级 . 而当收到高版本新功能的消息时 , 客户端也应当对该消息做相应的处理 . 例如,老版本的app不支持消息撤回 , 而新版本支持消息撤回 , 当新版本发送消息撤回时 , 老版本可以拦截到这条未知的消息类型 , 做相应的处理 , 比如替换成一条提示"该版本暂不支持,请前往appstore下载新版本"等. 而当必要时 , 如果整个IM结构没有经过深思熟虑 , 还可能会涉及到强制升级 .
其实 , 做IM遇到最麻烦的问题之一 , 就应当是版本兼容问题 . 即时通讯的功能点有很多 , 项目不可能一期所有的功能全部做完 , 那么就会涉及到新老版本兼容的问题 . 当然如果服务端经验足够丰富 , 版本兼容的问题可以交于服务端来完成 , 客户端并不需要做太多额外的事情 . 如果是并行开发 , 服务端思路不够长远 ,或者产品需求变更频繁且比较大.那么客户端也需要做一些相应的版本兼容问题 . 处理版本兼容问题并不难 , 主要问题在于当增加一个新功能时 , 服务端或许会推送过来更多的字段 , 而老版本的项目数据库如果没有预留足够的字段 , 就涉及到了数据库升级 . 而当收到高版本新功能的消息时 , 客户端也应当对该消息做相应的处理 . 例如,老版本的app不支持消息撤回 , 而新版本支持消息撤回 , 当新版本发送消息撤回时 , 老版本可以拦截到这条未知的消息类型 , 做相应的处理 , 比如替换成一条提示"该版本暂不支持,请前往appstore下载新版本"等. 而当必要时 , 如果整个IM结构没有经过深思熟虑 , 还可能会涉及到强制升级 .
<<<<注意事项>>>>
1. 在搭建体系时 , 尽量把数据和业务逻辑都抽取到ChatHandler中 , 控制器里只需要拿到直接可用的消息模型即可 . 不然后期功能增多 , 控制器里的逻辑和代码会越来越多 ,并且还需要考虑控制器的生命周期问题 , 比较麻烦
以上仅为大体的思路 , 实际上搭建IM , 更多的难点在于逻辑的处理和各种细节问题 . 比如数据库,本地缓存,和服务端的通信协议,和安卓端私下通信协议.以及聊天UI的细节处理,例如聊天背景实时拉高,图文混排等等一系列麻烦的事.没办法写到很详细 ,都需要自己仔细的去思考.难度并不算很大,只是比较费心.
Expand Down

0 comments on commit 083d4c3

Please sign in to comment.