你敢说你真的了解 代理设计模式？？

iOS中消息传递方式

在iOS中有不少种消息传递方式，这里先简单介绍一下各类消息传递方式。

• 通知：在iOS中由通知中心进行消息接收和消息广播，是一种一对多的消息传递方式。

• 代理：是一种通用的设计模式，iOS中对代理支持的很好，由代理对象、委托者、协议三部分组成。

• block：iOS4.0中引入的一种回调方法，能够将回调处理代码直接写在block代码块中，看起来逻辑清晰代码整齐。

• target action：经过将对象传递到另外一个类中，在另外一个类中将该对象当作target的方式，来调用该对象方法，从内存角度来讲和代理相似。

• KVO：NSObject的Category－NSKeyValueObserving，经过属性监听的方式来监测某个值的变化，当值发生变化时调用KVO的回调方法。

       固然还有其余回调方式，这里只是简单的列举。

代理的基本使用

代理是一种通用的设计模式，在iOS中对代理设计模式支持的很好，有特定的语法来实现代理模式，OC语言能够经过@Protocol实现协议。

代理主要由三部分组成：

• 协议：用来指定代理双方能够作什么，必须作什么。

• 代理：根据指定的协议，完成委托方须要实现的功能。

• 委托：根据指定的协议，指定代理去完成什么功能。

这里用一张图来阐述一下三方之间的关系：

Protocol－协议的概念

从上图中咱们能够看到三方之间的关系，在实际应用中经过协议来规定代理双方的行为，协议中的内容通常都是方法列表，固然也能够定义属性，我会在后续文章中顺带讲一下协议中定义属性。

协议是公共的定义，若是只是某个类使用，咱们常作的就是写在某个类中。若是是多个类都是用同一个协议，建议建立一个Protocol文件，在这个文件中定义协议。遵循的协议能够被继承，例如咱们经常使用的UITableView，因为继承自UIScrollView的缘故，因此也将UIScrollViewDelegate继承了过来，咱们能够经过代理方法获取UITableView偏移量等状态参数。

协议只能定义公用的一套接口，相似于一个约束代理双方的做用。但不能提供具体的实现方法，实现方法须要代理对象去实现。协议能够继承其余协议，而且能够继承多个协议，在iOS中对象是不支持多继承的，而协议能够多继承。

// 当前协议继承了三个协议，这样其余三个协议中的方法列表都会被继承过来

@protocol  LoginProtocol <UITableViewDataSource, UITableViewDelegate, UITextFieldDelegate>- (void)userLoginWithUsername:(NSString *)username password:(NSString *)password;

@end

协议有两个修饰符@optional和@required，建立一个协议若是没有声明，默认是@required状态的。这两个修饰符只是约定代理是否强制须要遵照协议，若是@required状态的方法代理没有遵照，会报一个黄色的警告，只是起一个约束的做用，没有其余功能。

不管是@optional仍是@required，在委托方调用代理方法时都须要作一个判断，判断代理是否实现当前方法，不然会致使崩溃。

示例：

// 判断代理对象是否实现这个方法，没有实现会致使崩溃

if (

    [self.delegate respondsToSelector:@selector(userLoginWithUsername:password:)]) {

    [self.delegate userLoginWithUsername:self.username.text password:self.password.text];

}

下面咱们将用一个小例子来说解一下这个问题：

示例：假设我在公司正在敲代码，敲的正开心呢，忽然口渴了，想喝一瓶红茶。这时我就能够拿起手机去外卖app上定一个红茶，而后外卖app就会下单给店铺并让店铺给我送过来。

这个过程当中，外卖app就是个人代理，我就是委托方，我买了一瓶红茶并付给外卖app钱，这就是购买协议。我只须要从外卖app上购买就能够，具体的操做都由外卖app去处理，我只须要最后接收这瓶红茶就能够。我付的钱就是参数，最后送过来的红茶就是处理结果。

可是我买红茶的同时，我还想吃一份必胜客披萨，我须要另外向必胜客app去订餐，上面的外卖app并无这个功能。我又向必胜客购买了一份披萨，必胜客当作个人代理去为我作这份披萨，并最后送到我手里。这就是多个代理对象，我就是委托方。

在iOS中一个代理能够有多个委托方，而一个委托方也能够有多个代理。我指定了外卖app和必胜客两个代理，也能够再指定麦当劳等多个代理，委托方也能够为多个代理服务。

