getMessages

获取指定会话历史消息。

此方法先从本地获取历史消息，本地有缺失的情况下会从服务端同步缺失的部分；从服务端同步失败的时候会返回非 0 的 errorCode，同时把本地能取到的消息回调上去。 必须开通历史消息云存储功能。

Parameters

获取指定会话历史消息。

获取指定会话的连续消息，会先从本地数据库获取指定数量消息，然后根据这些消息所在会话的连续置信区间来判断，这些消息中间是否有断档遗漏（即本地存储消息与服务端存储不同步）如果本地数据库的消息有断档， 会触发一次从服务端获取断档处的消息，然后跟本地消息合并再返回给调用者。

此方法先从本地获取历史消息，本地有缺失的情况下会从服务端同步缺失的部分；从服务端同步失败的时候会返回非 0 的 errorCode，同时把本地能取到的消息回调上去。 必须开通历史消息云存储功能。

以下为单群聊场景下的详细说明：

产生消息断档的典型情况有： 1. 超过消息离线存储最长时间未登录。例如默认离线消息的最长存储时间是 7 天，若用户连续 10 天未登录，当再次登录时， 服务器只会推送最近 7 天的离线消息，那么更早的 3 天内的消息本地就没有，这段期间称为断档。 2. 客户启用了群组离线消息存储条数配置。例如配置群组离线消息存储条数为 100 条，若用户离线期间， 该群离线消息超过 100 条，当再次登录时，服务器只会推送最后的 100 条消息，那么更早的消息本地也没有，这段期间称为断档。

本地存储消息是否断档的判断逻辑： 当连接成功后，服务器主动下发消息分为两种情况，一种是单条直发，一种是通知拉取（一般是会话消息量较大的情况）。还有一种 是客户端主动拉取消息。对于通知拉取和主动拉取，服务端返回结果中都带有连续置信区间的起始和终止时间戳，客户端会将这段时 间记录在本地数据库中，视为该会话的连续置信区间。如果用户一直在线情况下，收到单条直发消息，也会将当前消息的时间戳与本 地存储的该会话置信区间做拼接，视为连续置信区间。当用户调用此接口时，会根据用户传入的获取消息条数 count 来从本地数据库 中获取，如果获取的所有消息时间戳都在连续置信区间内，就视为无断档，可直接返回给用户。否则会以断档处时间戳为起点，向服 务端拉取历史消息，拉回来消息的同时，会更新该会话的连续置信区间，并将入库类型消息与本地数据库的消息合并，再返回给用户。

结果回调中，messages 为本次拉取到的消息列表，timestamp 为下次拉取的起始时间戳，isRemaining 为服务器是否还有未拉取的消息。 分为以下几种情况： 1. messages 数量等于 count。代表本次的调用已拉取到 count 条消息，且消息是连续的。用户可根据 isRemaining 结果决定是否要继续拉取。 2. messages 数量小于 count（包括 0 的情况），且 isRemaining 为 false。 代表本次调用已拉取到所有连续消息，且服务端也无更多消息可供拉取。 3. messages 数量小于 count（包括 0 的情况），且 isRemaining 为 true。 代表本次调用只拉取到这么多连续消息，虽然尝试从服务端拉取断档处消息，但拉回来的都是不存储类型的消息。 同时服务端还有更多消息可供拉取，需要用户使用返回的 timestamp 继续拉取。

以下情况需要注意： 1. 调用此接口返回的消息，会在本地标记为连续消息。如果后面调用了删除消息相关接口从本地数据库删除了已连续的消息， 会认为此处仍然连续无断档。下次再调用此接口时，不会从服务端拉取此处已删除的消息。 2. 当用户一直在线时，如果服务端通过 ServerAPI 将当前用户踢出某群，过一段时间再加回来。 如果服务端执行以上操作的同时什么都不做，客户端是无感知的。用户在被踢出群的这段时间内，此群消息接收不到， 等加回来后又可以收之后的消息，但 SDK 会认为此间消息一直连续无断档，下次调用此接口时，不会从服务端拉取退群期间的消息。 如果想补偿这段时间消息，需要调用拉取该时段的远端消息接口。为避免执行上述操作时，客户端无感知， 建议在服务端执行踢人操作前，同时发送一条小灰条消息通知被踢人，避免用户误解。

Parameters