1. 구성

1>협의: 대리 쌍방이 무엇을 할 수 있는지, 무엇을 해야 하는지를 지정하는 데 사용한다.2>대리: 지정된 협의에 따라 위탁자가 실현해야 할 기능을 완성한다.3>의뢰: 지정된 협의에 따라 대리인이 어떤 기능을 완성하는지 지정한다.

2. 키워드

다만 에이전트가 프로토콜을 강제로 준수해야 하는지 여부입니다. @optional: 프록시 프로토콜을 실행할지 여부를 선택할 수 있습니다. @required: 실행해야 합니다. 그렇지 않으면 경고를 보냅니다. 기본값은 실행해야 합니다.

3. iOS에서 에이전트의 본질:

1> 에이전트의 경우 에이전트 대상 메모리의 전달과 조작은 위탁류가 에이전트 대상을 설정한 후에 실제적으로 하나의 id 형식의 바늘로 에이전트 대상을 약한 인용을 했다.위탁자는 대리인에게 조작을 하게 한다. 실제로는 위탁류에서 이 id형 바늘이 가리키는 대상에게 메시지를 보내고 이 id형 바늘이 가리키는 대상은 대리 대상이다.2> 위탁자의 입장에서 말하자면 위탁자의 대리 속성은 본질적으로 대리 대상 자체이고 위탁대리를 설정하는 것은 대리 속성 지침이 대리 대상을 가리키는 것이다. 대리 대상은 위탁자에서만 자신의 방법을 사용하고 방법이 실현되지 않으면 붕괴를 초래할 수 있다.붕괴된 정보를 보면 대리인이 협의 중의 방법을 실현하지 않아 발생한 붕괴임을 알 수 있다.3> 협의의 경우 사실은 하나의 문법일 뿐이다. 위탁자 중의 대리 속성은 협의에서 성명하는 방법을 호출할 수 있지만 협의 중의 방법의 실현은 대리인이 완성해야 한다. 협의자와 위탁자는 대리인이 완성했는지 안 했는지 모르고 어떻게 완성했는지 알 필요가 없다.

4. 프록시 메모리 관리(weak 포인터)

@property (nonatomic,** weak**, nullable) id objDelegate; 1> 원인 정의 포인터는 기본값strong 유형은 속성도 본질적으로 하나의 구성원 변수와 set, get 방법으로 구성된 것이다. strong 유형의 바늘은 강한 인용을 초래하고 반드시 한 대상의 생명 주기에 영향을 주며 이것도 순환 인용을 형성한다.(쌍방이 상대방을 강제로 인용하여 쌍방의 메모리를 방출할 수 없게 만든다) 그리고 순환 인용으로 인한 메모리 유출도 인스트루먼트에서 발견할 수 없기 때문에 dealloc 방법으로 폐기 여부를 인쇄할 수 있기 때문에 특히 조심해야 한다.2> 순환 인용 상황 위탁자는 대리인을 objDelegate 구성원 변수로 하고strong을 사용하면 위탁자가 대리인을 강제로 인용하게 된다.당대 이측은 위탁자의 협의를 사용할 때 위탁자를 구성원 변수로 강제로 인용한다.결과적으로 쌍방이 각자 상대방을 강제로 인용하여 메모리를 방출할 수 없게 되었다.2.1> 코드 프레젠테이션 에이전트가 위탁자를 구성원 변수로 실례화할 때 강제로 인용한다:delegateVC @property(nonatomic,strong,nullable)UItableView*myTableView;즉delegateVC->myTableView 에이전트가 위탁자의 에이전트가 될 때 위탁자는 대리인을 강제로 인용한다. @property(nonatomic,strong,nullable)iddelegate;myTableView.delegate = self 3> delegate @property(nonatomic, weak) id delegate를 assign으로 수식할 수 없는 이유; @property (nonatomic, assign) id delegate; 원인:weak과 assign은'비보유 관계'의 지침으로 이 두 가지 수식자를 통해 수식된 지침 변수는 인용 대상의 인용 계수를 바꾸지 않는다.그러나 대상이 풀리면 weak은 자동으로 nil을 가리키고 assign은 가리키지 않습니다.iOS에서는 nil에 메시지를 보낼 때 충돌을 일으키지 않기 때문에 assign은 야생 포인터의 오류를 초래할 수 있습니다 unrecognized selector sent to instance.

5. 비공식 협의

iOS2.0 이전에 @Protocol 정식 프로토콜이 도입되기 전에 프로토콜을 실현하는 기능은 주로 NSObject에 Category를 추가하는 방식이었다.

 //  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;
@end

6. 프록시와 Block의 선택

1>여러 개의 메시지 전달은delegate를 사용해야 합니다.여러 개의 메시지가 전달될 때delegate로 실현하는 것이 더욱 적합하고 또렷해 보인다.Block은 좋지 않아요. 이럴 때 Block은 오히려 유지하기가 불편하고 뚱뚱해 보여요. 어색해요.예를 들어 UIKit의 UItableView에는 많은 에이전트가 Block으로 바뀌면 실현됩니다.2>한 의뢰 대상의 대리 속성은 한 개의 대리 대상만 있을 수 있으며, 의뢰 대상이 여러 개의 대리 대상의 리셋을 호출하려면 Block을 사용해야 한다.delegate는 특정한 프록시 대상을 저장하는 주소일 뿐입니다. 여러 프록시를 설정하면 다시 값을 부여받는 것과 같습니다. 마지막으로 설정한 프록시만 실제 값을 부여받을 수 있습니다.3> 단일 대상은delegate를 사용하지 않는 것이 좋다.중복 부여된 값을 피해야 마지막 에이전트가 적용됩니다.4>성능적으로 볼 때 Block의 성능 소모는delegate보다 약간 크다. 왜냐하면 Block은 창고 구역에서 창고 구역으로 복사하는 등 작업과 관련되기 때문에 시간과 공간의 소모는 모두 에이전트보다 크다.프록시는 프로토콜 대상을 준수하는objcprotocol_list에 노드를 추가하여 실행할 때 프로토콜을 준수하는 대상에게 메시지를 보내면 됩니다.