代理对象在不少状况下实际上是能够复用的，能够建立多个代理对象为多个委托方服务，在下面将会经过一个小例子介绍一下控制器代理的复用。

下面是一个简单的代理：

首先定义一个协议类，来定义公共协议

#import <Foundation/Foundation.h>

@protocol LoginProtocol <NSObject>

@optional

- (void)userLoginWithUsername:(NSString *)username password:(NSString *)password;

@end

定义委托类，这里简单实现了一个用户登陆功能，将用户登陆后的帐号密码传递出去，有代理来处理具体登陆细节。

#import <UIKit/UIKit.h>

#import "LoginProtocol.h"

/**

 *  当前类是委托类。用户登陆后，让代理对象去实现登陆的具体细节，委托类不须要知道其中实现的具体细节。

 */

@interface LoginViewController : UIViewController

// 经过属性来设置代理对象

@property (nonatomic, weak) id<LoginProtocol> delegate;

@end

实现部分：

@implementation LoginViewController

- (void)loginButtonClick:(UIButton *)button {  

// 判断代理对象是否实现这个方法，没有实现会致使崩溃

  if (

      [self.delegate respondsToSelector:@selector(userLoginWithUsername:password:)]) {      

      // 调用代理对象的登陆方法，代理对象去实现登陆方法

      [self.delegate userLoginWithUsername:self.username.text password:self.password.text];

  }

}

代理方，实现具体的登陆流程，委托方不须要知道实现细节。

// 遵照登陆协议

@interface ViewController () <LoginProtocol> 

@end@implementation ViewController

- (void)viewDidLoad {

    [super viewDidLoad];

    LoginViewController *loginVC = [[LoginViewController alloc] init];

    loginVC.delegate = self;

    [self.navigationController pushViewController:loginVC animated:YES];

}

/**

 *  代理方实现具体登陆细节

 */

- (void)userLoginWithUsername:(NSString *)username password:(NSString *)password {    NSLog(@"username : %@, password : %@", username, password);

}

代理使用原理

代理实现流程

在iOS中代理的本质就是代理对象内存的传递和操做，咱们在委托类设置代理对象后，实际上只是用一个id类型的指针将代理对象进行了一个弱引用。委托方让代理方执行操做，其实是在委托类中向这个id类型指针指向的对象发送消息，而这个id类型指针指向的对象，就是代理对象。

经过上面这张图咱们发现，其实委托方的代理属性本质上就是代理对象自身，设置委托代理就是代理属性指针指向代理对象，至关于代理对象只是在委托方中调用本身的方法，若是方法没有实现就会致使崩溃。从崩溃的信息上来看，就能够看出来是代理方没有实现协议中的方法致使的崩溃。

而协议只是一种语法，是声明委托方中的代理属性能够调用协议中声明的方法，而协议中方法的实现仍是有代理方完成，而协议方和委托方都不知道代理方有没有完成，也不须要知道怎么完成。

代理内存管理

为何咱们设置代理属性都使用weak呢？

咱们定义的指针默认都是__strong类型的，而属性本质上也是一个成员变量和set、get方法构成的，strong类型的指针会形成强引用，一定会影响一个对象的生命周期，这也就会造成循环引用。

咱们将LoginVC对象的delegate属性，设置为弱引用属性。这样在代理对象生命周期存在时，能够正常为咱们工做，若是代理对象被释放，委托方和代理对象都不会由于内存释放致使的Crash。

可是，这样还有点问题，真的不会崩溃吗？

下面两种方式都是弱引用代理对象，可是第一种在代理对象被释放后不会致使崩溃，而第二种会致使崩溃。

@property (nonatomic, weak) id<LoginProtocol> delegate;@property (nonatomic, assign) id<LoginProtocol> delegate;

weak和assign是一种“非拥有关系”的指针，经过这两种修饰符修饰的指针变量，都不会改变被引用对象的引用计数。可是在一个对象被释放后，weak会自动将指针指向nil，而assign则不会。在iOS中，向nil发送消息时不会致使崩溃的，因此assign就会致使野指针的错误unrecognized selector sent to instance。

因此咱们若是修饰代理属性，仍是用weak修饰吧，比较安全。

控制器瘦身－代理对象

为何要使用代理对象？

随着项目愈来愈复杂，控制器也随着业务的增长而变得愈来愈臃肿。对于这种状况，不少人都想到了最近比较火的MVVM设计模式。可是这种模式学习曲线很大很差掌握，对于新项目来讲可使用，对于一个已经很复杂的大中型项目，就不太好动框架这层的东西了。

