1. 何为代理模式
代理模式的几种形式：
（1）远程代理（remote proxy）：为位于不同地址空间或网络上的对象提供本地代表。
（2）虚拟代理（virtual proxy）：根据需要常见重型对象。
（3）保护代理（protection proxy）：根据各种访问权限控制对原对象的访问。
（4）智能引用代理（smart-reference proxy）：通过对真正对象的引用进行计数来管理内存。也用于锁定真正对象，让其他对象不能对其进行修改。
代理模式：为其他对象提供一种代理以控制对这个对象的访问。
通常，代理是一种替代或者占位，它控制对另一些对象的访问，而这些对象可能是远程对象，创建的开销较大的对象，或者是对安全性有要求的对象。本片博文只重点介绍虚拟代理。
代理模式的思想是使用一个基本上跟实体对象行为相同的代理。客户端可以“透明地”使用代理，不必知悉所面对的只是一个代理而不是实体对象。当客户端请求某些创建开销较大的功能时，代理将把请求转发给实体对象，准备好请求的功能并返回给客户端，客户端不知道幕后发生了什么，代理和实体对象同样拥有客户端要求的行为。图1-1解释了这一思想。
当客户端向Proxy对象发送request消息时，Proxy对象会把这个消息转发给Proxy对象之中的RealSubject对象。RealSubject会实施实际的操作间接满足客户端的需求。
在运行时，我们可以想象这样一个场景：客户端以抽象类型引用一个对象，这个引用实际上是个Proxy对象，Proxy对象本身有一个对RealSubject实例的引用，以后如果你接到请求，此实例将执行高强度的工作。这个运行时的场景如图1-2所示：
2. iOS中的代理模式
iOS中的代理主要由三部分组成：
- 协议：用来指定代理双方可以做什么，必须做什么
- 代理：根据指定的协议，完成委托方需要实现的功能
- 委托：根据指定的协议，指定代理去完成什么功能
图2-1描述了三者之间的关系：
从上图中我们可以看到三方之间的关系，在实际应用中通过协议来规定代理双方的行为，协议中的内容一般都是方法列表，当然也可以定义属性。
2.1 协议（Protocol）
协议是公共的定义，如果只是某个类使用，我们常做的就是写在某个类中；如果是多个类都是用同一个协议，建议创建一个Protocol文件，在这个文件中定义协议。遵循的协议可以被继承，例如我们常用的UTableView，由于继承自UIScrollView，所以也将UIScrollViewDelegate也继承了过来，我们可以通过代理方法获取UITableView偏移量等状态参数。
协议只能定义公用的一套接口，类似于一个约束代理双方的作用。但不能提供具体的实现方法，实现方法需要代理对象去实现。协议可以继承其他协议，并且可以继承多个协议，在iOS中对象是不支持多继承的，而协议可以多继承。
@protocol UITableViewDelegate<NSObject, UIScrollViewDelegate>
协议有两个修饰符@optional和@required，创建一个协议如果没有声明，默认是@required状态的。这两个修饰符只是约定代理是否强制需要遵守协议，如果@required状态的方法代理没有遵守，会报一个黄色的警告，只是起一个约束的作用，没有其他功能。
无论是@optional还是@required，在委托方调用代理方法时都需要做一个判断，判断代理是否实现当前方法，否则会导致崩溃。
在iOS中一个代理可以有多个委托方，而一个委托方也可以有多个代理。代理对象在很多情况下其实是可以复用的，可以创建多个代理对象为多个委托方服务，在下面将会通过一个小例子介绍一下控制器代理的复用。
2.2 代码实现
（1）首先定义一个协议类，来定义公共协议
@protocol LoginProtocol
@optional
- (void)userLoginWithUsername:(NSString *)username password:(NSString *)password;
@end
（2）定义委托类，这里简单实现了一个用户登录功能，将用户登录后的账号密码传递出去，有代理来处理具体登录细节
#import #import "LoginProtocol.h"
/**
* 当前类是委托类。用户登录后，让代理对象去实现登录的具体细节，委托类不需要知道其中实现的具体细节。
*/
@interface LoginViewController : UIViewController
// 通过属性来设置代理对象
@property (nonatomic, weak) id 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];
}
}
（3）代理方，实现具体的登录流程，委托方不需要知道实现细节
// 遵守登录协议
@interface ViewController ()
@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);
}
2.3 代理实现的原理
（1）代理的实现流程
在iOS中代理的本质就是代理对象内存的传递和操作，我们在委托类设置代理对象之后，实际上只是用一个id类型 的指针将代理对象进行了一个弱引用。委托方让代理方执行操作，实际上是在委托类中向这个id类型指针指向的对象发送消息，而这个id类型指针指向的对象，就是代理对象。如图2-2所示：
通过上面这张图我们发现，其实委托方的代理属性本质上就是代理对象自身，设置委托代理就是代理属性指针指向代理对象，相当于代理对象只是在委托方中调用自己的方法，如果方法没有实现就会导致崩溃。从崩溃的信息上来看，就可以看出来是代理方没有实现协议中的方法导致的崩溃。
而协议只是一种语法，是声明委托方中的代理属性可以调用协议中声明的方法，而协议中方法的实现还是有代理方完成，而协议方和委托方都不知道代理方有没有完成，也不需要知道怎么完成。
（2）代理的内存管理
为什么我们设置代理属性都使用weak呢？
我们定义的指针默认都是__strong类型的，而属性本质上也是一个成员变量和set、get方法构成的，strong类型的指针会造成强引用，必定会影响一个对象的生命周期，这也就会形成循环引用。如图2-3所示：
上图中，由于代理对象使用强引用指针，引用创建的委托方LoginVC对象，并且成为LoginVC的代理。这就会导致LoginVC的delegate属性强引用代理对象，导致循环引用的问题，最终两个对象都无法正常释放。
我们将LoginVC对象的delegate属性，设置为弱引用属性。这样在代理对象生命周期存在时，可以正常为我们工作，如果代理对象被释放，委托方和代理对象都不会因为内存释放导致的Crash。如图2-4所示：
下面两种方式都是弱引用代理对象，但是第一种在代理对象被释放后不会导致崩溃，而第二种会导致崩溃。
@property (nonatomic, weak) delegate;
@property (nonatomic, assign) delegate;
weak和assign是一种“非拥有关系”的指针，通过这两种修饰符修饰的指针变量，都不会改变被引用对象的引用计数。但是在一个对象被释放后，weak会自动将指针指向nil，而assign则不会。在iOS中，向nil发送消息时不会导致崩溃的，所以assign就会导致野指针的错误unrecognized selector sent to instance。
3. 控制器瘦身－代理对象
在项目中用到比较多的控件应该就有UITableView了，有的页面往往UITableView的处理逻辑很多，这就是导致控制器臃肿的一个很大的原因。对于这种问题，我们可以考虑给控制器瘦身，通过代理对象的方式给控制器瘦身。
这是平常控制器使用UITableView，如图3-1所示：
这是我们优化之后的控制器构成，如图3-2所示：
从上面两张图可以看出，我们将UITableView的delegate和DataSource单独拿出来，由一个代理对象类进行控制，只将必须控制器处理的逻辑传递给控制器处理。
UITableView的数据处理、展示逻辑和简单的逻辑交互都由代理对象去处理，和控制器相关的逻辑处理传递出来，交由控制器来处理，这样控制器的工作少了很多，而且耦合度也大大降低了。这样一来，我们只需要将需要处理的工作交由代理对象处理，并传入一些参数即可。
下面我们用一段代码来实现一个简单的代理对象：
（1）代理对象
.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
（2）外界控制器的调用
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逻辑一样或类似，代理对象是可以复用的。
4. 非正式协议
在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)actionForLayer:(CALayer *)layer forKey:(NSString *)event;
@end
5. delegate和block的选择
这两种消息传递的方式，没有哪个更好、哪个不好....我们应该区分的是在什么情况下应该用什么，用什么更合适！
多个消息传递，应该使用delegate。在有多个消息传递时，用delegate实现更合适，看起来也更清晰。block就不太好了，这个时候block反而不便于维护，而且看起来非常臃肿，很别扭。例如UIKit的UITableView中有很多代理如果都换成block实现，我们脑海里想一下这个场景，这里就不用代码写例子了.....那简直看起来不能忍受。
一个委托对象的代理属性只能有一个代理对象，如果想要委托对象调用多个代理对象的回调应该用block。
代理更加面相过程，block则更面向结果。从设计模式的角度来说，代理更佳面向过程，而block更佳面向结果。例如我们使用NSXMLParserDelegate代理进行XML解析，NSXMLParserDelegate中有很多代理方法，NSXMLParser会不间断调用这些方法将一些转换的参数传递出来，这就是NSXMLParser解析流程，这些通过代理来展现比较合适。而例如一个网络请求回来，就通过success、failure代码块来展示就比较好。
从性能上来说，block的性能消耗要略大于delegate，因为block会涉及到栈区向堆区拷贝等操作，时间和空间上的消耗都大于代理。而代理只是定义了一个方法列表，在遵守协议对象的objc_protocol_list中添加一个节点，在运行时向遵守协议的对象发送消息即可。
上面图中代理1可以被设置，代理2和代理3设置的时候被划了叉，是因为这个步骤是错误的操作。我们上面说过，delegate只是一个保存某个代理对象的地址，如果设置多个代理相当于重新赋值，只有最后一个设置的代理才会被真正赋值。
⚠️单例对象最好不要用delegate。单例对象由于始终都只是同一个对象，如果使用delegate，就会造成我们上面说的delegate属性被重新赋值的问题，最终只能有一个对象可以正常响应代理方法。
