ReactiveCocoa比较区分replay, replayLast和replayLazily

最新推荐文章于 2018-05-29 13:44:21 发布
转载 最新推荐文章于 2018-05-29 13:44:21 发布 · 1.3k 阅读 · 0

本文详细介绍了ReactiveCocoa中三种信号订阅方法：replay, replayLast 和 replayLazily 的工作原理及应用场景。通过示例代码展示了不同订阅方式下信号行为的变化。


原文地址；https://spin.atomicobject.com/2014/06/29/replay-replaylast-replaylazily/

Subscribing to a Signal

　　对于一个“普通”的信号，每次订阅都将会导致信号中的代码再执行一遍，且该次订阅者仅接收到该次订阅发送出去的值。

　　第一个例子演示每次订阅都会重新执行订阅代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
__blockintnum = 0;
  RACSignal *signal= [RACSignal createSignal:^RACDisposable *(id  subscriber) {
      num++;
      NSLog(@"Increment num to: %i", num);
      [subscriber sendNext:@(num)];
      returnnil;
  }];
  
  NSLog(@"Start subscriptions");
  
  // Subscriber 1 (S1)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S1: %@", x);
  }];
  
  // Subscriber 2 (S2)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S2: %@", x);
  }];
  
  // Subscriber 3 (S3)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S3: %@", x);
  }];

　　运行结果如下：

1
2
3
4
5
6
7
Start subscriptions
  Increment num to: 1
  S1: 1
  Increment num to: 2
  S2: 2
  Increment num to: 3
  S3: 3

　　可以看到，每次订阅num都在递增，如果不订阅则不会递增。通过这种方式，可以知道信号是懒惰的，如果没有订阅者的话，是不会执行的。

　　第二个例子演示信号被添加订阅的时候，订阅者是怎么接收发送的值的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
RACSubject *letters = [RACSubject subject];
 RACSignal *signal= letters;
 
 NSLog(@"Subscribe S1");
 [signalsubscribeNext:^(id x) {
     NSLog(@"S1: %@", x);
 }];
 
 NSLog(@"Send A");
 [letters sendNext:@"A"];
 NSLog(@"Send B");
 [letters sendNext:@"B"];
 
 NSLog(@"Subscribe S2");
 [signalsubscribeNext:^(id x) {
     NSLog(@"S2: %@", x);
 }];
 
 NSLog(@"Send C");
 [letters sendNext:@"C"];
 NSLog(@"Send D");
 [letters sendNext:@"D"];
 
 NSLog(@"Subscribe S3");
 [signalsubscribeNext:^(id x) {
     NSLog(@"S3: %@", x);
 }];

运行结果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Subscribe S1
  
Send A
S1: A
  
Send B
S1: B
  
Subscribe S2
  
Send C
S1: C
S2: C
  
Send D
S1: D
S2: D
  
Subscribe S3

　　在很多情况下，这是我们想要的预期结果，不过在某些情况下，你不需要订阅的代码再次被执行。例如订阅 一个向网络服务器发送的请求，当服务器返回数据时，多个监听者需要更新(无论有多少个监听者，请求只发送一下（第一个例子就不满足我们的需求）)，或者我们想拿到订阅前信号发送过的值（第二个例子，S2想拿A，B的值或者S3想拿A，B，C，D的值，就不满足我们的需求了）。因此-replay,-replayLast, and-replayLazily应需而生。

Subscribing to a -replay Signal

　　这个replay方法将返回一个新的信号，当源信号被订阅时，会立即发送给订阅者全部历史的值，不会重复执行源信号中的订阅代码，不仅如此，订阅者还将收到所有未来发送过去的值。

　　第一个例子演示信号添加新的订阅时，代码是不会再次被执行的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
__blockintnum = 0;
  RACSignal *signal= [[RACSignal createSignal:^RACDisposable *(id  subscriber) {
      num++;
      NSLog(@"Increment num to: %i", num);
      [subscriber sendNext:@(num)];
      returnnil;
  }] replay];
  
  NSLog(@"Start subscriptions");
  
  // Subscriber 1 (S1)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S1: %@", x);
  }];
  
  // Subscriber 2 (S2)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S2: %@", x);
  }];
  
  // Subscriber 3 (S3)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S3: %@", x);
  }];
