在iOS7之后，苹果推出了手势滑动返回功能，也就是从屏幕左侧向右滑动可返回上一个界面。大大提高了APP在大屏手机和iPad上的操作体验，场景切换更加流畅。
常见的问题有：
1.右滑手势失效
2.右滑手势与其他手势冲突
3.右滑手势导致应用 Crash
4.右滑手势的开启与关闭
了解一下 navigationItem 的几个属性
hidesBackButton                   - 是否隐藏原生返回按钮,当前控制器设置，当前控制器有效
backBarButtonItem                 - 当前控制器设置，下一级控制器生效
leftBarButtonItem                 - 当前控制器设置，当前控制器生效
leftBarButtonItems                - 当前控制器设置，当前控制器生效
leftItemsSupplementBackButton     - 在leftBarButtonItem设置之后，再设置该属性可以控制backBarButtonItem的被覆盖状态
系统原生的右滑返回是OK的，但如果设置了 hidesBackButton 、 backBarButtonItem 、 leftBarButtonItem 、 leftBarButtonItems 几个属性，原生的右滑返回手势就会失效。
关于解决方式网上给了很多，但涉及到具体项目觉得使用拦截手势代理回调的方式最为合理。
其一，可以很便捷地解决右滑失效、手势冲突、右滑 Crash 等问题
其二，返回按钮你可以随意自定义
其三，在混合式开发中，可以在拦截的代理回调中给 web 跳转也增加逐级返回体验
关键代码如下 ,详见 Demo
self.navigationController.interactivePopGestureRecognizer.delegate = (id)self;
self.navigationController.interactivePopGestureRecognizer.enabled  = TRUE;
-(BOOL)gestureRecognizerShouldBegin:(UIGestureRecognizer *)gestureRecognizer{
DLog(@" gestureRecognizerShouldBegin : %@ \n %@",gestureRecognizer,[gestureRecognizer class]);
BOOL rlt = FALSE;
// 手势
if(gestureRecognizer == self.navigationController.interactivePopGestureRecognizer){
// 控制器堆栈
if(self.navigationController.viewControllers.count >= 2){
rlt = TRUE;
}
}
return rlt;
}
其中可以将该部分代码放在积累控制器设置或自定义导航栏控制器中设置；然后在不需要的控制器中使用 self.navigationController.interactivePopGestureRecognizer.enabled  = FALSE; 单独关闭即可

