登錄模塊可能是很多開發者接觸APP開發的第一個完整模塊，相對其它業務模塊，登錄模塊各頁面功能定義明確，調用關系比較清晰，一般以登錄頁面為主頁面，push到各個頁面即可：
簡化的登錄關系圖
這是大部分登錄Demo描述的場景，真的如此嗎？想一下常見的APP，比如京東，什么時候會出現登錄頁面？答案是：
任何頁面！ 只要你沒有登錄，“簽到”會跳轉到登錄，“購物車”會跳轉到登錄，“消息中心”會跳轉到登錄，我們這里統一稱為“發起頁”：
優化前的實際登錄關系圖
從發起頁進入登錄模塊時，考慮了以下情形：
a) 入口不一定是登錄頁，也有可能是重置密碼（如：個人中心），也可能直接到注冊頁（為簡化，圖中略去）。
b) 從任何子頁面都有可能直接回到發起頁，圖中用虛線標示，比如進入注冊頁后，用戶不想注冊了，這時應該退出整個注冊流程，直接回到發起頁。
不難發現，為了考慮多種情況，登錄模塊中的每個頁面都需要知道其它頁面的情況，與其它頁面產生了強關聯，“登錄”需要知道“重置密碼”、“注冊”、“第三方注冊”，連作為調用者“發起頁”也不能幸免，如上圖情形，就需要關聯“登錄”和“重置密碼”；如果這時候需要添加“用戶信息”，就需要修改“發起頁”、“驗證碼”、“第三方登錄”等等頁面，導致整個模塊修改困難。
這種系統的各個對象之間的相互關系成網狀結構的情形，就是中介者模式大顯身手的時候了：
這種模式提供了一個中介類，該類通常處理不同類之間的通信，并支持松耦合，使代碼易于維護。中介者模式屬于行為型模式。
我們引入“VC管理器”，各頁面只和該管理器發生聯系，需要跳轉到哪個頁面，只需要告訴管理器“目標頁面名稱”即可，無需知道具體的頁面類：
引入中介者后的各頁面關系如圖：
優化后的登錄關系圖
“VC管理器”中，將顯示的VC用棧結構來保存，方便我們處理返回或直接關閉邏輯。
通過引入“VC管理器”，我們獲得了以下好處：
- 減少各頁面之間耦合，可以靈活的顯示模塊中各個頁面。
- 統一管理了各個頁的跳轉關系，減少了各頁面處理頁面跳轉的冗余代碼。
- 方便添加新頁面。
