聊天室和其他模块最大的区别在于聊天室类人数多，单位时间消息量巨大，在这种场景下如果开发者还是按照处理群的逻辑来处理聊天室就会引起很多的问题，下面主要列举一下常见的问题。

Q：登录云信聊天室是否要求先登录 IM？

云信的聊天室服务和云信账号绑定，所以必须要求先进行 IM 鉴权后才能够使用聊天室接口。

Q：云信是否支持匿名登录？

目前云信并没有在服务层直接支持匿名登录，但是业务层可以模拟匿名登录的状态。从原理上来说，所有的匿名登录只是一种比较便捷且不需要用户进行输入用户名密码的有名登录，换言之，所有的匿名登录在实现上仍旧需要向服务器提交一定的用户信息以做鉴权。所以业务方可以事先分配云信账号的方式进行匿名登录。

Q：进入聊天室后断线怎么办？

进入聊天室后因为网络状况引起的掉线，云信 SDK 会自动进行重连，直到重新进入聊天室为止，不需要上层开发做任何干预。

Q：如何获取聊天室内用户信息？

聊天室内获取用户信息的场景大致有两种：

• 聊天室内有用户发消息，接受者需要显示发送方的名字；

• 用户在浏览聊天室内用户信息。

第一种情况：上层开发无需主动调用获取用户信息的接口，因为我们已经在每条消息填充了消息发送者的基本消息（目前主要是用户 Id， 昵称和头像），如果需要更详细的数据，推荐在调用进入聊天室接口时填充到拓展信息中，拓展信息同样会出现在后续该用户发出的所有消息中，包括通知消息，如进入聊天室和离开聊天室的通知。

第二种情况：调用聊天室获取用户接口返回的用户对象中同样已经包括用户 Id，昵称，头像信息和拓展信息，无需再次请求用户信息。

错误姿势：在聊天室中每收到一条消息就去获取当前消息发送者的详细用户信息。

原因在于：聊天室内的人数众多，消息量巨大，以一个聊天室内有 1W 人为例，假设平均一秒钟有 100 条消息，如果按照上面的逻辑操作，每一秒就会有 100 W 次用户信息的请求发送给服务器，明显是不可取的，同时客户端也会因为在 1 分钟内发送了过多的用户信息请求（每分钟 6000 条）而触发服务器频控。

Q：如何优雅地发送聊天室消息？

聊天室内调用消息发送接口和调用群/个人的消息一样，并没有什么特殊的要求。但是由于特殊的业务需求，往往会遇到和群里或者个人消息完全不同的问题。

举例说明：
直播间的点赞消息，经常需要发送各种连击点赞，几秒内刷出几十条消息，甚至上百条消息。而这样很容易触发服务器频控，同时也导致接收端处理不过来（下个问题会具体分析这种情况）。

解决方案：
合并消息。将多个点赞消息合并为一个点赞消息，同时这个点赞消息包含当前消息内有多少个赞的信息。处理流程：当用户点赞时，缓存当前的赞信息，并进行计时（如 0.3s），那么当计时时间触发时或者赞数积累到阈值时，将当前的赞打包成一个点赞消息并发送。

Q：如何优雅地接收聊天室消息？

和发送消息不同，聊天室内接受消息会有各种极限问题出现，主要诱因在于聊天室内的单位时间内消息量非常大，需要对这种极限情况进行合理处理。一个合理地假设是聊天室内每秒收到 100 条以上的消息很常见，那么我们就来看下每秒收到 100 条消息对 App 来说是个什么样的情况。

一般而言，一个 App 要达到流畅的水准，需要界面保持每秒 60 帧，那么意味着每一帧需要处理大约两条消息，而 App 在收到这些消息后往往需要做动画，文字高度计算，界面重排版等工作，再算上界面本身的一些工作，很容易堵塞主线程，使得主线程卡顿甚至卡死。

那么怎么办呢？

• 合并消息通知

服务器在 1 秒内下发 100 条并不意味着客户端一定需要有 100 条消息通知，客户端可以选择性将这些消息合并，将 100 次每次一条消息的通知合并成几次每次几十条消息的通知，这使得上层需要处理的事件数大幅度减少（虽然消息量并没有变化）。而在云信这里，这一部分会由 SDK 自动完成。 1 秒内 100 条消息往往会被归并成大约 3-4 次通知，每次通知内附带 30 多条消息。

• 后台计算

上一步我们将消息通知进行归并，减少了消息的通知次数，这样变相减少了 App 被触发刷新界面的次数，但是消息总数并没有减少，仍旧有这么多消息需要放到界面上进行显示。而显示的第一步往往是需要计算对应的文本消息的尺寸以进行最终的排版，而这一部分如果放到 UI 线程中处理，仍会占用大量主线程时间，所以可以将这部分的计算放到后台线程中进行，等计算出最终的结果后再 dispatch 到主线程进行最终的控件添加和显示即可。 （虽然一般情况下 UI 相关的操作是需要在主线程中进行的，但是某些 UI 操作仍是可以在后台进行的）

• 估算

即便使用后台计算，某些计算仍旧会占用大量 CPU ，如计算文字高度，当我们调用系统方法，设置文字字体，获取文字所占大小时，系统一般需要遍历每一个文字（在 iOS 里面一般会使用是 CTRun 的概念，CTRun 表示的是排版最小单元，并不特指是一个字），根据文字的属性进行预排版并追踪计算出大小。但实际上对于一些特殊的文本，我们完全可以根据其文本长度直接估算出对应的大小，而省去调用系统 API 进行计算的麻烦。（举例来说，少于10个字的文字，肯定是无法占满一行，那么他的高度一般就是个固定值）

• 消息选择性显示

由于聊天室是个流动性非常大，消息量非常大的场景，虽然 App 也的确收到了这么多消息，但实际上并不需要将消息一一显示到界面上，部分超过范围的消息可以进行选择性丢弃。举个例子，当前界面实际上只能显示约 20 行聊天记录，而我们一下子收到将近 100 条消息，那么实际上我们只需要将最后 20 条消息放到界面中显示，而其余的消息只加入到内存 model 中，只有当用户真正上拉到对应位置时才进行真正的消息内容显示。

网易云信∣真正稳定的IM云服务

http://netease.im  长按识别，更多精彩