生产-消费模式
生产-消费模式在各种场景下均有应用，几乎所有需要排队处理的场景，都可以认为是生产-消费关系模式。关于生产-消费模式的细节及PV操作等在此不再详述，不了解的可参见链接。
如：在直播场景下的礼物特效展示。
在iOS中的设计实现
因为业务需求需要排队策略实现，在实现时有过考虑：设计一个队列类，并在类中维护数组去保存需要推入、取出的数据，而操作时会出现几种情况。
- 队列中为空，等待队列数据的推入。
- 队列中为满，等待队列数据仍在推入，内存吃紧。
在第一种情况下，消费业务在等待，当数据出现时应通知消费业务。
在第二种情况下，需要使生产业务暂停，在消费业务需要时再推入即可，对内存、性能都是最好的。
而且，如果使用普通的类设计，生产、消费业务在使用时都非常不方便。
多线程+信号量
多线程+信号量是处理问题1的合理方式，当队列为空时，消费业务将被阻塞，而有新的数据推入时由信号量唤醒消费业务。
内存优化
对于问题2，即在类接口中除了有推入的接口外，还应当有拉入的接口——此部分由队列类主动完成。如读取超大文件便会出现这种情况。
类接口
所有的基础模块没有好用的接口都将搁浅在推进中途，一个好的接口是对上层业务负责。
由于消费生产的实际特点，该模块命名为RPipeline——流水线，并使用其实现NSFastEnumeration接口，从而使该模块使用时异常简单。
self.pipeline = [[RPipeline alloc] init];
/// ...
for (NSObject * object in self.pipeline) {
/// do something with object
[object consume];
}
由于使用信号量会使当前线程阻塞，所以for循环取数据时应放在子线程中，为了简化这种操作，直接添加新的静态接口。
self.pipeline = [RPipeline pipelineWithAction:(void (^)(NSObject *object))action {
/// do something with object
[object consume];
}
[object consume]句表示该数据已经被使用完，此时如果流水线中仍有数据，则将被推出，否则阻塞。没有调用该句则表示消费线程仍在处理object，流水线也会阻塞。
详细设计
一、NSFastEnumeration的及阻塞信号量的实现
实现countByEnumeratingWithState:objects:count接口，并在该接口中等待信号量以达到在for循环中阻塞的目的。
在内部维护的数据列表中，放置一个哨兵，它将一直存在，直至该流水线被destroy。因此在此之前上述接口中始终返回1，for将一直不结束。
二、内存问题
新增输入接口
@protocol RPipelineInputProtocol <NSObject>
@required
/**
生产产品的方法，会由【流水线】主动调用
@return 返回产品,如果为nil，不会被加入到流水线中
*/
- (NSObject * _Nullable)produceFor:(RPipeline *)pipline;
@end
@interface RPipeline (Input)
/**
流水线的被动生产者。如果流水线中没有产品，该方法将被主动调用
*/
@property (nonatomic, weak) id<RPipelineInputProtocol> input;
@end
如果input非空，当流水线内的数据不够时，会调用该回调，达到按需获取的目的，比全部数据都放在内存中，这种方式要节省很多内存。
三、切面处理
有的业务场景下，需要对所有的数据做统一处理，因此添加过滤器接口
@protocol RPipelineFilterProtocol <NSObject>
@optional
/// 返回该过滤器的优先级,如果没有实现则为0
@property (nonatomic, assign, readonly) NSInteger filterPriority;
@required
/**
如果向【流水线】添加了过滤器，当产品即将被推出时，依次经过所有的过滤器。
@param object 流水线中的产品，或经过其它过滤器的产品
@return 过滤后的产品，如果返回nil，该产品会被丢弃
*/
- (NSObject * _Nullable)pipelineFilter:(NSObject * _Nonnull)object;
@end
当数据将被推出时，会经过所有排序后的filter，处理后继续流程，如果pipelineFilter:返回空，直播抛弃该数据。
由于众所周知的原因，代码已经托管至码云，见Gitee
欢迎留言讨论
