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

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

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

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

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

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

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

蕴含的性能和特点：
因为数据是基于业务的，所以它只被申明为一个 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

蕴含的性能和特点：
治理创立数据的 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

蕴含的性能和特点：
因为数据是基于业务的，所以它只被申明为一个 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
两者构造如图所示

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

@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

蕴含的性能和特点：
定义了状态的基类
申明了状态的基类须要遵循的 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];
    //...
}

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

次态→初态↓	状态 A	状态 B	状态 C
状态 A	条件 A	…	…
状态 B	…	…	…
状态 C	…	…	…

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

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

保护一个对象，提供了对代理增删改查的能力，实现对代理的操作。
这里实现 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 能力，利用在镜头页的业务逻辑中。
通过此次重构，进步了扫码能力的复用性，构造和逻辑的清晰带来的是保护老本的升高，不必再海底捞针从代码“巨无霸”中寻找问题，升高了开发人日。

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

背景

扫一扫原架构

扫码能力综述

设计模式

责任链模式

创立数据的 Creator

治理处理单元的 Manager

处理单元 Pipeline

业务层调用

状态模式

状态的信息 StateInfo

状态的基类 BaseState

业务层调用

代理模式

代理单例 GlobalProxy

代理的治理 Handler

业务层的调用

扫一扫新架构

总结

Just My Socks（注册教程内含优惠码）

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

背景

扫一扫原架构

扫码能力综述

设计模式

责任链模式

创立数据的 Creator

治理处理单元的 Manager

处理单元 Pipeline

业务层调用

状态模式

状态的信息 StateInfo

状态的基类 BaseState

业务层调用

代理模式

代理单例 GlobalProxy

代理的治理 Handler

业务层的调用

扫一扫新架构

总结

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）