为什么要做这个?
代码混乱,常出现视频流卡主,发现问题不好排查。想要增加一种模式非常困难。
随着业务的叠加,原来的代码已经支离玻碎了。
没改之前有哪些问题
- 刷新都会removeFromView再addSubView重新构建宫格视图,性能很低。业务叠加起来问题非常多,偶现问题也多。
- 设置视频流时，使用了延时。刷新不可控。
- 刷新使用标记刷新，可读性差，其他人不好接手。
- BLMeetingItemModel对象使用范围广，很多不应该存在的。如isShareScreen、isSmall、isHost等,这些都只有一个，不需要存放在BLMeetingItemModel中。
- 代码复用性差。存在歧义的变量。
功能简介
一人视图.jpeg
两人视图.jpeg
多人视图.jpeg
一人视图:一个人的视图
两人视图:除了正常展示，还支持大小窗的切换。
多人视图:主要在于刷新逻辑的处理
当人数发生变化时，需要处理对应的状态。
我做了哪些优化
-
抽出视频流的videoView,确保一些视频内部的逻辑自己能处理,如加载动画、流的模式、第一针完成隐藏动画等。
原因:之前发现四宫格view、最小化view、最大化view到处都在用，代码没有复用性
成果:代码复用性高，出现问题好排查。 -
多人视图增加view缓存，确保每个view都对应一个视频流。
原因:之前发现同一个view设置多个流可能会闪退。(同事传递的经验，因为代码是他写的，具体情况需要验证。)
成果:每个view对应一个视频流。如果有人离开会议，只需要更新其他人的frame即可。刷新简单,性能提升。 -
多人视图刷新重新设计,提取itemView的frame计算方式,比如第5个，能知道是第二页的第一个itemview。让位置更新变的简单。
原因:之前的写法都是removeFromSuperview,在重新布局，计算。性能非常差。
成果:知道是第几个，就能精确计算位置。刷新简单，没有移除view的性能问题。 -
刷新时仅刷新当前页面,关闭其他页面的视频流。这是一个省流的方案。
原因:假如有十几个视频流全开着，而我们真正能看到的也就当前页的四个视频流。
成果:省流、省电、减少手机发热等。 -
去掉延时、发送通知再为view设置视频流
原因:这个是同事告诉我,声网的SDK需要这么操作。后来找到原因，设置完视频流在收到第一针画面操作时,又为当前流设置了一遍空的view。
成果:去掉延时和第一针再设置,视频刷新逻辑变得非常简单。也不存在说我四宫格、点击放大、最小化切换时，出现视频卡主的问题。
也省去了维护延迟带来的问题，使用延迟，再批量刷新，这样的代码是灾难性的。 -
增加一人视图
原因:之前一人视图是在二人视图上处理的，即隐藏二人视图的小视图。后来发现二人视图还有大小窗的位置互换，发现一人视图逻辑也不合适。
做法:单独剥离出来。即BLAgoraOneView、BLAgoraC2CView、BLAgoraMoreView
成果:职责分离,互不干扰，每一种view即一种策略。当人数发生变化时，来切换策略，再刷新当前策略即可。 -
去掉二人视图歧义的变量
原因:代码中存在localModel,remoteModel。再切换远程与本地视图时，发现localModel代表远程、remoteModel代表本地。一个人的时候也用remoteModel代表本地。明显存在歧义。
做法:剥离出一人视图，切换时仅把对应的model放到对应视图，不用切换model的含义。
成果:职责清晰，变量不存在歧义 -
去掉歧义的变量
BLMeetingItemModel每个视图的model。存放下面变量明显不合适:
isShareScreen //正在共享屏幕
一个会议中正在共享的只有一个人，不需要itemModel都存在一个。有没有共享，一个全局变量可判断
isSmall//是否是小屏幕
当前处于最小化、四宫格、最大化，实时查询下即可，不用存放在itemModel
isHost//是否是主持人
与isShareScreen类似，主持人就一个。存一份即可
isNeedFresh//刷新标记
重新刷新逻辑后，被干掉了。你刷新就需要把这个变量置为yes，很多情况忘记了，导致刷新失效。也是一个槽糕的设计 -
没有用到的变量、方法，发现一个去掉一个
总结:
- 第一波优化先做到这里，现在大致职责清晰，问题比较少。即使测试发现问题，也能第一时间来修正。
- 还未达到最优，我们的meetingViewController还很臃肿，但逻辑基本清晰，偶现问题明显减少。代码复用性增强，可读性也增强，扩展性也比较好，偶现问题减少。性能提升了一大截。
网友评论