1
2
3
4
5
Increment num to: 1
  Start subscriptions
  S1: 1
  S2: 1
  S3: 1

　　信号首次被订阅时，num立马被递增了，且仅仅递增了一次。这说明了不管有你多个订阅者，订阅代码我只执行了一次。

　　

　　第二个例子演示每个新添加的订阅者接收到信号中全部的值（不管是之前发出的值还是将来发出的值）。

　　

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
RACSubject *letters = [RACSubject subject];
  RACSignal *signal= [letters replay];
  
  NSLog(@"Subscribe S1");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S1: %@", x);
  }];
  
  NSLog(@"Send A");
  [letters sendNext:@"A"];
  NSLog(@"Send B");
  [letters sendNext:@"B"];
  
  NSLog(@"Subscribe S2");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S2: %@", x);
  }];
  
  NSLog(@"Send C");
  [letters sendNext:@"C"];
  NSLog(@"Send D");
  [letters sendNext:@"D"];
  
  NSLog(@"Subscribe S3");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S3: %@", x);
  }];
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Subscribe S1  
  
Send A  
S1: A
  
Send B
S1: B
  
Subscribe S2
S2: A
S2: B
  
Send C
S1: C
S2: C
  
Send D
S1: D
S2: D
  
Subscribe S3
S3: A
S3: B
S3: C
S3: D

　　尽管订阅者S3在所有的值发送之后再订阅，然后还能接收到所有的值。

Subscribing to a -replayLast Signal

　　这个replayLast返回一个新的信号，当源信号被订阅时，会立即发送给订阅者最新的值，不会重复执行源信号中的订阅代码。订阅者还会收到信号未来所有的值。

　　对于第一个例子，跟之前replay一样，所以我就不再次演示了。

　　第二个例子演示如何将最新的值提供给新的订阅者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
RACSubject *letters = [RACSubject subject];
  RACSignal *signal= [letters replayLast];
  
  NSLog(@"Subscribe S1");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S1: %@", x);
  }];
  
  NSLog(@"Send A");
  [letters sendNext:@"A"];
  NSLog(@"Send B");
  [letters sendNext:@"B"];
  
  NSLog(@"Subscribe S2");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S2: %@", x);
  }];
  
  NSLog(@"Send C");
  [letters sendNext:@"C"];
  NSLog(@"Send D");
  [letters sendNext:@"D"];
  
  NSLog(@"Subscribe S3");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S3: %@", x);
  }];
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Subscribe S1
  
Send A
S1: A
  
Send B
S1: B
  
Subscribe S2
S2: B
  
Send C
S1: C
S2: C
  
Send D
S1: D
S2: D
  
Subscribe S3
S3: D

Subscribing to a -replayLazily Signal

　　这replayLazily方法返回一个新的信号，当源信号被订阅时，会立即发送给订阅者全部历史的值，不会重复执行源信号中的订阅代码。跟replay不同的是，replayLazily被订阅生成新的信号之前是不会对源信号进行订阅的（原文写的有点绕，简单来讲 直到订阅时候才真正创建一个信号，源信号的订阅代码才开始执行）。暂时不理解也没事，看下面的代码输出，和注释。

　这第一个例子会说明跟replay差异。 注意字符串“Increment num to: 1”是被订阅了之后才打印显示的。而replay和replayLast没被订阅前就打印了“Increment num to: 1” 这个消息。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
__blockintnum = 0;
  RACSignal *signal= [[RACSignal createSignal:^RACDisposable *(id  subscriber) {
      num++;
      NSLog(@"Increment num to: %i", num);
      [subscriber sendNext:@(num)];
      returnnil;
  }] replayLazily];  //跟replay不同的就这么一个地方
  
  NSLog(@"Start subscriptions");
  
  // Subscriber 1 (S1)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S1: %@", x);
  }];
  
  // Subscriber 2 (S2)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S2: %@", x);
  }];
  
  // Subscriber 3 (S3)
  [signalsubscribeNext:^(id x) {
      NSLog(@"S3: %@", x);
  }];
1
2
3
4
5
6
7
// 帖子滚动起来，跟replay比较一下 Increment num to: 1 的显示顺序。
 
