抖音 iOS 推荐 Feed 容器化总结作者|抖音主框架团队责编|张红

文章图片
作者|抖音主框架团队责编|张红月出品|字节跳动技术团队（BytedanceTechBlog）抖音Feed容器在推荐、关注、同城、朋友等多个场景中使用，每个场景都有自身的逻辑和业务，最终汇总在FeedViewController中，随着业务的迭代，代码越来越臃肿，面临如下的问题：
容器类(FeedViewController)有10000+行，还有十多个业务分类，整体的理解和维护成本高容器类框架和业务边界不清晰，框架代码的修改不收敛和不规范，业务改动可能导致线上问题，如数据层不收敛导致的问题：自动删除导致一次滑动多个视频或者自动跳转到第一个视频等问题容器类承担了推荐、关注、朋友三个大场景，细节的业务逻辑差异较多，目前多业务代码耦合在一起，增加新功能时需要考虑其他业务方，容易引入问题，开发和测试效率低内流容器和外流容器，形态相似但是代码分离，主体代码重复，新增功能时需要在两个类中做重复开发，如：视频预加载优化等，开发和维护成本高核心功能的监控和代码防劣化的体系不完善Feed容器多场景下承载业务Feed容器承载了基础功能、直播、登录、登出、性能监控、预加载等多个功能。
【抖音 iOS 推荐 Feed 容器化总结】由于之前没有做好管控，导致容器中业务相互耦合严重，业务边界不清晰，开发过程中稍有不慎，就会对其他业务造成影响。

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

文章图片
防劣化&监控缺失业务耦合，对代码改动没有监控，导致FeedViewController越来越膨胀。因为没有合理架构导致无法做拆分，代码劣化越来越严重，而且基于现状无法进行防劣化。
目标方案为了解决上述问题，首先设定好目标，然后根据目标提出解决方案，最终落地实现，验证目标是否达成。
目标架构分层，明确每层职责，容器和业务解耦，多业务之间解耦，做到容器和业务各自闭环；业务组件可插拔，不同场景支持灵活的组合和扩展业务组件；搭建监控体系，实现稳定性、性能、问题定位，建立看板，实时了解各项指标；防劣化，容器和业务分仓隔离，收敛维护人员；思路根据上述的目标，从下面四点进行思考和设计：
明确业务开发痛点，多业务合作开发效率低、设计不合理模块使用成本高等;自上而下设计，保证整体业务架构设计的合理性，明确优化方向;分层开发和上线验证，降低上线风险和全量成本;架构防劣化，收益可衡量;方案针对Feed容器内部多场景、多业务耦合导致整体维护困难，新业务接入成本高的问题，首先按照场景、业务和功能维护进行拆分梳理。在拆分完成后为了方便各个业务进行维护，设计了ControlerKit工具实现了生命周期方法的分发，并且通过Context进行状态管理，实现了各个业务间的通信和状态维护。

文章图片
整体架构图
基础容器
Feed基础容器，采用组件化框架，支持基础组件和业务组件的动态组合和扩展，由业务无关、统一的列表形态组成，通过数据驱动页面展现。同时对外暴露生命周期事件，方便组件进行监听。其中基础容器由平台方进行统一维护，并提供了完善的监控体系，方便进行问题的定位和追查。