关于架构:淘宝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];    //...}

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

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

代理模式

在开发过程中，咱们会在越来越多的中央应用到上图能力，比方「淘宝拍照」的相册中、「扫一扫」的相册中，用到解码、码展现、码解决的能力。因而，咱们须要把这些能力封装并做成插件化，以便在任何中央都可能应用。这里就引出了咱们革新的第三步：代理模式。代理模式是一种结构型设计模式，可能提供对象的替代品或其占位符。代理管制着对于原对象的拜访，并容许在将申请提交给对象前后进行一些解决。本文设计的状态模式，蕴含两局部：代理单例 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 能力，利用在镜头页的业务逻辑中。
通过此次重构，进步了扫码能力的复用性，构造和逻辑的清晰带来的是保护老本的升高，不必再海底捞针从代码“巨无霸”中寻找问题，升高了开发人日。