前两天用咕唧分享照片的时候，我发现分享出去的照片，与我查看时的角度不一致，被转了90°。这是一个需要解决的问题。

分析问题1

一开始，我以为是咕唧的隐私保护功能导致的。为了保护隐私，咕唧默认会移除照片中的GPS信息和Exif信息。此外，用户可以在设置中，选择分享这些信息。

我们知道，平常拍照片，你的手机可能是横着拍，也可能是竖着拍，偶尔可能倒过来拍。但是不管你拍照时，手机处于何种角度，系统在显示该照片的时候，都会正确的显示该照片为当时你在屏幕上见到的样子。因为系统会读取照片属性中的方向信息，从而知道你拍照时手机的状态，这样就能正确的显示。

我首先就是认为Exif信息被咕唧删除了，系统没有了参照，只能按照默认的方式处理，因而与实际的方式造成了偏差。

解决问题1

我创建了一个测试项目，然后将那张出问题的照片作为资源，做同样的缩小操作，之后查看照片属性。结果我发现其实方向Orientation属性并没有保存在Exif信息，而是在图片的属性中。也就是说，事实上，咕唧缩小的图片是包含这个信息的。之前的分析是错误的。

那么是什么原因导致了包含了正确方向信息的照片，实际显示的反而是错误的呢？

分析问题2

排除了一切不可能，剩下的就是唯一的可能。

我们知道，系统在读取照片的时候，会根据方向Orientation做正确的处理。也就是说，CGImageSourceCreateImageAtIndex(_:_:_:)获得的照片本身就是正确方向的。那么这个方向正确的照片。在通过CGImageDestination重新保存时，就应该改变Orientation值为默认值，而不是继续保存原始值。

解决问题2

如果上面的分析正确，思路就很简单了。保存之前，检查方向Orientation是否为默认值，如果不是，则修改为默认值。

注意：是只要CGImageSource加载了图片，就会造成这个问题。因此，不仅缩小照片有这个问题，仅仅是去除Exif或者GPS信息，都会存在这个问题，同样需要修改方向Orientation为默认值。

思考

我在想要不要把这个问题，作为bug报告给苹果。思考的结果是不要。因为如果苹果修复了这个问题，将新照片变成与原始照片的方向一致。那么之前有做过特殊处理的应用，照片的方向就又都会从正确变成错误。这相当于是API不延续了。

为了保证之前的兼容性，好多时候，只能遗留不正确的代码。这个就是API设计出问题的代价。

参考资料

• 如何处理iOS中照片的方向
• CGImageDestination写入属性时的架构

模型

• UISplitViewController拥有两个视图控制器，在故事版中分别对应主视图控制器和细节视图控制器，在编码中对应为viewControllers属性，主视图控制器在前，细节视图控制器在后。
• 开发者通过preferredDisplayMode推荐想要的模式，通过displayMode获得当前的模式。
• 在iPhone中，横屏、和竖屏都是allVisible，此时可以通过UISplitViewControllerDelegate的splitViewController(_:collapseSecondary:onto:)方法来告诉系统默认是显示哪个视图控制器。
• 在iPad中，横屏是allVisible，竖屏是primaryHidden。此时如果想要默认显示主视图控制器，需要在UISplitViewControllerDelegate的splitViewController(_:willChangeTo:)方法，设定preferredDisplayMode为primaryOverlay。

UISplitViewController

• displayMode
  • 这是一个只读属性。
  • 它代表的是UISplitViewController当前的具体模式。
• preferredDisplayMode
  • 开发者只能通过displayMode了解到UISplitViewController当前的模式。如果开发者不满意这个模式，想要手动调节，就可以通过修改preferredDisplayMode来实现。
  • 值得注意的是，这个是开发者的推荐，并不是完全的设定，系统仅会在条件允许的情况下，优先使用这个推荐。如果系统认为可视面积过小，就会忽略这个推荐，而使用系统认为最适合的模式。

UISplitViewController.DisplayMode（按照rawValue的数值排列）

• automatic
  • 自动模式是默认的模式，完全由系统进行判断，开发者没有任何推荐。
  • 注意：这个自动模式，只在preferredDisplayMode中有效，displayMode实际显示的，只会是下面三个模式。
• primaryHidden
  • UISplitViewController包含两个视图控制器，主视图控制器和细节视图控制器。primaryHidden表示优先显示细节视图控制器，而将主视图控制器隐藏起来。用户需要使用手势或者是后退按钮显示主视图控制器。
  • iPad在竖屏时默认会是这个模式。
• allVisible
  • 同时显示主视图控制器和细节视图控制器。
  • 需要注意：这个模式虽然叫allVisible，却不是一定都能同时显示。如果不能，就会需要告诉系统，优先显示哪个视图控制器。
  • iPad在横屏时默认会是这个模式。此时会全部显示。
  • iPhone 6s Plus在竖屏和横屏时都是这个模式。竖屏时，因为实际上不能全部显示，就还需要考虑UISplitViewControllerDelegate的splitViewController(_:collapseSecondary:onto:)方法。
• primaryOverlay
  • 与primaryHidden类似。但是会优先显示主视图控制器，叠加在细节视图控制器之上。
  • 如果我们要特别提示用户主视图控制器的存在，就可以使用这个选项。

UISplitViewControllerDelegate

splitViewController(_:collapseSecondary:onto:)方法

当UISplitViewController.DisplayMode为allVisible，且可显示的面积不能同时容纳显示主视图控制器和细节视图控制器时，系统会调用UISplitViewControllerDelegate的splitViewController(_:collapseSecondary:onto:)方法。

这个方法返回true代表显示主视图控制器，返回false代表显示细节视图控制器。

splitViewController(_:willChangeTo:)方法

当你需要在系统选择了primaryHidden时，就更改为primaryOverlay。使用此方法。

最初的代码在这里。作者自己的说明。

最初的作品已经很好用了。只是细节需要改动一下。

更改

1. 原代码低于Swift 4.0，Xcode 11 beta 5无法编译。此次，先将Swift改成4.0。发现一切正常，没有需要改动的地方。
2. 原代码不支持暗模式，可以在故事版中将颜色重新选择为支持暗模式的。特别的，在资源中新建颜色资源AlertBackgroundColor，获得模拟器中UIAlertController.view在亮/暗模式下的背景颜色。并指定为Alert View的背景色。
3. 原代码ViewController.swift第55行使用了.overCurrentContext，这个在master/detail模式的布局中，如果detail中弹出自定义的警告窗口，之后旋转屏幕或者更改显示模式（比如由亮改暗），警告窗口就会出现问题。此处需要改成.overFullScreen。
4. 原代码CustomAlertView.swift第23行alertViewGrayColor使用了自定义颜色，注释掉掉。在第35行插入let alertViewGrayColor = UIColor.systemGray2。
5. CustomAlertView.swift第36行插入let lineThickness:CGFloat = 0.5，并且将第37-39行的width: 1.0改成width: lineThickness。

小结

经过以上的改动，就可以获得一个支持iOS 13 beta的自定义AlertController了。剩下的你只需要根据自己的需求，继续填充就可以了。