（整个关于ReactiveCocoa的代码工程可以在https://github.com/qianhongqiang/QHQReactive下载）
上一章节简要的说明了如何实现的热信号。但是像那么写，貌似不是非常优雅。这一章节我们会把冷热信号转换写的跟ReactiveCocoa一样优雅。
ReactiveCocoa内部是如何实现冷热信号转换的呢？我们来看个例子
RACSignal *replayLazilySignal = [[RACSignal createSignal:^RACDisposable *(id<RACSubscriber> subscriber) {
NSLog(@"replaylazily---sendAction");
[subscriber sendNext:@"replaylazily"];
return nil;
}] replayLazily];
[replayLazilySignal subscribeNext:^(id x) {
NSLog(@"subscribe1----%@",x);
}];
[replayLazilySignal subscribeNext:^(id x) {
NSLog(@"subscribe2----%@",x);
}];
没错，只是在原有信号的基础上，增加了一个replayLazily方法掉用。我们从输出上可以看看，是否转为了热信号。
2015-12-29 13:28:03.588 xxxxxx[40933:6054173] <xxxxxx:(232)> replaylazily---sendAction
2015-12-29 13:28:03.589 xxxxxx[40933:6054173] <xxxxxx:(238)> subscribe1----replaylazily
2015-12-29 13:28:03.589 xxxxxx[40933:6054173] <xxxxxx:(242)> subscribe2----replaylazily
发送只有1次，被订阅了两次。那么我们也朝这个目标出发。
我们这次让一个热信号QHQSubject去订阅最初的冷信号，偷偷的将返回改成这个热信号，偷梁换柱而神不知鬼不觉。
-(QHQSignal *)replayLazily {
QHQMulticastConnection *conn = [[QHQMulticastConnection alloc] initWithSourceSignal:self outSignalSubject:[[QHQSubject alloc] init]];
[conn connectSignal];
return conn.connSignal;
}
这里用到了一个新类，用于做这层转化QHQMulticastConnection，它需要一个源，和一个订阅信号。当执行connectSignal方法后，让热信号订阅最初信号。
-(void)connectSignal {
[_sourceSignal subscribe:_connSignal];
}
让热信号称为接下来流的来源。看似已经天衣无缝了，执行下，看看结果如何
-(void)demoFourReplayLazily {
QHQSignal *replaySignal = [[QHQSignal createSignal:^(id subscriber) {
[subscriber sendNext:@"replaySignal---send"];
}] replayLazily];
[replaySignal subscribeNext:^(id x) {
NSLog(@"sub1 ---- %@",x);
}];
[replaySignal subscribeNext:^(id x) {
NSLog(@"sub2 ---- %@",x);
}];
}
2015-12-29 13:39:59.345 PageText[42204:6070078] replaySignal----send
怎么没有输出订阅的结果呢？确实不应该输出结果，开始分析下原因。当你掉用replayLazily方法时，你已经偷偷摸摸将信号换成了QHQSubject，在这个过程中，你已经订阅了信号，也就是最终的输出结果。让后你再去订阅这个QHQSubject的时候，它做不了任何事情，因为信号的发送已经过去了，过去了，了。我们可以做个延迟发送事件看看。
QHQSignal *replaySignal = [[QHQSignal createSignal:^(id subscriber) {
NSLog(@"replaySignal----send");
[subscriber sendNext:@"replaySignal---send"];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
NSLog(@"Delay-----replaySignal----send");
[subscriber sendNext:@"Delay-----replaySignal---send"];
});
}] replayLazily];
[replaySignal subscribeNext:^(id x) {
NSLog(@"sub1 ---- %@",x);
}];
[replaySignal subscribeNext:^(id x) {
NSLog(@"sub2 ---- %@",x);
}];
发送了两次事件，一次是理解发送，另一次做了延迟。看看结果
2015-12-29 13:45:35.560 PageText[42399:6074028] replaySignal----send
2015-12-29 13:45:37.561 PageText[42399:6074028] Delay-----replaySignal----send
2015-12-29 13:45:37.562 PageText[42399:6074028] sub1 ---- Delay-----replaySignal---send
2015-12-29 13:45:37.562 PageText[42399:6074028] sub2 ---- Delay-----replaySignal---send
延迟发送的事件确实收到了，说明确实转化成了热信号。但是我们总不能每次都延迟一下吧，当然我们可以搞定这个问题，我们让热信号把事件存起来，订阅这订阅后把事件都发送出去。这个时候需要一个可以保存事件的热信号。
因此，我们创建了一个新类继承于QHQSubject
@interface QHQReplaySubject ()
@property (nonatomic, assign) NSUInteger capacity;
@property (nonatomic, strong) NSMutableArray *values;
@end
它会将每次发送来的事件保存在values数组中，如果数组容量大于承载capacity，将会移除掉更早的事件
-(void)sendNext:(id)next {
[_values addObject:next];
[super sendNext:next];
if (_values.count >_capacity) {
[_values removeObjectAtIndex:0];
}
}
它每次被订阅时，都需要首先将已经保存的信号发送给订阅着
-(void)subscribe:(id<QHQSubscrib>)sub {
for (id value in _values) {
[sub sendNext:value];
}
[self.subscribers addObject:sub];
}
这样，第一次的信号就不会丢失。
-(QHQSignal *)replayLazily {
QHQMulticastConnection *conn = [[QHQMulticastConnection alloc] initWithSourceSignal:self outSignalSubject:[QHQReplaySubject replaySubjectWithCapacity:1]];
[conn connectSignal];
return conn.connSignal;
}
简单的将热信号替换成能够保存1个老信号的热信号，那么问题迎刃而解
2015-12-29 14:02:00.766 PageText[43381:6084580] replaySignal----send
2015-12-29 14:02:00.767 PageText[43381:6084580] sub1 ---- replaySignal---send
2015-12-29 14:02:00.767 PageText[43381:6084580] sub2 ---- replaySignal---send
2015-12-29 14:02:02.768 PageText[43381:6084580] Delay-----replaySignal----send
2015-12-29 14:02:02.769 PageText[43381:6084580] sub1 ---- Delay-----replaySignal---send
2015-12-29 14:02:02.770 PageText[43381:6084580] sub2 ---- Delay-----replaySignal---send
输出符合预期
实际上，RAC也是这么做的，不过它将所有的接口都处理成线程安全的。