抖音 iOS 推荐 Feed 容器化总结

动手点关注干货不迷路 👆

背景

抖音 Feed 容器在推荐、关注、同城、朋友等多个场景中使用，每个场景都有自身的逻辑和业务，最终汇总在 FeedViewController 中，随着业务的迭代，代码越来越臃肿，面临如下的问题：

• 容器类(FeedViewController) 有 10000+行，还有十多个业务分类，整体的理解和维护成本高

• 容器类 框架和业务边界不清晰，框架代码的修改不收敛和不规范，业务改动可能导致线上问题，如数据层不收敛导致的问题：自动删除导致一次滑动多个视频或者自动跳转到第一个视频等问题

• 容器类 承担了推荐、关注、朋友三个大场景，细节的业务逻辑差异较多，目前多业务代码耦合在一起，增加新功能时需要考虑其他业务方，容易引入问题，开发和测试效率低

• 内流容器和外流容器，形态相似但是代码分离，主体代码重复，新增功能时需要在两个类中做重复开发，如：视频预加载优化等，开发和维护成本高

• 核心功能的监控和代码防劣化的体系不完善

Feed 容器多场景下承载业务

Feed 容器承载了基础功能、直播、登录、登出、性能监控、预加载等多个功能。

由于之前没有做好管控，导致容器中业务相互耦合严重，业务边界不清晰，开发过程中稍有不慎，就会对其他业务造成影响。

而且随着业务迭代，逐渐呈现劣化趋势，尤其是对于新业务接入，面对负责的代码无从下手。

业务迭代效率低

由于代码都在容器类中直接修改，一个版本经常会有多个业务在容器中进行修改导致冲突的情况，此时就需要多方进行 review，保证改动不出问题，往往还要平台业务的同学进行支持，业务的整体迭代效率比较低。

防劣化&监控缺失

业务耦合，对代码改动没有监控，导致 FeedViewController 越来越膨胀。因为没有合理架构导致无法做拆分，代码劣化越来越严重，而且基于现状无法进行防劣化。

目标方案

为了解决上述问题，首先设定好目标，然后根据目标提出解决方案，最终落地实现，验证目标是否达成。

目标

• 架构分层，明确每层职责，容器和业务解耦，多业务之间解耦，做到容器和业务各自闭环；

• 业务组件可插拔，不同场景支持灵活的组合和扩展业务组件；

• 搭建监控体系，实现稳定性、性能、问题定位，建立看板，实时了解各项指标；

• 防劣化，容器和业务分仓隔离，收敛维护人员；

思路

根据上述的目标，从下面四点进行思考和设计：

• 明确业务开发痛点，多业务合作开发效率低、设计不合理模块使用成本高等;

• 自上而下设计，保证整体业务架构设计的合理性，明确优化方向;

• 分层开发和上线验证，降低上线风险和全量成本;

• 架构防劣化，收益可衡量;

方案

针对 Feed 容器内部多场景、多业务耦合导致整体维护困难，新业务接入成本高的问题，首先按照场景、业务和功能维护进行拆分梳理。在拆分完成后为了方便各个业务进行维护，设计了 ControlerKit 工具实现了生命周期方法的分发，并且通过 Context 进行状态管理，实现了各个业务间的通信和状态维护。

整体架构