? ?在OC開發(fā)中镣奋，導(dǎo)航控制器是一個(gè)非常常見的控件枪汪，而且在不少使用時(shí)候胁勺，我們需要自定義導(dǎo)航條NavigationBar世澜。但是這個(gè)做法可能帶來一些小麻煩，下面是我遇到的問題以及解決方案的思維過程署穗。
? ? 在蘋果內(nèi)部寥裂，返回功能的實(shí)現(xiàn)自帶了一個(gè)邊緣的滑動返回功能。但是一旦使用我們自定義的NavigationBar案疲，重寫了返回按鈕封恰，子控制器這個(gè)功能便會消失。如果我們既要用到自定義褐啡，又要保留滑動返回功能诺舔，那我們首先要分析消失的原因，再來尋找解決方案备畦。
既然替換NavigationBar會導(dǎo)致滑動返回功能的消失低飒，那我們基本可以確定，在NavigationBar當(dāng)中會有某些屬性某些方法實(shí)現(xiàn)了這個(gè)功能萍恕。那么需要進(jìn)一步考慮系統(tǒng)做了哪些事逸嘀，哪些會導(dǎo)致滑動功能失效。
由于滑動功能肯定需要手勢允粤，我們可以先從手勢進(jìn)行分析崭倘。又因?yàn)榛瑒臃祷厥謩菔莍OS7.0以后推出的，而且添加手勢是添加到UINavigationController的view上类垫，那我們直接點(diǎn)進(jìn)去搜索關(guān)鍵字“gesture”
出現(xiàn)有且只有一個(gè)符合我們條件的屬性司光。那我們可以大膽推測滑動返回功能跟interactivePopGestureRecognizer有關(guān)系，所以直接打印它的值來觀察悉患。
剛好它的值中有個(gè)與屏幕邊緣的手勢相關(guān)残家，進(jìn)一步驗(yàn)證我們的猜想。那么就可以用最簡單粗暴的方法來確認(rèn)售躁，直接“干掉”該方法坞淮，如果功能失效茴晋，那肯定與它相關(guān)，那我們可以考慮嘗試代理回窘，通過interactivePopGestureRecognizer讓滑動返回功能失效诺擅。首先讓控制器成為interactivePopGestureRecognizer的代理，在代理方法中把識別手勢方法的返回值改為NO啡直，不出所料烁涌，滑動功能無法實(shí)現(xiàn)。
為了確認(rèn)該屬性本來就存在著代理酒觅，順便把代理屬性的值也打印出來撮执。
這也可以證明了猜想的正確性。那么下一步就是考慮如何在使用自定義導(dǎo)航條（NavigationBar）的基礎(chǔ)上舷丹，使滑動功能繼續(xù)實(shí)現(xiàn)抒钱。
首先嘗試直接把代理屬性清空，不讓它繼續(xù)控制屏幕滑動掂榔，確實(shí)實(shí)現(xiàn)了自定義NavigationBar后繼續(xù)滑動的返回功能继效。但明顯也會帶來bug症杏，造成導(dǎo)航控制器view也可以滑動装获，而且滑動后造成了界面的假死，所以不能把代理設(shè)置為nil厉颤。那我們繼續(xù)使用控制器作為代理穴豫，考慮通過控制手勢在根控制器上不能滑動來修復(fù)該bug。
在手勢控制時(shí)加入判斷逼友，如果該控制器為根控制器精肃，那么手勢將不會觸發(fā)，如果為子控制器帜乞，能夠正常使用司抱。最終達(dá)到項(xiàng)目要求，在使用自定義NavigationBar自定義返回按鈕的前提下實(shí)現(xiàn)原有的滑動返回功能黎烈。
