一、了解present和dismiss

一个iOS开发，这个控制器的打开和关闭，应该是接触UIKit所接触的第一个关于UIViewController的API，然而，你真的了解它吗？

同样的，本文默认你已经了解UIViewController的present和dismiss方法，并多次运用。另外本文不再加OC语言的代码，毕竟都能读得懂swift。

二、谁来调用dismiss方法？

咱们从最基本的开始：一个控制器A，和一个控制器B。

A present B

让A打开B，在A中是这样写:

//A

let B = ViewController()

self.present(B, animated: true, completion: nil)

在B中需要关闭B的时候在B中这么写：

//B

self.dismiss(animated: true, completion: nil)

难道？这样写有问题？这....可能大多数开发者都是这么写，也没有出现过什么问题。但是...

YES，这样写在“理论”讲，是错误的。

别急，在实际上，这么写大多数情况是没有问题的，因为iOS系统帮我们做了很多。

三、presentingViewController和presentedViewController

想了解为什么说那么写在“理论上”是错误的，先从presentingViewController和presentedViewController说起。

为了不使本文枯燥，不引用大段描述和说明，只针对案例解释。当从A中弹出B后：

self.presentingViewController: 在A中，就是nil；在B中，就是A

self.presentedViewController：在A中，就是B；在B中，就是nil

那为什么说在B中调用dismiss在“理论上”是错的呢？因为有这么一个规则一定要记住！

谁污染，谁治理！

很熟悉对不对？MRC的法则，谁创建谁释放！所以A打开了B，当然是A来负责关闭！

正确写法是在A里调用self.dismiss(animated: true, completion: nil)。

等等，之前都是B里调用？没错，dismiss方法系统会自动优化，当B视图控制器调用dismiss时，它并没有打开任何界面，就将dismissViewController方法会自动交给B的presentingViewController执行，也就是A来执行。

如果现在A没有打开B的话，调用dismissViewController时它没有presentedViewController，转交给它的presentingViewController，但是它也没有presentingViewController，所以dismiss就不执行了。swift中可选型能很好的解释了：

self.presentingViewController?.dismiss(animated: true, completion: nil) //presentingViewController为nil，后面的不执行

扩展：关于实例为空的时候方法不执行，可百度“iOS消息转发”了解。

既然这样，说这个有毛用？

如果你从A打开了B，从B打开了C，现在怎么直接回到A？

你很可能会通过一些手段让B执行dismiss方法，但你会得到错误的结果，因为你这里如果交给B执行dismiss方法，和直接在C里面执行dismiss方法的效果是一样的，也就是说你到了B的界面并没有到A。

SO，dismiss方法必须让需要回到的这个控制器来执行。那么一个控制器的presentingViewController一定是打开它的那个控制器吗？继续往后看。

四、presentingViewController是打开它的那个控制器吗？

从上文，A打开了B，A是B的presentingViewController，那是不是所有的控制器的presentingViewController都是调用presnet方法打开自己的那个控制器呢？

NO！但是刚才A打开了B，不是说A是B的presentingViewController吗？当然，不是说一个控制器A弹出一个控制器B，A就一定是B的presentingViewController。

吃屁吧你

别着急，看几个图片娱乐一下：

第一种

这时箭头指向的控制器的presenting是谁？

第二种

这时箭头指向的控制器的presenting是谁？

第一个图片是navigationController，第二个是tabbarController。又跟你想的不一样了？看来你真的了解的太少，这时咱们得了解一下子控制器了。

四、子控制器childViewControllers

刚才在了解presentingViewController和presentedViewController的时候，如果你用代码试了一下，会发现parentViewController(OC中，swift叫parent)，父控制器。有父就有子，每个控制器都有一个属性，叫做childViewControllers，存放它的子控制器。这里对childViewControllers的使用方法使用场景使用优势不做探讨。我们假设你了解并多次使用了子控制器来显示复杂界面的。

但是实际上只要你学习iOS的UIKit，你就肯定已经多次，甚至经常使用了这个东西。

我们知道，在一个有导航控制器的控制器P中加入了子控制器Q，然后添加了Q的view，这个Q就可以使用self.navigationController进行跳转，Q是利用的P的导航控制器进行跳转。也就是说Q的关于控制器的操作都被P给处理了。

那新加入一个问题：如果在Q中present出来一个界面R，那这个R的presentingViewController是谁呢？

是的，是P。此时已经出现了刚才说的问题，Q打开了R，但是R的presentingViewController却是P。这时因为Q是P的子控制器。

那么就可以解释上面两个图片的结果为什么是navi控制器和tabbar控制器了。因为使用标签控制器和导航控制器，都是显示的子控制器的内容，一个带导航栏，一个带标签栏。

所有的控制器都有childViewControllers属性，保存了所有的子控制器，但是有些特殊的控制器，比如UIPageViewController、UINavigationController、UITabBarController等，还有一个viewControllers属性，实际内容和childViewControllers一样。这些特殊的控制器实际上不展示主要内容，主要内容由子控制器展示。

所以刚才说，只要你学了UIKit用了UINavigationController和UITabBarController，你就在使用childViewControllers在做界面的管理了。

因此，当某个控制器有父控制器的时候，它的presentingViewController是父控制器的presentingViewController。

说这么多，又有毛用？

image.png

比如你做过转场动画，会用到这么个方法animateTransition(using transitionContext: UIViewControllerContextTransitioning)，当然你首先要做的，就是从context里获取toViewcontroller和fromViewController。如果你的这个转场是个modalPresent，此时你获取到的fromViewController可不一定是调用present的那个控制器，所以你要根据这个VC来做一些动画，可能就要有问题了。

如果是带UINavigationController，需要通过nav.topViewController获取nav当前的控制器，如果是带UITabBarController，需要通过tab.selectedViewController获取tab当前的控制器。

四、如何强制指定presentingViewController就是打开自己的那个？

我们需要了解一下这两个属性：

@property(nonatomic,assign) BOOL definesPresentationContext;

@property(nonatomic,assign) UIModalPresentationStyle modalPresentationStyle;

modalPresentationStyle属性决定了将要present的控制器以何种方式展现，默认值为UIModalTransitionStyleCoverVertical。如果把一个控制器的definesPresentationContext属性设置为YES，那么在需要进行UIModalPresentationCurrentContext类型的跳转的时候，UIKit会使用视图层级内的这个控制器来进行跳转。

avc.definesPresentationContext = false

avc.modalPresentationStyle = .currentContext

大功告成！现在presentingViewController能够获取到我们期望的对象了。