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

FeedContainerProtocol用来给controller提供FeedViewController实现的能力FeedContext中存放Controller共用的状态两个都能实现通信，但context更偏重于状态，而ContainerProtocol更偏重于能力，比如页面滚动、数据刷新业务组件定义
定义业务Controller类实现FeedControllerProtocol协议在对应的生命周期方法中实现对应的业务逻辑若FeedControllerProtocol不满足情况时根据之前说明方式在协议中增加新的生命周期方法，同时同步增加到FeedContainerProtocol ，以便分发重构后业务迭代方式
文章图片
框架由平台业务架构方维护其他业务的框架扩展需要提交到架构方，由架构方开发其他业务提交的方案和修改，交由架构方review业务方的代码，业务方自闭环防劣化建设为了防止随着业务的迭代， Feed容器逐渐劣化，需要进行防劣化建设。首先进行框架和业务分仓：
代码隔离，修改权限收敛;框架部分，线下做Pipeline准入， Lint检查是否符合容器规则;业务方修改容器代码， review通过后才能合入
文章图片
新方案优势业务解耦，明确了业务和容器的职责，边界清晰降低FeedViewController维护成本减少新业务接入成本方便做防劣化接入示例
以下以兴趣选择和业务为例，介绍新老业务的接入。
新功能接入-兴趣选择
兴趣选择是新的类型的卡片，需要进行卡片注册并处理相关逻辑。

文章图片
历史方案FeedViewController直接进行修改，包括如下内容：
增加状态管理属性需要在tableviewdelegate和scroll滚动等多个方法中增加相应的处理逻辑处理注册卡片逻辑新方案抽取单独的业务Controller在生命周期方法中处理兴趣选择相关逻辑业务相关的属性在Controller中声明和维护Controller注册到ControllerManager在对应的Controller中进行自己的业务处理即可，不需要了解容器本身的其他业务逻辑存量功能拆分—Feed监控Feed监控功能在FeedTableVC中处理了很多业务，而且这些逻辑也其他业务存在着耦合。
网络请求监控和数据处理页面滚动播放处理...
文章图片
采用新方案进行拆分首先创建FeedMonitorController ，增加业务相关的属性、生命周期方法中实现对应的逻辑，之后抽取单独的业务controller在生命周期方法中处理熟人相关逻辑。同时注册到controllerManager中，并设置AB、原有代码判断AB 。上线验证，全量后删除容器老代码。之后业务自闭环，再进行迭代时直接在FeedMonitorController内容修改即可。

文章图片
当前进展&后续规划规划和节奏
文章图片

文章图片
重构后的收益业务解耦后，容器本身稳定，业务方各自维护自身业务，提高了整体的稳定性老容器新容器因为业务耦合，需要了解Feed的结构和多业务的细节，新同学熟悉的时间需要2天左右；在实现过程中，由于多个业务同时进行迭代，相互影响，质量无法保障只需要在自己的业务Controller开发即可，无需关心容器的结构以及其他业务方，极大的提高了开发和迭代效率；改动不影响其他业务线的代码，保障了代码的稳定性全量业务在业务组件中实现了自闭环版本进行了映射