feed是什么意思？流架构演进

大家好，今天给各位分享feed是什么意思的一些知识，其中也会对流架构演进进行解释，文章篇幅可能偏长，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在就马上开始吧！

1、Feed流可以分为两部分来看，即Feed+流，首先看第一部分Feed，在英文中Feed是投喂的意思，也就是你喜欢什么样的内容，就给你什么样的内容，而流则是给用户呈现信息的形式。结合起来就是Feed流是一种持续更新并呈现给用户内容的信息流。

2、维基百科对Feed的定义如下：OntheWorldWideWeb,awebfeed(ornewsfeed)isadataformatusedforprovidinguserswithfrequentlyupdatedcontent.(来源https://en.wikipedia.org/wiki/Web_feed）

3、Feed流将用户主动订阅的若干消息源组合在一起形成内容聚合器，帮助用户持续地获取最新的订阅源内容，Feed流即持续更新并呈现给用户内容的信息流。

4、文中该词指Feed流里的视频播放。

5、目前，视频内容已经占据了互联网数据总量的80%，并且有越来越多的APP开始提供加载视频功能。即便没有任何技术与应用突破，预计到2022年视频内容的数据总量也将达到82%。这都表明视频在促进人与人交互中的作用得到了广泛的认可。随着视频成为人们休闲娱乐和信息传递的主要方式，越来越多的视频消费被前置，列表内播放视频成为Feed流里的一个重要组成部分。

6、近年来，我们可以看到：越来越多的APP在列表内插入可inline播放的卡片，如西瓜视频、爱奇艺、新浪微博等，大家都非常默契的将视频消费前置化。但是如何找到符合自己产品的视频化道路，就需要大量的线上试错、数据验证，这些都是产品打磨的重要方式。

7、所以对于我们开发者来说，如何快速响应业务的试错及数据的回归验证，且降低维护成本成为了迫在眉睫的事项。

8、目前，B站的首页推荐、动态、搜索等业务都有inline播放的能力，业务的差异带来了不同的交互诉求。如首页推荐在Banner存在时会优先起播Banner的卡片，当用户手动点击下方手动起播卡片时，一次播放周期内，会优先播放该卡，同时首页推荐的inline卡片分别有弹幕、点击播放、点赞、拖拽进度等差异化功能。动态列表内，会根据一定条件会延迟起播inline卡片，时长可配置。

9、各自为战-散落在各类列表的相似逻辑

10、对于inline播放，大致的流程为：

11、列表停止滚动/滚动到顶/VCdidAppear时触发检索事件；

12、检索tableView/collectionViewvisibleCells；

13、计算露出比例，找到符合播放条件的卡片；

14、调用播放VC内精简后的伪代码如下：

15、目前，只要有inline播放诉求的页面，这样的代码就会出现在相应的ViewController中。

16、业务差异带来的“巧妙”解决方案

17、起初，inline播放的功能相对简单，只需在列表停止滚动后，找到一张播放卡片起播即可，面板上也只有简单的音量开关按钮，所以最开始的设计都是基于ViewController里的checkInlinePlayCard方法，这样做在当时的背景下是“够用”的。但是随着业务的发展，Banner也需要支持inline播放，并且它与列表其它卡片的播放行为存在差异性，于是我们在ViewController里记录了Banner卡片，checkInlinePlayCard方法内对这部分记录的卡片进行差异化处理，这个需求看起来被“完美”的解决掉了。

18、再后来，为了验证不同面板对播放时长及卡片点击的影响，产品大大提出了要将普通的inline卡片分成三组：只有音量按钮的卡片、可手动拖拽进度的卡片、展示弹幕的卡片。接到需求后，我们将卡片分为三种不同类型，每个卡片关于播放的一些属性是不变的，变化的是面板上的UI内容，需求快速上线了，但是我们产生了大量的重复代码，在后续一个内部技改需求中，我们相同的逻辑修改了三遍。

19、经过后来几个版本的迭代，inline相关的功能不断丰富，checkInlinePlayCard方法处理了各式各样的的逻辑分支。以首页推荐为例，由于Banner及直播、广告卡等业务存在，它的找卡逻辑大概为：先检索一次visibleCells，判断是否是Banner卡，如果是则去走相关的播放逻辑，如果不是则筛选出广告卡、直播卡，分别加入相应的数组中。然后筛选出符合条件的卡片再去判断续播条件，上述操作完成后，还需判断卡片类型是否是一些实验命中的卡，然后走相应的起播逻辑。

20、上述内容是笔者精简后的起播逻辑，整体从检索到起播的代码行数在2000行左右，里面包含了各种各样的条件判断，逻辑的组合与避让，基本上是一段“上帝”代码，让维护的人苦不堪言，每天都祈祷着千万不要有新的需求进来。

21、在上述例子中，我们不难发现，每一次的需求过来，我们设计的方案都“够用”，"巧妙"地完成了需求，但后来，越来越多的逻辑集中在ViewController及checkInlinePlayCard方法中，导致了越来越多的Flag和重复的代码。

22、原以为只修改了部分相关逻辑，却影响了风马牛不相及的其它功能，同时相同功能的代码散落在各个地方，一次变化可能会带来多次相同改动，如果漏改，就意味着某个功能的不可用，往往修复一处问题就会引入新的问题，形成了恶性循环，给我们带来了极大的心智负担。

23、痛定思痛，我们需要抽象出inline播放的基础功能，降低重复代码的再次开发，同时对业务的差异、快速试错提供友好支撑。

24、将ViewController从繁琐的找卡片、播放卡片中解放出来，将相关逻辑托管；

25、要支持不同类型的页面：如UITableView、UICollectionView、UIScrollView驱动的页面或简单的UIView驱动的页面；

26、要满足不同的检索条件及起播条件：不同卡片的播放条件由各种避让操作变为策略驱动；

27、管理相同的播放逻辑及状态维护；

28、要满足不同卡片的不同UI及交互诉求：提供自定义面板接口，同时管理面板的展示与移除逻辑。

29、它负责管理所有与inline相关的事件，由VC去持有它的实例，将VC从繁重的inline管理工作中解放出来，它的构造方法如下：

30、其内部持有着"两大护法"，它们是ViewHandler、ViewFetcher。

31、内部监听了vc的生命周期方法，在相应的生命周期回调时，通知ModuleInlineManager进行起播停播操作持有tableView/collectionView的delegate，当列表真正滚动停止时，将事件告知ModuleInlineManager，同时将原有的tableView/collectionView相关代理方法通过ModuleInlineManager回调给VC，不影响其它的逻辑。

32、接收到ModuleInlineManager发出的检索消息后，它负责寻找最符合播放条件的那张卡，去除了之前基于visibleCells驱动的找卡逻辑，采用subViews及剪枝的方式来寻找可播卡片。

33、它将原先使用的一系列标记位抽象成配置与策略，内部采用优先级标记卡片，最终找到符合业务逻辑的可播卡片。

34、前面我们有聊到，inline播放在不同业务的表现形式五花八门，尤其是首页推荐上的inline播放的功能更是变化快、差异性大，线上同时在跑的实验多达十余种，过去，我们在不同inline播放场景下对播放器的管理各自为战，大量相同逻辑在不同业务copy一份然后在此基础上做差异化的修改，同时，播放器有时不得不理解业务的一些逻辑，做相应的特殊处理。

35、不同业务playerHelper里的数据构建大致相同，功能不同，导致代码冗余且对player层侵染很大，它大概的样子如下：

36、首页playerHelper承载了更多卡片功能，在内部以ifelse的方法做逻辑分支管理，如音量和点赞逻辑出现了耦合则又是一条新的分支，改动可能会影响到原有的功能，我们将首页的playerHelper展开，结构如下：

37、有没有一种方案，可以统一管理播放行为又具备良好的业务扩展性？答案是YES，它就是inlineController，它由列表上卡片的ViewModel持有，在cell出列时，将需要展示播放器的视图赋值给它的inlineView属性。

38、播放器上的自定义面板，如音量按钮、弹幕开关等，业务可按需传入自定义视图。

39、接收播放器的一些回调，如播放状态的变化，处理后提供独立API抛出，方便业务特殊诉求。

40、提供了play、suspend、replay等操作，供ModuleInlineManager或业务特殊场景使用，统一与播放器的交互行为。

41、InlineController管理了卡片上与播放有关的事务，承载播放视图、提供播放所需数据源、接收播放器的生命周期回调等，我们可以发现，原来散落在各个业务Helper里相同的播放控制逻辑、各种自定义的数据模型被收敛在了InlineController里。同时，CustomLayer、PlayerCallback有很好的支撑了业务的差异性，不同业务如有特殊需要可继承InlineController完成定制化需求。框架内部提供了一套默认实现，它包含播放生命周期的管理及默认播控面板，如果新业务初期比较轻量，那么inline播放功能可以被很快的接入进来。

42、以默认实现来接入这套框架，大概代码如下：

43、经过以上相关配置，一个Feed流即可完成列表播放功能，如有复杂面板或者交互诉求，在InlineController上异化即可。

44、以上就是我们这次轻量化项目Feed流的架构变化，受限于篇幅，有一些细节如起播数据监控、复用逻辑处理等来不及说，我们下次一定！

45、本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿

好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！