Start subscriptions     // 实际订阅
Increment num to: 1 // 信号开始创建
S1: 1
S2: 1
S3: 1

　　第二个例子演示将全部历史的值提供给任何新的订阅者，就像replay一样。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
RACSubject *letters = [RACSubject subject];
  RACSignal *signal= [letters replayLazily];
  
  NSLog(@"Subscribe S1");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S1: %@", x);
  }];
  
  NSLog(@"Send A");
  [letters sendNext:@"A"];
  NSLog(@"Send B");
  [letters sendNext:@"B"];
  
  NSLog(@"Subscribe S2");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S2: %@", x);
  }];
  
  NSLog(@"Send C");
  [letters sendNext:@"C"];
  NSLog(@"Send D");
  [letters sendNext:@"D"];
  
  NSLog(@"Subscribe S3");
  [signalsubscribeNext:^(id x) {
      NSLog(@"S3: %@", x);
  }];
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Subscribe S1
  
Send A
S1: A
  
Send B
S1: B
  
Subscribe S2
S2: A
S2: B
  
Send C
S1: C
S2: C
  
Send D
S1: D
S2: D
  
Subscribe S3
S3: A
S3: B
S3: C
S3: D

　　总结一下：

　　ReactiveCocoa提供了这三个简便的方法允许多个订阅者订阅一个信号，却不会重复执行订阅代码，并且能给新加的订阅者提供订阅前的值。replay和replayLast使信号变成热信号，且会提供所有值(-replay) 或者最新的值(-replayLast) 给订阅者。replayLazily返回一个冷的信号，会提供所有的值给订阅者。

