一、项目现状及问题总结：

1. 代码问题

1. 直播间6个模式，每个模式一份代码，每个主controller代码量在4000 - 7000行之间。多个单类的代码量巨大，6000+两个类，5000+4个类，4000+3个类。
2. 6个模式代码大量重复性代码，礼物模块6份，推拉流代码6份，声网SDK封装3份，修改任何一份代码都需要同步到其他模式，共6份。
3. 功能模块中侵入太多的业务性代码，比如礼物模块有的模式支持显示送礼人，有的模式不支持，礼物模块中内部充满了大量的直播间模式代码判断。新增一个模式，或礼物模块在某个模式下新增一个功能，都需要梳理完礼物模块所有的代码再填充。
4. 类的层级过深，类树结构混乱，类和类之间相互引用，持有关系接近网状结构；类层级深度较高，如A->B->C->D->E->F，F要与A有业务交叉，用通知、有的通过传递让F持有A直接调用、用代理一层一层传递。
5. View层不单一，写了大量逻辑代码，比如直接调用WebsocketManager做逻辑，后续业务扩展需要和其他业务有交叉逻辑后，维护成本高。

2. 辅助排查工具问题

1. 测试或线上出现问题后只能靠完全复现才能解决，若未复现如同盲盒一样无法解决用户问题，无辅助排查工具问题

3. 业务问题：

1. 老板及业务方想做换肤需求，满足新老用户对于UI不同的要求，进入一个房间，同样的逻辑支撑起两套UI，并且能够实现实时换肤需求。按照当前的框架和设计，100人天的估时让业务方难以接受。

4. 性能问题：

1. 用户反馈进房间崩溃，未抓到崩溃日志
2. 用户反馈卡顿

二、项目目标及解决方案

目标：

1. 一套业务逻辑支持多套UI皮肤，每新增一套UI皮肤，开发成本控制在只做UI渲染和响应事件对接，增加对业务方的支持
2. 项目框架合理，主类的代码量减少到3000
3. 框架及设计模式合理，优化设计模式、类层级结构
4. 出现线上和测试问题有据可查，不断完善

方案：

1. 抽离功能组件，本地Pod化，剥离与业务的耦合：推流、拉流、声网、Websocket
2. 抽离业务组件，本地Pod化，剥离与业务的耦合：礼物、聊天室
3. 房间设计模式从MVC到MVVM，View移除业务逻辑，只做数据渲染和事件响应，新增UI样式实现无缝对接
4. 在view和业务完全剥离的情况下，新增ViewManager，用来管理所有subView的添加、移除、层级控制
5. 在1、2、3、4完成的情况下，主类Controller只有各个模块的初始化、销毁，不同模块消息中转
6. 全局抽象来看，直播间当成一个小App，然后组件化。