現實中的案例說明：
舉一個app外賣的案例，來簡單理解一下代理協(xié)議的概念。
其實在生活中（工作和學習）我們經常會遇到叫外賣的場景。作為消費者角色其實過程很簡單
- 打開app
- 搜索餐飲（或周邊推薦）
- 下單付款，等待……
但這里很多人并不曾想，平臺（app外賣）和騎士之間的關系
注意：我這里提到了【騎士】
平臺負責管理app和收錢，結算（商戶服務等）一系列運營手段……
騎士負責送餐（前提是要在app平臺做好相關登記和簽署平臺協(xié)議）
進入正題：
先要明確兩個人之間的關系是什么？？？？這點很重要~
委托人：平臺（實際想要達到某個目的的人）
代理人：騎士（實際去干活的人）
代理協(xié)議就可以理解為平臺和騎士之間的相互關系？
平臺不管做飯做菜的事情。但可以管理別的事物
騎士也不管做飯做菜的事情。但可以幫平臺完成一個訂單的送達。
代理協(xié)議也正是這個道理
貌似兩者都很難完成的一件事情，但是其中有一個人是可以通過靈活的變通，完成一項任務。
那么我們來說說ios代理協(xié)議
首先我們想讓一個類（控制器）完成一件事，這件事情控制器不能直接去完成怎么辦？我們來想一下app平臺怎么做的
解決方案：
1、擬訂一個協(xié)議（類和控制器擬訂協(xié)議和方法）
這個協(xié)議是對外公開的，是給所有想當騎士的人都可以看見的，可不是什么內部文件，只能內部看哦！~那么協(xié)議應該寫在.h還是.m文件呢？
2、向外部召集騎士（設置代理屬性） ，這一步是不是也是對外公開的呢？？
3、有人應招了，那就簡單聊一下。如果沒什么問題，平臺會詳細的告訴應招人需要如何去做？注意一個細節(jié)：一般平臺會要求，如果作為騎士會享有平臺的一些資源和穿戴平臺的制定的服裝（方法的實現，一般在方法實現中將委托人作為參數帶上，當然根據情況，也可以不帶）
這里還有一個細節(jié)~ 先要判斷一下應招人有沒有正在做別人家的騎士工作？？你想到什么？？
怎么做一個騎士呢？
1、拿到平臺的相關協(xié)議看一下，簽署協(xié)議（遵守協(xié)議）
2、簽署協(xié)議之后就拿到平臺授權的騎士特權（設置代理）
3、出門下樓，就可以執(zhí)行第一單了（實現方法）
總結一下：
首先要明確誰是委托人，誰是代理人
A（委托人）
B（代理人）
在A.h的文件中要做三件事
1.設置協(xié)議
2.擬訂方法
3.設置代理屬性
在A.m的文件中需要代理的地方進行調用方法。（注意要先判斷代理是否有執(zhí)行過這個方法）
在B.h的文件中我們什么都不做
在B.m的文件中要做三件事情
1.遵守協(xié)議
2.設為代理
3.實現相應方法。
over