全屏返回手势
自 iOS7 之后，Apple 增加了屏幕边缘右划返回交互的支持，再配合上 UINavigationController 的交互式动画，pop 到上一级页面的操作变的非常顺畅和丝滑，从此，我很少再使用点击左上角导航栏上的返回按钮的方式返回了，因为这对单手操作十分不友好；如果一个 App 居然胆敢不支持滑动返回，那离被卸载就不远了。
说到全屏返回手势，首先我感觉这件事本身可能就有问题，毕竟有点反苹果官方的交互，让用户从任意的地方都能够滑动返回这个交互在国内的 App 中非常普遍，比如我手机中的手Q、微博、网易新闻、大众点评等，当然还有百度知道- -。这里得对微信的产品经理们得点个赞，从整个 App 来看，不论是交互还是 UI 结构和样式都非常的 iOS，没有什么特别奇葩的页面和交互，以至于使用 UIKit 原生的框架可以非常简单的搭建起来，这也符合我个人对 App 的一个愿景：一个优秀的 App 不论从用户角度看还是从代码角度看都应该是简单且优雅的，呼吁各家产品经理可以多借鉴下像微信这样很本色的 App 设计。(以后可以分享下如何使用 Storyboard 在一小时内快速搭建起微信 UI)
FDFullscreenPopGesture
工作毕竟是工作，于是乎所以就被迫实现了套 pan 手势处理加截图和视差，虽然在运动曲线上、bar 截图处理上下了不少功夫，但距离系统的丝滑效果还是差距挺远。随时间推移，终于能够最低支持 iOS7 后，我们把这个问题再次拿出来讨论和研究，直到在微博上看到了 J_雨同学的这篇文章 后才找到了这个迄今为止最简单的解决方案。于是乎在他的授权下，我们在 forkingdog 上把这个返回手势开源，github地址，并果断应用到了百度知道 App 内，这是 Demo 效果：
利用了系统自己的边缘返回手势处理函数后，一切动画和曲线都和原生效果一毛一样了。
于是乎发布了 FDFullscreenPopGesture 1.0 版本，而且提供了一个 AOP 形式的 API，把它添加到工程里面，什么代码都不用写，所有 UINavigationController 就自带这个全屏返回效果了。
丝滑的处理导航栏的显示和隐藏
接下来我们发现利用系统的 UINavigationBar 时，返回手势中若碰到前一个页面有 bar，后一个页面没 bar，或者反过来时，动画就非常难看，举两个反例：
手Q iOS：
它的个人中心页面上面的 bar 是隐藏状态，然后做了个和其他页面很像的假 bar，但返回手势一开始就露馅了，为了弥补，还做了下后面真 bar 的 alpha 值动画，两个返回按钮还是重叠在了一起。
新浪微博 iOS：
和手Q一样的实现方式，只不过没做 alpha 动画，所以就非常明显了。
为啥会这样呢？这可能就是 UINavigationController 在导航栏控制 API 上设计的缺陷了。 一个 UINavigationController 管理了串行的 N 个 UIViewController 栈式的 push 和 pop，而 UINavigationBar 由 UINavigationController 管理，这就导致了 UIViewController 无法控制自己上面的 bar 单独的隐藏或显示。 这非常像 UIApplication 全局的 status bar，牵一发还得动全身，不过 Apple 在 iOS7 之后为 vc 控制自己的 status bar 提供了下面几个方法：
1
2
3- (UIStatusBarStyle)preferredStatusBarStyle NS_AVAILABLE_IOS(7_0);
- (BOOL)prefersStatusBarHidden NS_AVAILABLE_IOS(7_0);
- (UIStatusBarAnimation)preferredStatusBarUpdateAnimation NS_AVAILABLE_IOS(7_0);
终于让这个全局变量变成了局部变量，虽然写起来费劲了些。
但是对 UINavigationBar 的控制，依然是全局的，可能 Apple 觉得 App 不应该有这种奇怪的页面结构？
解决这个问题的方法也不难，在滑动返回的后要出现的那个 view controller 中写下面的代码：
1
2
3
4- (void)viewWillAppear:(BOOL)animated {
[super viewWillAppear:animated];
[self.navigationController setNavigationBarHidden:YES animated:animated];
}
系统就会把有 bar 和 无 bar 的 transition 动画衔接起来。但是如上面所说，这是个全局变量，还得在所有由这个没有 bar 的特殊页面能 push 和 pop 的页面都进行反向的处理，代码非常的乱乎。于是乎，我们试着解决了这个问题，先看效果：
我特意挑了个从真 bar 到假 bar，再从假 bar 到 真 bar 的页面，还算蛮丝滑的，transition 动画全是系统自己搞定的。
就事把 FDFullscreenPopGesture 更新到了 1.1 版本，贯彻我们一向的精简 API，你只需要在 bar 要隐藏的 view controller 中写一句话：
1
2
3
4- (void)viewDidLoad
[super viewDidLoad];
self.navigationController.fd_prefersNavigationBarHidden = YES;
}
或者喜欢重载的写法也行：
1
2
3- (BOOL)fd_prefersNavigationBarHidden {
return YES;
}
刻意的模仿了下系统的命名风格，就这一句话，剩下的就都不用操心了。
关于私有API
大家会质疑说，这用到了 UIKit 的私有属性和私有 API，要是系统升级变了咋办？要是审核被拒了咋办？
首先，iOS 系统的 SDK 为了向下兼容，一般只会增加方法或者修改方法实现，不太可能直接删除一个共有方法，而私有方法的行为确实可能有变化，但系统 release 频率毕竟很低，每当新版本发布时 check 下原来的功能是否能 work 就好了，大可不必担心这么远，SDK 是死的人是活的。
另一个就是审核问题，FDFullscreenPopGesture 的实现中有主要有两处触碰到了私有 API：
1
2
3
4// 1. 私有变量标志transition动画是否正在进行
[self.navigationController valueForKey:@"_isTransitioning"];
// 2. 一个内部的selector
NSSelectorFromString(@"handleNavigationTransition:");
不论是 kvc 还是 selector 反射，都是利用 objc runtime 完成的，而到了这一层，真的就没啥公有私有可言了。设想你就是开发 Apple 私有 API 检查工具的工程师，给你一个 ipa 的包，你会如何检查出其中有没有私有 API 呢？
首先，这个检查一定是个静态检查吧，不可能是运行时检查，因为代码逻辑那么复杂，把程序跑起来看所有 objc_msgSend 中包不包括私有调用这件事太不现实了。
对 ipa 文件做静态检查的话肯定是去分析 Mach-O 可执行文件，因为这时很多源代码级别的信息已经丢失，经分析可以采取下面几种手段：
是否 link 了私有 framework 或者公开 framework 中的私有符号，这可以防止开发者把私有 header 都 dump 出来供程序直接调用。
同上，使用@selector(_private_sel)加上-performSelector:的方式直接调用私有 API。
扫描所有符号，查看是否有继承自私有类，重载私有方法，方法名是否有重合。
扫描所有string，看字符串常量段是否出现和私有 API 对应的。
我觉得前三条被 catch 住的可能性最高，也最容易被检查出来。再来看我们用到用字符串的方法 kvc 和 反射 selector，应该属于最后一条，这时候就很难抉择了，拿 handleNavigationTransition: 来说，看上去人畜无害啊，我自己类里面的方法也完全可能命名出这个来，所以单单凭借字符串命中私有 API 判定，苹果很容易误伤一大票开发者。
综上，我觉得使用字符串的方式使用私有 API 是相对安全的，我们的 App 马上要提交审核，如果过了几天你还能读到这段文字，说明我的猜想是木有错的，大家可以放心使用。
0 代码的 Demo
还有一个有意思的事，我们在 github 上的 demo工程 木有写一行代码，就实现了下面的效果：
工程长这个样子，view controller 类也没写，为了体现 FDFullscreenPopGesture 的 AOP 性质：
页面由 Storyboard 构建：
而控制页面隐藏 bar 的属性也能用 Runtime Attributes 模拟调用：
这样就完成了一个非常干净的 Demo
加入到你的工程中
首先要求最低支持 iOS7，我想在 WWDC 2015 结束，iOS9 发布后，主流的 App 就都会 iOS7 起跳了。
依然是熟悉的 cocoapods 安装：
1pod 'FDFullscreenPopGesture', '~> 1.1'
要是没有搜到就 pod setup 下。
广告时间
我这边正在招聘 iOS，坐标北京，希望找到一个代码规范的、爱用 IB 的、懒得写重复代码、不爱加班的同学，相信这里有很大空间供你学习和提升，还可以参与到 forkingdog 开源小组中做点屌屌的东西，欢迎私聊或把简历丢到 sunyuan01@baidu.com