在项目中用到比较多的控件应该就有UITableView了，有的页面每每UITableView的处理逻辑不少，这就是致使控制器臃肿的一个很大的缘由。对于这种问题，咱们能够考虑给控制器瘦身，经过代理对象的方式给控制器瘦身。

什么是代理对象

这是日常控制器使用UITableView(图画的难看，主要是意思理解就行)

这是咱们优化以后的控制器构成

从上面两张图能够看出，咱们将UITableView的delegate和DataSource单独拿出来，由一个代理对象类进行控制，只将必须控制器处理的逻辑传递给控制器处理。

UITableView的数据处理、展现逻辑和简单的逻辑交互都由代理对象去处理，和控制器相关的逻辑处理传递出来，交由控制器来处理，这样控制器的工做少了不少，并且耦合度也大大下降了。这样一来，咱们只须要将须要处理的工做交由代理对象处理，并传入一些参数便可。

下面咱们用一段代码来实现一个简单的代理对象

代理对象.h文件的声明

typedef void (^selectCell) (NSIndexPath *indexPath);

/**

 *  代理对象(UITableView的协议须要声明在.h文件中，否则外界在使用的时候会报黄色警告，看起来不太舒服)

 */@interface TableViewDelegateObj : NSObject <UITableViewDelegate, UITableViewDataSource>/**

 *  建立代理对象实例，并将数据列表传进去

 *  代理对象将消息传递出去，是经过block的方式向外传递消息的

 *  @return 返回实例对象

 */

+ (instancetype)createTableViewDelegateWithDataList:(NSArray *)dataList

                                        selectBlock:(selectCell)selectBlock;

@end

代理对象.m文件中的实现

#import "TableViewDelegateObj.h"

@interface TableViewDelegateObj () 

@property (nonatomic, strong) NSArray   *dataList;

@property (nonatomic, copy)   selectCell selectBlock;

@end

@implementation TableViewDelegateObj

+ (instancetype)createTableViewDelegateWithDataList:(NSArray *)dataList

                                        selectBlock:(selectCell)selectBlock {    return [[[self class] alloc] initTableViewDelegateWithDataList:dataList

                                                       selectBlock:selectBlock];

}

- (instancetype)initTableViewDelegateWithDataList:(NSArray *)dataList selectBlock:(selectCell)selectBlock {    self = [super init];    

 if (self) {

         self.dataList = dataList;

                 self.selectBlock = selectBlock;

    }

                     return self;

}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {    

                     static NSString *identifier = @"cell";    

                     UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];    

                     if (!cell) {

        

                     cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:identifier];

    }

    cell.textLabel.text = self.dataList[indexPath.row];    return cell;

}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {    

                     return self.dataList.count;

}

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {

    [tableView deselectRowAtIndexPath:indexPath animated:NO];    

                     // 将点击事件经过block的方式传递出去

    self.selectBlock(indexPath);

}@end

外界控制器的调用很是简单，几行代码就搞定了。

self.tableDelegate = [TableViewDelegateObj createTableViewDelegateWithDataList:self.dataList 

                                                                   selectBlock:^(NSIndexPath *indexPath) {    NSLog(@"点击了%ld行cell", (long)indexPath.row);

}];

self.tableView.delegate = self.tableDelegate;self.tableView.dataSource = self.tableDelegate;

在控制器中只须要建立一个代理对象类，并将UITableView的delegate和dataSource都交给代理对象去处理，让代理对象成为UITableView的代理，解决了控制器臃肿以及和UITableView的解藕。

上面的代码只是简单的实现了点击cell的功能，若是有其余需求大多也均可以在代理对象中进行处理。使用代理对象类还有一个好处，就是若是多个UITableView逻辑同样或相似，代理对象是能够复用的。

非正式协议

简介

在iOS2.0以前尚未引入@Protocol正式协议以前，实现协议的功能主要是经过给NSObject添加Category的方式。这种经过Category的方式，相对于iOS2.0以后引入的@Protocol，就叫作非正式协议。

正如上面所说的，非正式协议通常都是以NSObject的Category的方式存在的。因为是对NSObject进行的Category，因此全部基于NSObject的子类，都接受了所定义的非正式协议。对于@Protocol来讲编译器会在编译期检查语法错误，而非正式协议则不会检查是否实现。

非正式协议中没有@Protocol的@optional和@required之分，和@Protocol同样在调用的时候，须要进行判断方法是否实现。

// 因为是使用的Category，因此须要用self来判断方法是否实现

