关于架构:淘宝iOS扫一扫架构升级-设计模式的应用

本文在“扫一扫性能的一直迭代，基于设计模式的根本准则，逐渐采纳设计模式思维进行代码和架构优化”的背景下，对设计模式在扫一扫中新的利用进行了总结。

背景

扫一扫是淘宝镜头页中的一个重要组成，性能运行长远，其历史代码中较少采纳面向对象编程思维，而较多采纳面向过程的程序设计。
随着扫一扫性能的一直迭代，咱们基于设计模式的根本准则，逐渐采纳设计模式思维进行代码和架构优化。本文就是在这个背景下，对设计模式在扫一扫中新的利用进行了总结。

扫一扫原架构

扫一扫的原架构如图所示。其中逻辑 & 展示层的性能逻辑很多，并没有良好的设计和拆分，举几个例子：
所有码的解决逻辑都写在同一个办法体里，一个办法就靠近 2000 多行。
宏大的码解决逻辑写在 viewController 中，与 UI 逻辑耦合。
依照现有的代码设计，若要对某种码逻辑进行批改，都必须将所有逻辑全量编译。如果持续沿用此代码，扫一扫的可维护性会越来越低。

因而咱们须要对代码和架构进行优化，在这里优化遵循的思路是：
理解业务能力
理解原有代码逻辑，不确定的中央通过埋点等形式线上验证对原有代码性能进行重写 / 重构
编写单元测试，提供测试用例
测试 & 上线

扫码能力综述

扫一扫的解码能力决定了扫一扫可能解决的码类型，这里称为一级分类。基于一级分类，扫一扫会依据码的内容和类型，再进行二级分类。之后的逻辑，就是针对不同的二级类型，做相应的解决，如下图为技术链路流程。

设计模式

责任链模式

上述技术链路流程中，码解决流程对应的就是原有的 viewController 外面的巨无霸逻辑。通过梳理咱们看到，码解决其实是一条链式的解决，且有前后依赖关系。优化计划有两个，计划一是拆解成多个办法顺序调用；计划二是参考苹果的 NSOperation 独立计算单元的思路，拆解成多个码处理单元。计划一实质还是没解决开闭准则（对扩大凋谢，对批改关闭）问的题。计划二是一个比拟好的实际形式。那么怎么设计一个简略的构造来实现此逻辑呢？
码解决链路的特点是，链式解决，可管制解决的程序，每个码处理单元都是繁多职责，因而这里引出革新第一步：责任链模式。
责任链模式是一种行为设计模式，它将申请沿着解决者链进行发送。收到申请后，每个解决者均可对申请进行解决，或将其传递给链上的下个解决者。
本文设计的责任链模式，蕴含三局部：
创立数据的 Creator 治理处理单元的
Manager 处理单元
Pipeline‍
三者构造如图所示

创立数据的 Creator

蕴含的性能和特点：
因为数据是基于业务的，所以它只被申明为一个 Protocol，由下层实现。
Creator 对数据做对象化，对象生成后 self.generateDataBlock(obj, Id) 即开始执行
API 代码示例如下

/// 数据产生协定 <CreatorProtocol>
@protocol TBPipelineDataCreatorDelegate <NSObject>
@property (nonatomic, copy) void(^generateDataBlock)(id data, NSInteger dataId);
@end

下层业务代码示例如下

@implementation TBDataCreator
@synthesize generateDataBlock;
- (void)receiveEventWithScanResult:(TBScanResult *)scanResult
                     eventDelegate:(id <TBScanPipelineEventDeletate>)delegate {
    // 对数据做对象化                
    TBCodeData *data = [TBCodeData new];
    data.scanResult = scanResult;
    data.delegate = delegate;

    NSInteger dataId = 100;
    // 开始执行递归
    self.generateDataBlock(data, dataId);
}
@end

治理处理单元的 Manager

蕴含的性能和特点：
治理创立数据的 Creator
治理处理单元的 Pipeline
采纳反对链式的点语法，不便书写
API 代码示例如下

@interface TBPipelineManager : NSObject
/// 增加创立数据 Creator
- (TBPipelineManager *(^)(id<TBPipelineDataCreatorDelegate> dataCreator))addDataCreator;
/// 增加处理单元 Pipeline
- (TBPipelineManager *(^)(id<TBPipelineDelegate> pipeline))addPipeline;
/// 抛出通过一系列 Pipeline 的数据。当 Creator 开始调用 generateDataBlock 后，Pipeline 就开始执行
@property (nonatomic, strong) void(^throwDataBlock)(id data);
@end