感谢前人的无私奉献.  简书原文 ,  优化有bar,无bar的切换

前言

苹果在IOS7以后给导航控制器增加了一个Pop的手势，只要手指在屏幕边缘滑动，当前的控制器的视图就会跟随你的手指移动，当用户松手后，系统会判断手指拖动出来的大小来决定是否要执行控制器的Pop操作。



这个操作的想法非常好，但是系统给我们规定的范围必须是屏幕左侧边缘才可以触发，这样实际使用过程中对于有些产品会产生不便，于是有些app就采取整个屏幕都响应这个手势并且pop动画还是用系统原生的，这样操作起来确实方便好多。



 

推荐使用:Runtime+KVC

为了方便大家阅读下面的代码，我们需要先了解系统的这个手势。

前面我们了解到，这个手势属于UINavigationController，我们就跳到它的头文件里看看能不能找到线索。这个思路是正确的，确实有一个手势叫做interactivePopGestureRecognizer。属性为readonly，就是说我们不能给他换成自定义的手势，但是可以设置enable=NO。ok，既然找到了它，就打印一下看看它到底是一个什么手势。



通过log，我们看到他属于UIScreenEdgePanGestureRecognizer这个类(之前我是没有用到过)，它继承自UIPanGestureRecognizer，出现在IOS7以后，是专门处理在屏幕边缘触发的手势类型，并且只有一个属性叫edges，用来设置它的触发边缘（上、下、左、右、全部）。

我们继续看它的log。控制台除了打印了它的类，还打印了它的触发target:_UINavigationInteractiveTransition（这是一个私有类，看来是专门用来做导航控制器交互动画的），和action:handleNavigationTransition（这是它的一个私有方法），我们要做的就是新建一个UIPanGestureRecognizer，让它的触发和系统的这个手势相同，这就需要利用runtime获取系统手势的target和action。

那么如何获取这个target呢？一开始我用kvc想直接获取这个手势的target，程序崩溃了，原来它根本没有这样一个属性。所以我能想到的是，先利用runtime遍历它的所有成员变量，看看系统是怎么存储这个属性的，

 



 

通过log我们可以看到，UIGestureRecognizer有一个叫_targets的属性，它的类型为NSMutableArray。





