背景

历史原因加上功能的不断迭代，造成直播间代码越来越难以维护，前期架构也没有很好设计，造成各种耦合，不管是业务上的耦合，还是UI上的耦合。加上遗留了很多适配上的问题，以及交互问题，这块的代码成了一块比较难啃的硬骨头，重构这块代码已刻不容缓。

重构思路

1. 引入多代理实现（使用过XMPP的同学应该会熟悉这个概率，笔者工作早期有使用过XMPP），用于统一事件的分发，各个业务都可以注册成为代理，用于将数据转发给各个关心的业务模块，做到各业务模块的解耦。
2. 将页面划分成不同的Container，使用UIStatickView来做流式布局。通过协议的方式，添加不同业务的视图，业务层自己维护视图的显示尺寸，以及是否显示，不需要管理布局间的相对关系。这样可以很好的将UI进行解耦，达到插拔式使用效果。
3. UI联动解耦，比如键盘升起某些视图需要位移，某些需要隐藏，原来的处理方式是在一个地方注册监听，然后处理所有的视图逻辑。重构思路是，下放权利，各个业务模块自己注册通知，然后自己处理这块的逻辑。这个主要也是充分发挥了UIStatickView的特性，不然做起来会比较麻烦。
4. 横竖屏切换，布局相应调整。主要也是利用UIStatickView流式布局的线性方向，结合SizeClass，可以达到切换横屏后，布局方向的灵活调整。
5. 业务层采用MVVM结构实现。

UI结构

以下只是部分结构

直播间UI架构.png

部分效果

由于涉及到一些隐私数据问题，这里只放很小的一部分效果。

横竖屏切换自适应：

点击图片查看动图

键盘联动效果，以及横竖屏切换：

点击图片查看动图

体验优化

本次重构，还做了很多交互体验上的优化。

1.添加动画

交互没有动画，就像一个人没有灵魂一样。但是，动效也不是越多越好，越复杂越好。常规动效即可，耐看。也可以理解为，在该有的地方有该有的动效，才是好的动效。
比如底部弹起的弹框，那么他就该从底部慢慢升起，而不是直接就盖在了页面上。这是用户已经见惯不怪的效果了，没有这个效果反而觉得很low。
再比如键盘升起的时候，页面内容需要跟着键盘的动效一起慢慢升起或者降落。
当然，还有很多弹框的动效，由于时间和资源有限，加上直播间的弹框较多，需要重新架构一下。所以，本次只做了部分修改。

2.直播间刷新优化

老版本在进入直播间，加载数据的时候加了很多loading，这个其实很影响视觉。所以，我在不影响功能的情况下，直接干掉了霸屏loading。

再一个，老版本从直播间切换到其他页面后，会再次刷新直播间数据，并且重新拉流。这样就会看到聊天列表闪屏、直播拉流断掉并重新启动等。这样一顿操作下来，体验真的有点难以忍受。这个细节问题，其实很好解决，从新回到直播间的时候，已经在拉流了就不需要再次启动拉流了，这样画面就不会断掉（视网络情况而定）。

聊天列表闪屏问题。为什么会闪屏？仔细看不难发现，造成闪屏的原因是：列表数据从有到无，再到有。找出这个问题就好解决了，解决方式就是在有数据的时候去刷新列表，不做清空列表的动作。事实上，聊天列表数据也不会有清空的情况。真的有这种情况，那就是数据库数据被清了。

3.样式升级

当你在一家公司接触了一波又一波UI设计师后，你会发现每个人的设计都有自己的风格。我觉得一个好的App，需要有一个整体的风格，不管是图标、圆角、配色、字体字号、插图、弹框、交互等等，都应该在一个规范里面去执行，需要一个宏观的把控。巧了，我在公司就主导推动过这件事，并且最终出了一套规范。在这次重构中发现的一些配色和字体问题，做了修改。比如邀请下单按钮背景色、价格颜色和字体、七天无理由颜色等等。

4.异形屏适配

屏幕适配，其实，也是UI重构的一部分。放在体验优化里面讲，是因为很多人不觉得这是一个 bug，仅仅是丑了点。它确实不是 bug，但真的看不过去呀。

关于如何准确适配异形屏，可以参考我之写的一篇文章 《iOS 如何更好的适配异形屏（刘海屏）》，掌握了这个技巧，可以很轻松的就解决这个问题。

5.聊天列表顶部渐隐效果

这个细节问题，也是不痛不痒。但是，别人家孩子有的东西，咱也不能落下。

6.统一转屏效果

很多地方都是直接在转屏的同时去切换下一个页面，这样不仅看起来怪怪的，同时也会产生布局的问题，特别的有两个操作都需要转屏时，出现同时调两次转屏造成一些意想不到的问题。
本次重构统，重构了转屏的方法，提供了转屏结束的回调。将需要转屏的操作，统一放在完成转屏的回调中去处理。这样既保持了统一性，又能避免出现布局错误。

7.页面联动效果

这个包括发布评论时键盘的升起和收起时，页面的联动效果。以及出价时，出价器显示，包括优惠券展示的联动效果等。

重构收益

经过重构，主要有以下收益：

• 直播交互更加的丝滑，体验提升几个档次
  • 页面切换，拉流不再卡顿
  • 键盘交互、横竖屏更加丝滑
  • 交互动效更加合理
• 结构更加清晰，扩展性强，解耦，易维护
  • 利于新业务的扩展，不再需要梳理大量的业务逻辑
  • 老业务的废除，都能够做到"干净"移除
• 期间解决了很多细节问题和历史遗留bug，总数在100+
• 上线后，运行稳定，几乎没产生因重构造成的bug
• 最后，也是非常重要的一个收益，就是对于开发来说，这块硬骨头终于被拿下，后期维护更加友好，间接提升效率

总结和感悟

本次重构任务量很大，重构中也发现了很多历史遗留问题和细节问题。细节问题处理和自测占了大部分时间。很多个夜晚笔者都是自觉加班加点的自测和打磨细节。一方面是希望把这个事情做好，当然，最主要还是害怕出线上bug😂。

在开启这项工作的前，也有小伙伴劝我不要做这件事。一方面是比较麻烦，另一方面是几乎没有业务价值，再者就是如果出了严重的线上事故，你所做的这一切都将毁于一旦。但是，作为一个有追求的技术来说，在遇到这样的问题时，是没有退路的。而且，我也很享受问题被解决后的成就感，我相信很多人都会有这样的感受。

通过这次重构，不仅仅是从技术上去解决问题，更多的时候，我会从产品的角度去思考一些功能和交互的合理性，然后去改进它。