全局数据同步（三）终极方案

2017-07-07

在全局数据同步系列文章中（一）（二）分别解决了model和view的全局同步，但是依然有一些问题，所以在这里给一个终极解决方案DDKeyPathChannel。 Star

重新来说明下解决的问题

由于各种原因，目前有两个表示同一种类型的model。

@interface UserModel1 : NSObject

@property (strong, nonatomic) NSString *id;
@property (strong, nonatomic) NSString *name;
@property (assign, nonatomic) NSInteger age;

@end

@interface UserModel2 : NSObject

@property (strong, nonatomic) NSString *id;
@property (strong, nonatomic) NSString *nickName;
@property (assign, nonatomic) NSInteger age;

@end

现在需要其中一个属性修改了，或者第三方要求更新属性，如何更好的同步各个不同model之间的属性呢？

另一个问题，又如何把这个状态更新到UI上呢？

以前方案的问题

首先，来看看之前解决方案的几个问题。

所有基类都需要实现特定接口协议。这对于model来说会比较简单，但是对于UIView来说就比较麻烦。
使用上，实现上比较麻烦，需要注意的地方比较多，容易犯错误。

那么有没有不影响到原来的类的方式呢？

新思路

既然现有的类去实现这个协议比较麻烦，那么找一个第三方类，永久的实现这个接口，并且把消息转发到现有的类不就可以了吗。

我们都知道有一个类不继承于NSObject，功能就是代理，那么我们利用这个类来做消息转发。

接口如下

@interface DDKeyPathChannelBaseProxy : NSProxy <DDKeyPathChannelProtocol>

// 以下两个属性确定对象唯一性
@property (readonly, nonatomic) NSInteger channelType;
@property (readonly, nonatomic) NSString *channelId;

// 原本的对象
@property (weak, readonly, nonatomic) __kindof NSObject *target;

- (instancetype)initWithChannelType:(NSInteger)channelType channelId:(NSString *)channelId target:(NSObject *)target;

@end

// 这是一个通过keyPath+白名单的实现，可以通过mapper来映射真正的keyPath
@interface DDKeyPathChannelProxy : DDKeyPathChannelBaseProxy

@property (strong, nonatomic) NSArray<NSString *> *whiteList;
@property (strong, nonatomic) NSDictionary<NSString *, NSString *> *keyPathMapper; // messageKeyPath : realKeyPath

@property (strong, nonatomic) void(^valueWillChangeBlock)(__kindof NSObject *target, NSString *keyPath, __kindof id newValue);
@property (strong, nonatomic) void(^valueDidChangeBlock)(__kindof NSObject *target, NSString *keyPath, __kindof id newValue);

@end

// 这是一个block的实现，可以在同步的时候自定义转换与实现
@interface DDKeyPathBlockChannelProxy : DDKeyPathChannelBaseProxy

@property (strong, nonatomic) NSString *keyPath;

@property (strong, nonatomic) void(^valueChangedBlock)(__kindof NSObject *target, NSString *keyPath, __kindof id newValue);

@end

转发的核心在于消息的传递

// keyPath
- (void)setValue:(id)value forKey:(NSString *)key {
    if (self.valueWillChangeBlock) self.valueWillChangeBlock(self.target, key, value);
    [self.target setValue:value forKey:key];
    if (self.valueDidChangeBlock) self.valueDidChangeBlock(self.target, key, value);
}

// block
- (void)setValue:(id)value forKey:(NSString *)key {
    if ([key isEqualToString:self.keyPath]) {
        if (self.valueChangedBlock) {
            self.valueChangedBlock(self.target, key, value);
        }
    }
}

那么我们怎么去挂载这个代理对象呢，想到associate object，那么我们也很容易的控制自己的生命周期了。

这样，我们就不需要在现有类中实现方法来支持该功能了，而且这样也更好的封装屏蔽了这些比较特殊的功能。在实践中感觉这种方式的使用成本是最低的，大家也比较容易接受。

[self.user1 bindChannelType:ChannelTypeUser
                  channelId:self.user1.id];
[self.user2 addChannelProxyWithChannelType:ChannelTypeUser
                                 channelId:self.user2.id
                                    config:^(DDKeyPathChannelProxy *proxy) {
                                        proxy.keyPathMapper = @{ @"name": @"nickName" };
}];
// 更新属性
[[DDKeyPathChannelManager sharedChannel] emitChannelType:ChannelTypeUser
                                               channelId:@"1"
                                                   value:@"Tom"
                                              forKeyPath:@"name"];
[[DDKeyPathChannelManager sharedChannel] emitChannelType:ChannelTypeUser
                                               channelId:@"1"
                                                   value:@(30)
                                              forKeyPath:@"age"];

UI层更新也可以通过这种方式，也可以选择使用KVO。

题外话

关于这个功能，很多人肯定想到了ReactiveX，关于这点，两者的确有部分相似的场景，但也有很多不同的地方。

关于更新UI这点，两者从效果上来看的确是一致的

1	object -> (signal, keyPath) -> UI

两者最大的不同在于，ReactiveX是monad的思想，是有输入输出，拥有明确的输入对象和观察对象，行为流程是从上游到下游。而本套方案是一个中间人模式，是一个星状结构，更像通知一点。

但是两者思想是类似的，ReactiveX是把各种行为封装成Signal，而我们是把消息使用keyPath来承载与转发。

如果想要使用ReactiveX来实现这个功能也不是不可以，创建一个全局的热型号(subject)，控制好回收(dispose)，也是可以实现该功能，但总感觉和RX的概念有点偏差了。

总结

从第一篇方案，到现在最终比较完美的一套方案，也是因为我们的需求在一步一步的变化，要求我们使用更好、更灵活的方案才能满足的结果。这个过程是一个不断思考不断反思的过程，从这个方案的演化中，我深有感悟，很多东西在创造出来的时候看似完美，但实际上还有很大的完善空间，同时别人的方案也会对自己的想法有很多的帮助。所以多了解别人的实现方案对自己的提升还是很有帮助的。