早期业务扩展快，短平快无法 代码耦合度高，自研IM组件 和国外版本的开发 导致切换成本过高 需要重构；
直播间 人数较多时，用户反馈 较为明显的卡顿和不问题，一些中低端机明显；
定位问题，CPU Profile 发现存在的明显的内存抖动 线下压测不够充分；
IM 消息体 属于大对象，持有用户对象实体和各种附加信息，而且不能简单做精简，然后在高频场景下内存需要频繁申请内存；
针对此条件做对象池缓存，对象复用，用完立即回收，解决内存抖动问题；
线下制作做压测工具
- 开发帧率监控模块自动消息生成器 mock 消息 定时器产生消息
- 定时刷新策略可控 文本消息 避免消息风暴 每秒最多50条 ,淹没不影响。端上限制发送发言频率 服务端丢弃无效消息（低等级不活跃用户） 保证到端上消息可控 保证 瞬间消息 不超过500条 10s 可以处理完。高优消息优先级排序 优先级一致 按照发送时间，返回端上 。设计一个生产者消费者阻塞队列 IM 消息组件作为生产者 有一个 消息 disptacher 作为消费者 定时去取。
- 优化层级 采用自定义 组合view;去除没必要的重复 merge 标签；避免过度绘制，红色背景–> 转为绿色；getView 中 一些复杂判断逻辑 没必要每次调用的 放到外部；删除无效的逻辑和旧版本的过时逻辑代码；
