Combine 框架，从0到1 —— 3.使用 Subscriber 控制发布速度

 

本文首发于 Ficow Shen’s Blog，原文地址： Combine 框架，从0到1 —— 3.使用 Subscriber 控制发布速度。

 

内容概览

• 前言
• 在发布者生产元素时消耗它们
• 使用自定义的订阅者施加背压(back pressure)
• 使用背压操作符管理无限需求(Unlimited Demand)
• 总结

 

前言

 

对于大多数响应式编程场景而言，订阅者不需要对发布过程进行过多的控制。当发布者发布元素时，订阅者只需要无条件地接收即可。但是，如果发布者发布的速度过快，而订阅者接收的速度又太慢，我们该怎么解决这个问题呢？Combine 已经为我们制定了稳健的解决方案！现在，让我们来了解如何施加背压(back pressure，也可以叫反压)以精确控制发布者何时生成元素。

 

在 Combine 中，发布者生成元素，而订阅者对其接收的元素进行操作。不过，发布者会在订阅者连接和获取元素时才发送元素。订阅者通过 Subscribers.Demand 类型来表明自己可以接收多少个元素，以此来控制发布者发送元素的速率。

订阅者可以通过两种方式来表明需求(Demand)：

• 调用 Subscription 实例（由发布者在订阅者进行第一次订阅时提供）的 request(_:) 方法；
• 在发布者调用订阅者的 receive(_:) 方法来发送元素时，返回一个新的 Subscribers.Demand 实例；

Demand 是可以累加的。如果订阅者已经请求了两个元素，然后请求 Subscribers.Demand(.max(3))，则现在发布者不满足的需求是五个元素。如果发布者随后发送元素，则未满足的需求将减少到四个。

 

发布元素是减少未满足需求的数量的唯一方法，订阅者不能请求负需求。

 

很多应用会使用 sink(receiveValue:) 和 assign(to:on:) 来创建便捷的订阅者类型，分别为：Subscribers.Sink 和 Subscribers.Assign。这两种订阅者在第一次连接到发布者时，会发送一个 unlimited 的 Demand，这时候订阅者会一直不停地接收发布者发来的内容。

 

在发布者生产元素时消耗它们

 

当发布者的需求很高或不受限制时，它发送元素的速度可能比订阅者处理元素的速度快很多。这种情况可能导致元素丢失，或者在元素等待被缓存时迅速增加内存的压力。

如果您使用便捷的订阅者，则会发生这种情况，因为它们的需求(Demand) 是无限数量 (unlimited) 的元素。确保您提供给 sink(receiveValue:) 的闭包和 assign(to:on:) 的副作用(执行效果)遵循以下特征：

• 不会阻塞发布者；
• 不会因为缓存元素而消耗过多的内存；
• 不会不知所措并且不能处理元素;

庆幸的是，许多常用的发布者（例如与用户界面元素相关联的发布者）都会以可控的速度进行发布。其他常见的发布者仅仅生成一个元素，例如：URL 加载系统的 <