实现代码示例如下

@implementation TBPipelineManager
- (TBPipelineManager *(^)(id<TBPipelineDataCreatorDelegate> dataCreator))addDataCreator {
    @weakify
    return ^(id<TBPipelineDataCreatorDelegate> dataCreator) {
        @strongify
        if (dataCreator) {[self.dataGenArr addObject:dataCreator];
        }
        return self;
    };
}

- (TBPipelineManager *(^)(id<TBPipelineDelegate> pipeline))addPipeline {
    @weakify
    return ^(id<TBPipelineDelegate> pipeline) {
        @strongify
        if (pipeline) {[self.pipelineArr addObject:pipeline];

            // 每一次 add 的同时，咱们做链式标记（通过 runtime 给每个解决加 Next）if (self.pCurPipeline) {NSObject *cur = (NSObject *)self.pCurPipeline;
                cur.tb_nextPipeline = pipeline;
            }
            self.pCurPipeline = pipeline;
        }
        return self;
    };
}

- (void)setThrowDataBlock:(void (^)(id _Nonnull))throwDataBlock {
    _throwDataBlock = throwDataBlock;

    @weakify
    //Creator 的数组，顺次对 Block 回调进行赋值，当业务方调用此 Block 时，就是开始解决数据的时候
    [self.dataGenArr enumerateObjectsUsingBlock:^(id<TBPipelineDataCreatorDelegate>  _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {obj.generateDataBlock = ^(id<TBPipelineBaseDataProtocol> data, NSInteger dataId) {
            @strongify
            data.dataId = dataId;
            // 开始递归解决数据
            [self handleData:data];
        };
    }];
}

- (void)handleData:(id)data {[self recurPipeline:self.pipelineArr.firstObject data:data];
}

- (void)recurPipeline:(id<TBPipelineDelegate>)pipeline data:(id)data {if (!pipeline) {return;}

    // 递归让 pipeline 解决数据
    @weakify
    [pipeline receiveData:data throwDataBlock:^(id  _Nonnull throwData) {
        @strongify
        NSObject *cur = (NSObject *)pipeline;
        if (cur.tb_nextPipeline) {[self recurPipeline:cur.tb_nextPipeline data:throwData];
        } else {!self.throwDataBlock?:self.throwDataBlock(throwData);
        }
    }];
}
@end

处理单元 Pipeline

蕴含的性能和特点：
因为数据是基于业务的，所以它只被申明为一个 Protocol，由下层实现。

API 代码示例如下

@protocol TBPipelineDelegate <NSObject>
// 如果有谬误，间接抛出
- (void)receiveData:(id)data throwDataBlock:(void(^)(id data))block;
@end

下层业务代码示例如下

// 以 A 类型码码处理单元为例
@implementation TBGen3Pipeline
- (void)receiveData:(id <TBCodeDataDelegate>)data throwDataBlock:(void (^)(id data))block {
    TBScanResult *result = data.scanResult;
    NSString *scanType = result.resultType;
    NSString *scanData = result.data;

    if ([scanType isEqualToString:TBScanResultTypeA]) {
        // 跳转逻辑
        ...
        // 能够解决，终止递归
        BlockInPipeline();} else {
        // 不满足解决条件，持续递归：由下一个 Pipeline 持续解决
        PassNextPipeline(data);
    }
}
@end

业务层调用

有了上述的框架和下层实现，生成一个码解决治理就很容易且能达到解耦的目标，代码示例如下

- (void)setupPipeline {
    // 创立 manager 和 creator
    self.manager = TBPipelineManager.new;
    self.dataCreator = TBDataCreator.new;

    // 创立 pipeline
    TBCodeTypeAPipelie *codeTypeAPipeline = TBCodeTypeAPipelie.new;
    TBCodeTypeBPipelie *codeTypeBPipeline = TBCodeTypeBPipelie.new;
    //...
    TBCodeTypeFPipelie *codeTypeFPipeline = TBCodeTypeFPipelie.new;

    // 往 manager 中链式增加 creator 和 pipeline
    @weakify
    self.manager
    .addDataCreator(self.dataCreator)
    .addPipeline(codeTypeAPipeline)
    .addPipeline(codeTypeBPipeline) 
    .addPipeline(codeTypeFPipeline) 
    .throwDataBlock = ^(id data) {
        @strongify
        if ([self.proxyImpl respondsToSelector:@selector(scanResultDidFailedProcess:)]) {[self.proxyImpl scanResultDidFailedProcess:data];
        }
    };
}

状态模式

回头来看下码展现的逻辑，这是咱们用户体验优化的重要一项内容。码展现的意思是对于以后帧 / 图片，辨认到的码地位，咱们进行锚点的高亮并跳转。这里蕴含三种状况：
未辨认到码的时候，无锚点展现
辨认到单码的时候，展现锚点并在指定工夫后跳转
辨认到多码额时候，展现锚点并期待用户点击
能够看到，这里波及到简略的展现状态切换，这里就引出革新的第二步：状态模式

状态模式是一种行为设计模式，能在一个对象的外部状态变动时扭转其行为，使其看上去就像扭转了本身所属的类一样。
本文设计的状态模式，蕴含两局部：
状态的信息 StateInfo
状态的基类 BaseState
两者构造如图所示

状态的信息 StateInfo

蕴含的性能和特点：
以后上下文仅有一种状态信息流转
业务方能够保留多个状态键值对，状态依据须要执行相应的代码逻辑。
状态信息的申明和实现代码示例如下

@interface TBBaseStateInfo : NSObject {
    @private
    TBBaseState<TBBaseStateDelegate> *_currentState; // 记录以后的 State
}
// 应用以后的 State 执行
- (void)performAction;
// 更新以后的 State
- (void)setState:(TBBaseState <TBBaseStateDelegate> *)state;
// 获取以后的 State
- (TBBaseState<TBBaseStateDelegate> *)getState;
@end

@implementation TBBaseStateInfo
- (void)performAction {
    // 以后状态开始执行
    [_currentState perfromAction:self];
}
- (void)setState:(TBBaseState <TBBaseStateDelegate> *)state {_currentState = state;}
- (TBBaseState<TBBaseStateDelegate> *)getState {return _currentState;}
@end

下层业务代码示例如下

typedef NS_ENUM(NSInteger, TBStateType) {
    TBStateTypeNormal, // 空状态
    TBStateTypeSingleCode, // 单码展现态
    TBStateTypeMultiCode, // 多码展现态
};

@interface TBStateInfo : TBBaseStateInfo
// 以 key-value 的形式存储业务 type 和对应的状态 state
- (void)setState:(TBBaseState<TBBaseStateDelegate> *)state forType:(TBStateType)type;
// 更新 type，并执行 state
- (void)setType:(TBStateType)type;
@end

@implementation TBStateInfo

- (void)setState:(TBBaseState<TBBaseStateDelegate> *)state forType:(TBStateType)type {[self.stateDict tb_setObject:state forKey:@(type)];
}

- (void)setType:(TBStateType)type {id oldState = [self getState];
    // 找到以后能响应的状态
    id newState = [self.stateDict objectForKey:@(type)];
    // 如果状态未产生变更则疏忽
    if (oldState == newState)
        return;
    if ([newState respondsToSelector:@selector(perfromAction:)]) {[self setState:newState];
        // 转态基于以后的状态信息开始执行
        [newState perfromAction:self];
    }
}
@end

状态的基类 BaseState

蕴含的性能和特点：
定义了状态的基类
申明了状态的基类须要遵循的 Protocol
Protocol 如下，基类为空实现，子类继承后，实现对 StateInfo 的解决。

@protocol TBBaseStateDelegate <NSObject>
- (void)perfromAction:(TBBaseStateInfo *)stateInfo;
@end

下层（以单码 State 为例）代码示例如下

@interface TBSingleCodeState : TBBaseState
@end

@implementation TBSingleCodeState

// 实现 Protocol
- (void)perfromAction:(TBStateInfo *)stateAction {
    // 业务逻辑解决 Start
    ...
    // 业务逻辑解决 End
}

@end

业务层调用

以下代码生成一系列状态，在适合时候进行状态的切换。

// 状态初始化
- (void)setupState {
    TBSingleCodeState *singleCodeState = TBSingleCodeState.new; // 单码状态
    TBNormalState *normalState = TBNormalState.new; // 失常状态
    TBMultiCodeState *multiCodeState = [self getMultiCodeState]; // 多码状态

    [self.stateInfo setState:normalState forType:TBStateTypeNormal];
    [self.stateInfo setState:singleCodeState forType:TBStateTypeSingleCode];
    [self.stateInfo setState:multiCodeState forType:TBStateTypeMultiCode];
}

// 切换惯例状态
- (void)processorA {
    //...
    [self.stateInfo setType:TBStateTypeNormal];
    //...
}

// 切换多码状态
- (void)processorB {
    //...
    [self.stateInfo setType:TBStateTypeMultiCode];
    //...
}

// 切换单码状态
- (void)processorC {
    //...
    [self.stateInfo setType:TBStateTypeSingleCode];
    //...
}

最好依据状态机图编写状态切换代码，以保障每种状态都有对应的流转。

代理模式

在开发过程中，咱们会在越来越多的中央应用到上图能力，比方「淘宝拍照」的相册中、「扫一扫」的相册中，用到解码、码展现、码解决的能力。因而，咱们须要把这些能力封装并做成插件化，以便在任何中央都可能应用。这里就引出了咱们革新的第三步：代理模式。代理模式是一种结构型设计模式，可能提供对象的替代品或其占位符。代理管制着对于原对象的拜访，并容许在将申请提交给对象前后进行一些解决。本文设计的状态模式，蕴含两局部：代理单例 GlobalProxy 代理的治理 ProxyHandler 两者构造如图所示

代理单例 GlobalProxy

单例的目标次要是缩小代理反复初始化，能够在适合的机会初始化以及清空保留的内容。单例模式对于 iOSer 再相熟不过了，这里不再赘述。

代理的治理 Handler

保护一个对象，提供了对代理增删改查的能力，实现对代理的操作。
这里实现 Key – Value 的 Key 为 Protocol，Value 为具体的代理。
代码示例如下

+ (void)registerProxy:(id)proxy withProtocol:(Protocol *)protocol {if (![proxy conformsToProtocol:protocol]) {NSLog(@"#TBGlobalProxy, error");
        return;
    }
    if (proxy) {[[TBGlobalProxy sharedInstance].proxyDict setObject:proxy forKey:NSStringFromProtocol(protocol)];
    }
}

+ (id)proxyForProtocol:(Protocol *)protocol {if (!protocol) {return nil;}
    id proxy = [[TBGlobalProxy sharedInstance].proxyDict objectForKey:NSStringFromProtocol(protocol)];
    return proxy;
}

+ (NSDictionary *)proxyConfigs {return [TBGlobalProxy sharedInstance].proxyDict;
}

+ (void)removeAll {[TBGlobalProxy sharedInstance].proxyDict = [[NSMutableDictionary alloc] init];
}

业务层的调用

所以不论是什么业务方，只有是须要用到对应能力的中央，只须要从单例中读取 Proxy，实现该 Proxy 对应的 Protocol，如一些回调、获取以后上下文等内容，就可能获取该 Proxy 的能力。

// 读取 Proxy 的示例
- (id <TBScanProtocol>)scanProxy {if (!_scanProxy) {_scanProxy = [TBGlobalProxy proxyForProtocol:@protocol(TBScanProtocol)];
    }
    _scanProxy.proxyImpl = self;
    return _scanProxy;
}

// 写入 Proxy 的示例（解耦调用）- (void)registerGlobalProxy {
    // 码解决能力
    [TBGlobalProxy registerProxy:[[NSClassFromString(@"TBScanProxy") alloc] init]
                    withProtocol:@protocol(TBScanProtocol)];
    // 解码能力
    [TBGlobalProxy registerProxy:[[NSClassFromString(@"TBDecodeProxy") alloc] init]
                    withProtocol:@protocol(TBDecodeProtocol)];

扫一扫新架构

基于上述的革新优化，咱们将原扫一扫架构进行了优化：将逻辑 & 展示层进行代码分拆，分为展示层、逻辑层，接口层。以达到层次分明、职责清晰、解耦的目标。

总结

上述积淀的三个设计模式作为扫拍业务的 Foundation 的 Public 能力，利用在镜头页的业务逻辑中。
通过此次重构，进步了扫码能力的复用性，构造和逻辑的清晰带来的是保护老本的升高，不必再海底捞针从代码“巨无霸”中寻找问题，升高了开发人日。