LeanCloud 调研

导入SDK

我们项目使用了cocoaPos，AVOS支持pod导入，编辑Podfile文件:

pod 'AVOSCloud'#使用聊天组件的话引入IM模块pod 'AVOSCloudIM'

update 即可

App内注册

使用我们在AVOS平台上注册App时生成的App Id 和 App Key,在我们的程序内部注册：

[AVOSCloud setApplicationId:AVOSApplicationId clientKey:AVOSClientKey];

实时通信核心概念

ClientId 用户 登录

实时通信中，每个终端都称为一个Client，并有一个唯一的ClientId 标识。这个ClientId由应用自己定义，并且是长度不大于64的字符串。
默认情况下，LeanCloud服务允许一个ClientId登录多台设备，也允许一台设备上登录多个ClientId，假如限制用于只在一台设备上登录，可以在登录时明确设置当前设备的tag，服务检测到同一tag的设备出现冲突时，会踢出已存在设备上的登录状态。当完成登录后，应用就不必再关心服务的连接状态，SDK会自动检测并重连，在前台时一直保持连接状态，在后台会开启推送。

在线状态

SDK和REST API 提供主动查询的机制供开发者查询某个用户的登录状态。

对话 Conversation

用户登录后与其他人进行消息沟通，即开启了一个对话。开始聊天时，首先创建一个对话，然后邀请其他人加入这个对话，然后所有的沟通都在这个对话中进行。没创建一个对话，都会把他加入到Conversation表中。可以在存储->数据中查看。
Conversation表中每个字段意义如下：

除了在各平台的 SDK 里面可以调用 API 创建对话外，我们也提供 REST API 可以让大家预先建立对话：对话的信息存储在 _Conversation 表中，你可以直接通过 数据存储相关的 REST API 对其进行操作

对话 类型

通信基本分为单聊、群聊、聊天室、公众号(机器人)几种方式，对话又分为普通对话、暂态对话、系统对话几种方式

单聊

单聊即两个Client之间的对话，公开与否（能否让其他人看到这个对话存在）由应用层自己控制。一般而言，它是私密的，并且加入新的成员之后，会切换到新的对话（当然，也可以依然不离开当前对话，这一点还是由应用层来决定）。 由普通对话实现

群聊

就是两个（含）以上 client 之间的对话，一般而言，可以添加和删除成员，并且会赋予群聊一个名字。随着成员的减少，群聊也可能只有两个甚至一个成员（成员的多少并不是区分群聊和单聊的关键）。群聊能否公开（譬如支持名字搜索），由应用自己决定。 由普通对话实现

聊天室

很多应用使用的开放聊天室、弹幕、网页直播等都可以抽象成「聊天室」，它与群聊类似，都是多人参与的群组，但是也有一些区别：其一在于聊天室人数可能远大于群聊人数；其二在于聊天室强调的是在线人数，所有参与者进入聊天界面就算加入，关闭界面就算退出，所以聊天室不需要离线消息和推送通知，在线成员数比具体成员列表更有意义。 由暂态对话实现。

公众号、机器人

对全部或者部分用户可见（由应用开发者决定）的账号，开发者可以利用这个账号给用户发广播通知，用户也可以通过这个账号反馈内容给开发者，开发者可以在后台看到消息，也可以利用 API 或 Web Hook 将自己的业务系统集成进来。 由系统对话实现

下图是每种状态的对话的区分：

创建对话

一般来说，普通对话由SDK创建，用于用户间自发的通信。暂态对话和系统对话一般由系统使用REST API先创建好，再下发给用户。假如我们创建一个公众号的话，可以在聊天中默认创建一个我们公司自己的对话，并且id已经创建好。

消息

实时通信服务，允许发送不大于5KB的文本消息。
消息分为「普通消息」和「暂态消息」。LeanCloud 云端对于普通消息会提供接收回执、自动持久化存储、离线推送等功能。 但是暂态消息，则不会被自动保存，也不支持延迟接收，离线用户更不会收到推送通知，所以适合用来做控制协议。 譬如聊天过程中「某某正在输入中…」这样的状态信息，就适合通过暂态消息来发送，而用户输入的正式消息，则应该用普通消息来发送。

LeanCloud 对普通消息提供「至少一次」的到达保证，并且在官方 SDK 中支持对消息的去重，开发者无需关心。除了基于「推」模型的消息机制，我们还提供消息记录的机制允许 SDK 和 REST API 通过「拉」的方式获取任意时间点前的消息。目前 LeanCloud 对消息记录提供永久存储。

开发者可以通过 SDK 或 REST API 发送消息。 SDK 通常用于最终用户发送消息，而 REST API 是开发者从服务器端发送消息的接口。当从 REST API 发送消息时，开发者可以指定消息的发送者、对话 ID，对于系统对话还可以指定消息的接收者。

富文本消息

服务预先制定好了几个消息类型，如
文本消息
图片
视频
音频
位置
基本都是Json格式

离线消息

每次用户登录后，服务会将离线消息下发到 Client ：
1.服务端对每个对话推送至多20条消息，在用户登录后以新消息的形式到达客户端
2.服务器返回离线期间产生的对话列表和未读消息数，开发者可以根据这个通知拉取离线消息记录收取离线消息，这种方式下开发者对消息的数量可以完全的控制；

离线推送通知

iOS 和 windows phone 平台的用户，在完成登录时，SDK 会自动关联当前的 Client ID 和设备。关联的方式是通过设备订阅名为 Client ID 的 Channel 实现的。开发者可以在数据存储 的 _Installation 表中的 channels 字段查到这组关联关系。在实际离线推送时，系统根据用户 Client ID 找到对应的关联设备进行推送。

另外，由于实时通信触发的推送量比较大，内容单一，这部分记录不会保存到消息菜单的推送记录。

权限和认证

为了保证聊天通道的安全，可以对所有操作进行签名要求。流程如下：

0.Client进行操作
1.请求服务器，生成签名
2.服务器生成时间戳，签名和随机字符串下发给Client
3.Client获得签名后编码到请求中发送给LeanClound服务器
4.LeanClound服务器对签名进行认证，通过后进行后续操作

签名采用 Hmac-sha1 算法，输出字节流的十六进制字符串（hex dump）。针对不同的请求，需要拼装不同组合的字符串，加上 UTC timestamp 以及随机字符串作为签名的消息。