LeanClound消息类型自定义
主要矛盾在于过去接收和发送的消息类型与现在接收和发送消息类型完全不一样，次要矛盾在于过去的消息类型与现在的消息类型对应的消息处理逻辑不一样。
模型架构。假设扁平化处理，所有键值对都写成字符串的形式，势必造成我在构建消息往外发送的时候还需要先构建字典，然后再传入到消息的字典中去，这是我不能忍受的，是否可以去扁平化，模型本身就是一个整型键值对、一个字符串键值对、一个字典键值对，如此一来构建模型至少需要上面的是三个键值对又变得特别麻烦了。那如果把字典这种键值对也包装成模型呢，这又变成了构建两个模型的问题了，MJEXtension将模型转换成字典。
处理逻辑。全局搜索枚举（枚举这种单词还是写长一点比较搜索起来比较方便）就能把消息类型对应的所有处理逻辑搞定，无论什么消息类型都有一个共同点，都是AVIMMessage消息类型，需要做的就是根据消息模型构建消息，最好的就是传入一个模型就发送消息出去，反正，我需要做的就根据一个模型构建一个整体的ChatModel。显示到聊天框的消息包括：普通礼物、特效礼物、群聊、系统消息、房间消息、第一次的点赞消息、不展示在聊天框的消息包括：来了、离开、观众被动退出（也就是服务器关闭直播间消息）、第一次以外的点赞消息、红包消息、弹幕消息。需要主要的是消息显示有两种特殊，一种是礼物连击和观众点赞写在聊天框的最下面；二种是观众进入房间显示到右上角。至于其他的消息，通通刷新TableView就👌了。后台发送的消息包括：普通礼物、特效礼物、红包消息、服务器关闭直播间消息。每次点赞都会发消息，但是请求服务器点赞的接口只能执行一次，因此服务器点赞的Type是7，需要显示到聊天框，用户第二次点赞的Type是5，不能显示到聊天框。
接收消息。接收消息十分简单，Json字符串一步就变成了大模型！先确保消息能够被完整接收，然后才是发送消息，毕竟只要接收得好，就不用担心因为消息类型不一致所带来的崩溃呀。
发送消息。到底该如何去建立大模型呀，大模型包含小模型属性的方法极为不科学，还是得用字典来做为属性。
主播被动关闭直播间
正常关闭直播间逻辑。退出分两步完成，严格区分SDK层和业务层。先执行SDK层的退房逻辑，成功后请求服务器关闭业务层房间，成功后接收到直播间关闭的消息，然后主播和观众在接收到这个消息之后都跳转到结束直播的控制器，同时退出LeanCound聊天室断开LeanClound连接。主播点击退出，关闭SDK视频录制、发送服务器请求、响应LeanClound消息、退出业务层、跳转控制器。
服务器关闭业务层房间失败异常处理。问题在于如果主播请求服务器关闭直播时服务器无回应，直接意味着直播关不了，这很要命的，无论服务器什么错误没回应，我都必须响应主播的退出按钮事件，都必须跳转控制器。所以处理就是自己构造直播间关闭的消息群发，这也正好解决了因为心跳超时直播间断开的问题。
关闭SDK房间视频录制失败异常处理。心跳失败必然是网络出错，网络出错意味着：1、SDK房间没有视频帧经过，2、接收不到服务器发来的直播间关闭消息 3、SDK会退出房间并销毁实例4、关闭视频录制不会返回ID 5、视频画面卡着不动6、点击退出按钮无法跳转控制器7、所有与网络有关的操作都干不了