if ([self respondsToSelector:@selector(userLoginWithUsername:password:)]) {

    [self userLoginWithUsername:self.username.text password:self.password.text];

}

非正式协议示例

在iOS早期也使用了大量非正式协议，例如CALayerDelegate就是非正式协议的一种实现，非正式协议本质上就是Category。

@interface NSObject (CALayerDelegate)

- (void)displayLayer:(CALayer *)layer;

- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx;

- (void)layoutSublayersOfLayer:(CALayer *)layer;

- (nullable id<CAAction>)actionForLayer:(CALayer *)layer forKey:(NSString *)event;@end

代理和block的选择

在iOS中的回调方法有不少，而代理和block功能更加类似，都是直接进行回调，那咱们应该用哪一个呢，或者说哪一个更好呢？

其实这两种消息传递的方式，没有哪一个更好、哪一个很差直说....咱们应该区分的是在什么状况下应该用什么，用什么更合适！下面我将会简单的介绍一下在不一样状况下代理和block的选择：

• 多个消息传递，应该使用delegate。
  在有多个消息传递时，用delegate实现更合适，看起来也更清晰。block就不太好了，这个时候block反而不便于维护，并且看起来很是臃肿，很别扭。
  例如UIKit的UITableView中有不少代理若是都换成block实现，咱们脑海里想一下这个场景，这里就不用代码写例子了.....那简直看起来不能忍受。

• 一个委托对象的代理属性只能有一个代理对象，若是想要委托对象调用多个代理对象的回调应该用block。

上面图中代理1能够被设置，代理2和代理3设置的时候被划了叉，是由于这个步骤是错误的操做。咱们上面说过，delegate只是一个保存某个代理对象的地址，若是设置多个代理至关于从新赋值，只有最后一个设置的代理才会被真正赋值。

• 单例对象最好不要用delegate。
  单例对象因为始终都只是同一个对象，若是使用delegate，就会形成咱们上面说的delegate属性被从新赋值的问题，最终只能有一个对象能够正常响应代理方法。

这种状况咱们可使用block的方式，在主线程的多个对象中使用block都是没问题的，下面咱们将用一个循环暴力测试一下block到底有没有问题。

NSOperationQueue *queue = [[NSOperationQueue alloc] init];

queue.maxConcurrentOperationCount = 10;

for (int i = 0; i < 100; i++) {

    [queue addOperationWithBlock:^{

        [[LoginViewController shareInstance] userLoginWithSuccess:^(NSString *username) {

            NSLog(@"TestTableViewController : %d", i);

        }];

    }];

}

上面用NSOperationQueue建立了一个新的队列，而且将最大并发数设置为10，而后建立一个100次的循环。咱们在多线程状况下测试单例在block的状况下可否正常使用，是能够的。

可是咱们仍是须要注意一点，在多线程状况下由于是单例对象，咱们对block中必要的地方加锁，防止资源抢夺的问题发生。

• 代理是可选的，而block在方法调用的时候只能经过将某个参数传递一个nil进去，只不过这并非什么大问题，没有代码洁癖的能够忽略。
  [self downloadTaskWithResumeData:resumeData

•                  sessionManager:manager

•                        savePath:savePath

•                   progressBlock:nil

•                    successBlock:successBlock

•                    failureBlock:failureBlock];

• 代理更加面相过程，block则更面向结果。
  从设计模式的角度来讲，代理更佳面向过程，而block更佳面向结果。例如咱们使用NSXMLParserDelegate代理进行XML解析，NSXMLParserDelegate中有不少代理方法，NSXMLParser会不间断调用这些方法将一些转换的参数传递出来，这就是NSXMLParser解析流程，这些经过代理来展示比较合适。而例如一个网络请求回来，就经过success、failure代码块来展现就比较好。

• 从性能上来讲，block的性能消耗要略大于delegate，由于block会涉及到栈区向堆区拷贝等操做，时间和空间上的消耗都大于代理。而代理只是定义了一个方法列表，在遵照协议对象的objc_protocol_list中添加一个节点，在运行时向遵照协议的对象发送消息便可。这篇文章并非讲block的，因此不对此作过多叙述。唐巧有一篇文章介绍过block，很是推荐这篇文章去深刻学习block。 文章地址 http://blog.devtang.com/2013/07/28/a-look-inside-blocks/?sukey=ecafc0a7cc4a741b195b82c60098fc3e0037824feb752d70fdefa1c1adac0ec734ba0772694accdcc33d40be18e24216