ReactiveCocoa & MVVM 学习总结一
lihei12345的专栏
06-16 7875
主要是为了总结学习RAC的过程中，遇到的一些困惑点，一些阅读的参考资料，文笔也不是很好。建议大家学习RAC参考文章： https://github.com/ReactiveCocoa/ReactiveCocoa/tree/master/Documentation以及花瓣工程师的一篇很棒的文章: http://limboy.me/ios/2014/06/06/deep-into-reactivec
细说ReactiveCocoa的冷信号与热信号（三）：怎么处理冷信号与热信号
一个有情怀的程序猿博客
07-10 334
第一篇文章中我们介绍了冷信号与热信号的概念，前一篇文章我们也讨论了为什么要区分冷信号与热信号，下面我会先为大家揭晓热信号的本质，再给出冷信号转换成热信号的方法。 揭示热信号的本质 在ReactiveCocoa中，究竟什么才是热信号呢？冷信号是比较常见的，map一下就会得到一个冷信号。但在RAC中，好像并没有“hot signal”这个单独的说法。原来在RAC的世界中，所有的热信号都属于一个类——RACSubject。接下来我们来看看究竟它为什么这么“神奇”。 在RAC2.5文档的框架概述中，有着这..
Comparing replay, replayLast, and replayLazily
Secret Island
07-10 909
A co-worker recently asked me about the difference between -replay, -replayLast, and-replayLazily in the ReactiveCocoa library. I had a vague understanding of the three but was not able to confi
Reactivecocoa-publish、multicast、replay、replayLast
CodeMachine的专栏
08-27 1169
//-replay 总是收取最后的内容,而并不执行signal 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 __block int num = 0; RACSignal *signal = [[RACSignal createSignal:^RACDisposable *(i
转：RAC中比较replay, replayLast, and replayLazily
weixin_30379973的博客
07-31 152
A co-worker recently asked me about the difference between-replay,-replayLast, and-replayLazilyin theReactiveCocoalibrary. I had a vague understanding of the three but was not able to confi...
http-replay:用于重放和比较 HTTP 请求和响应的库
06-28
这是一个在测试中重放请求和响应的库。 它允许过滤响应以删除值，一个不想断言的值。 支持的工具 支持的录音（阅读器）： 支持的框架（MessageHandler）： 工作流程 使用此测试助手的工作流程可能是： 首先使用 ...
pysc2-replay:在《星际争霸II》中检查动作和观察的框架重播
05-08
pysc2-重放 用于在StarCraftII中检查动作和观察的框架... $ ./transform_replay.py --replay ~/StarCraftII/Replays/DefeatRoaches/DefeatRoaches_2017-09-04-19-42-10.SC2Replay --agent ObserverAgent.ObserverAgent
Cygwin及windows上安装tcpreplay必要软件
06-07
在Windows操作系统上，为了进行网络数据包的回放和分析，常常需要用到tcpreplay这款工具。tcpreplay是一个开源的网络测试工具，主要用于在网络设备、应用程序或者服务上重放捕获的数据包，这对于网络性能测试、故障...
安装tcpreplay，相关依赖包
03-17
在Linux服务器上安装tcpreplay，需要的离线包 1.安装gcc 2.执行脚本 sh libpcap-install 3.执行完脚本，会出现四个安装包分别是Bison、flex、libpcap、m4 4.依次进入Bison、flex、libpcap、m4执行以下命令： #./...
linux设备tcpreplay安装
06-17
在Linux设备上安装tcpreplay包回放工具
RACSignal的Subscription深入分析
美团技术团队
06-30 668
ReactiveCocoa是一个FRP的思想在Objective-C中的实现框架，目前在美团的项目中被广泛使用。对于ReactiveCocoa的基本用法，网上有很多相关的资料，本文不再讨论。RACSignal是ReactiveCocoa中一个非常重要的概念，而本文主要关注RACSignal的实现原理。在阅读之前，你需要基本掌握RACSignal的基本用法 本文主要包含2个部分，前半...
冷热信号
韩钊钊钊钊的专栏
12-25 368
冷热信号区别： 热信号是主动的，即使你没有订阅事件，它仍然会时刻推送 而冷信号是被动的，只有当你订阅的时候，它才会发送消息 热信号可以有多个订阅者，是一对多，信号可以与订阅者共享信息 而冷信号只能一对一，当有不同的订阅者，消息会重新完整发送，热信号像是一个广播。冷信号像是一个模板，不同的订阅者会生成一个实例 热信号会被所有此刻已订阅的地方各执行一次，以后订阅的地方会错过之前的消息 一个很重要的概念
RAC学习二-RACReplaySubject
信者的路
05-29 588
上图是RACSubject和RACReplaySubejct订阅信号的方法，RACReplaySubject是继承自RACSubject，所以RACReplaySubject既可以当做信号又可发送信号，但与RACSubject不同的是，RACSubject必须先订阅信号后发送信号，但RACReplaySubject既可以先订阅信号后发送信号，又可以先发送信号后订阅信号，即 1. 创建信号...
王树森深度强化学习课程学习笔记与代码实现项目-深度强化学习理论解析算法推导PyTorch实战案例Q-learning策略梯度Actor-Critic蒙特卡洛方法时.zip
11-27
王树森深度强化学习课程学习笔记与代码实现项目_深度强化学习理论解析算法推导PyTorch实战案例Q-learning策略梯度Actor-Critic蒙特卡洛方法时.zipVS Code EIDE开发环境配置
沂沭河区.zip
11-27
三级水系流域矢量数据，数据格式shp格式，坐标系wgs84，真实可靠可打开，放心使用
李仙江.zip
11-27
三级水系流域矢量数据，数据格式shp格式，坐标系wgs84，真实可靠可打开，放心使用
五次多项式换道转向避撞轨迹规划可视化Matlab代码（分析不同车速与路面附着系数对换道时间、距离及横向加速度的影响）分析车速与路面
最新发布
11-27
五次多项式换道转向避撞轨迹规划可视化Matlab代码（分析不同车速与路面附着系数对换道时间、距离及横向加速度的影响）内容概要：本文档主要介绍了一个基于五次多项式进行换道转向避撞轨迹规划的Matlab仿真代码，重点分析了不同车速与路面附着系数对车辆换道时间、换道距离以及横向加速度的影响。通过可视化手段展示轨迹规划结果，帮助研究人员深入理解自动驾驶中路径规划的安全性与舒适性指标。该资源属于一系列科研仿真工具的一部分，涵盖路径规划、智能优化、电力系统、信号处理等多个领域，突出Matlab/Simulink在工程仿真中的应用价值。; 适合人群：具备一定Matlab编程基础，从事自动驾驶、智能交通系统、车辆工程或路径规划相关研究的研究生、科研人员及工程技术人员。; 使用场景及目标：①研究自动驾驶中安全换道轨迹的生成方法；②分析车辆动力学参数与道路条件对换道性能的影响；③为高级驾驶辅助系统（ADAS）和无人驾驶决策控制系统提供算法支持与仿真验证。; 阅读建议：建议结合Matlab代码与文档内容同步运行仿真，调整车速与路面附着系数等参数，观察换道轨迹与加速度变化趋势，深入理解五次多项式在连续平滑轨迹生成中的优势，并可进一步拓展至动态障碍物避撞或多车协同换道场景。
智能天线原理与MATLAB实践
11-27
本书系统讲解智能天线的基本原理与前沿技术，涵盖电磁场基础、天线阵列、随机过程、信道模型、到达角估计、自适应波束成形等内容。结合MATLAB仿真，帮助读者深入理解智能天线在无线通信、雷达等领域的应用。适合电子信息类研究生及工程师阅读，配套代码便于动手实践，助力掌握现代阵列信号处理核心技术。
live 和replay区别
10-15
在流媒体和视频处理领域，**Live（直播）** 和 **Replay（回放/重播）** 是两种不同的内容传输模式，主要区别体现在 **实时性、数据来源、交互性** 等方面。以下是详细对比： --- ### **1. 核心区别** | **特性** | **Live（直播）** | **Replay（回放）** | |-------------------|------------------------------------------|----------------------------------------| | **实时性** | 数据实时生成和传输，延迟通常为秒级 | 播放已存储的完整文件或录播流，无实时性 | | **数据来源** | 摄像头、编码器实时采集 | 磁盘文件、录像片段、云端存储 | | **交互性** | 观众无法控制进度（如暂停/跳转） | 支持暂停、快进、拖动进度条 | | **协议支持** | RTMP、SRT、HLS（低延迟模式）、WebRTC | HLS、DASH、MPEG-DASH（分段下载） | | **典型场景** | 赛事直播、视频会议、监控实时画面 | 点播视频、课程录像、监控录像回看 | --- ### **2. 技术实现差异** #### **Live（直播）** - **推流与分发** - 主播端通过 **RTMP** 或 **SRT** 将实时视频流推送到服务器（如 CDN）。 - 服务器通过 **HLS** 或 **低延迟协议** 分发给观众。 - **关键挑战** - **延迟优化**：需平衡延迟与稳定性（如 WebRTC 可达 500ms 以下）。 - **抗丢包**：使用 UDP 协议（如 RTP）或重传机制（如 RTX）。 #### **Replay（回放）** - **存储与分发** - 视频文件预先切片（如 HLS 的 `.ts` 分段）并存储在服务器。 - 观众按需下载分段文件，支持 **随机访问**（如跳转到任意时间点）。 - **关键挑战** - **CDN 缓存**：优化热门内容的边缘节点缓存命中率。 - **兼容性**：确保播放器支持多种封装格式（如 MP4、FLV）。 --- ### **3. 协议与示例** #### **直播协议示例** ```bash # RTMP 推流（直播） ffmpeg -i input.mp4 -c:v libx264 -f flv rtmp://server/live/stream_key # HLS 低延迟模式（LL-HLS） # 需服务器支持分块传输（chunked）和推送（push）。 ``` #### **回放协议示例** ```bash # HLS 点播（回放） ffmpeg -i input.mp4 -c:v h264 -hls_time 10 -hls_list_size 0 output.m3u8 # 生成分段文件（output0.ts, output1.ts...）和播放列表（.m3u8）。 ``` --- ### **4. 用户场景对比** - **直播场景** - 观众：实时参与互动（如弹幕、打赏）。 - 主播：需处理突发流量和网络抖动。 - **回放场景** - 观众：自主控制播放节奏，适合学习或复盘。 - 服务端：需高效存储和检索历史视频。 --- ### **5. 混合模式（Live-to-Replay）** 部分系统支持 **直播转点播**： 1. 实时直播流被同步录制为文件。 2. 直播结束后自动生成回放链接（如 Zoom 会议录制）。 3. 技术实现：通过 **DVR（Digital Video Recording）** 功能。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值