它是用数组来存储每一个target－action，所以可以动态的增加手势触发对象。那么又是什么存储每一个target-action呢？为了了解这个我们拿到这个属性的名字"_targets"通过kvc获取它，接着打印出来。



 



可以看到，由于系统重写了它的description方法，所以我们没办法通过打印获取这个对象是什么类型。既然不能打印，那么我们就用断点调试，来看它的真实类型，



我们看到，原来每一个target-action是用UIGestureRecognizerTarget这样一个类来存储的，它也是一个私有类。

苹果把许多的类做私有化也是有原因所在，其实在平时我们拿到这个类也是没有用的，他们的目的之一是避免对开发者公开无用的类，影响了封装性。所以在类的设计上，还是要向苹果学习。

下面直接看代码。

我们在控制器的ViewDidLoad加上这段代码，并且它只需要执行一次。

 



 

优化

这个demo我会提供给大家，下面简单说下程序的优化思路。


	
优化点一：对于方案一，其实不应该把导航控制器的代理方法以及手势处理的方法交给视图控制器，因为这段代码不是属于某一个视图控制器，而是全局的导航控制器，所以我们应该参考苹果的设计思想：新建一个专门管理交互过程的对象，这个类我们叫做NavigationInteractiveTransition。
	
	

	
优化点二：再来看之前的ViewDidLoad中只执行一次的代码，其实写在这里也不够妥当，同样的，这段代码也不属于某一个Controller，优化方案是新建一个导航控制器，在这个导航控制器的viewDidLoad中写上这些代码，这样也并不需要dispatch once。
	
	

	
优化点三：由于我们自定义的手势是加在一个私有view上，这个view是一个全局的，所以当这个控制器为根控制器时，我们的手势还是在起作用，这就相当于对根控制器做了pop操作，这会出现一个错误nested pop animation can result in corrupted navigation bar。导致这个错误的原因还有一个，如果我们pop的动画正在执行，再去触发一次手势，会导致导航控制器和导航条的动画混乱。为了避免问题出现我们需要成为手势的代理，判断当前控制器是否为根控制器并且pop或者push动画是否在执行（这个变量是私有的，需要用kvc来获取）。
	 

	


	
经过最后的优化，视图控制器可以什么都不写，想使用这个效果，只要使用我们自定义的导航控制器就可以了，这样的好处是手势动画与控制器完全解耦，并且不用给每一个控制器都addGesture。
	
给大家推荐一个仓库https://github.com/nst/iOS-Runtime-Headers，这个仓库可以调取苹果的所有私有方法头文件，相当强大。

最后放上这个demo的地址:https://github.com/zys456465111/CustomPopAnimation（使用时，切换工程的scheme就能切换不同方案。对于方案二，只需要导航控制器的类就可以了。）


pod 'FDFullscreenPopGesture'


还发现了一个问题, 比如前一个页面是没有NavigationBar , 后一个页面有NavigationBar , 最好在前一个页面通过这种方式设置导航栏隐藏,如果直接使用     self.navigationController.navigationBarHidden = YES ;  没有设置动画的, 通过手势pop回来的时候,导航栏的位置是有很强的割裂感,嗯,就是很丑.

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    [self.navigationController setNavigationBarHidden:YES animated:animated];
}

 

        在ios7以后，苹果推出了手势滑动返回功能，也就是从屏幕左侧向右滑动可依返回上一个界面。这项功能在大多数情况下方便了用户的使用，但是有时候，我们并不需要手势返回功能，比如某个页面加入了左右滑动翻页功能，用户在使用的时候很容易就返回到上一级界面了。
      禁用滑动返回手势需要在改界面的ViewController中添加如下代码：




[objc] view
 plain copy


 print?


- (void)viewDidAppear:(BOOL)animated  

{  

    [super viewDidAppear:animated];  

    // 禁用返回手势  

    if ([self.navigationController respondsToSelector:@selector(interactivePopGestureRecognizer)]) {  

        self.navigationController.interactivePopGestureRecognizer.enabled = NO;  

    }  

}  

        如果只是该界面禁用滑动返回手势，还需要添加如下代码使其他界面能够继续使用滑动返回手势：





[objc] view
 plain copy


 print?


- (void)viewWillDisappear:(BOOL)animated  

{  

    [super viewWillDisappear:animated];  

    // 开启返回手势  

    if ([self.navigationController respondsToSelector:@selector(interactivePopGestureRecognizer)]) {  

        self.navigationController.interactivePopGestureRecognizer.enabled = YES;  

    }  

}