58 同城 iOS 客户端 iOS11 及 iPhone X 适配实践
一、前言
前段时间 WWDC 大会上苹果推出了 iOS11 系统 和 iPhone X 新机型，相信各个 iOS 团队的开发者都已经在计划新系统和新机型的适配工作了。不得不说，新系统和新机型的发布确实是给 iOS 开发者带来了不小的工作量，因此有必要将 58 同城 iOS 客户端适配过程中遇到的问题跟大家分享一下。
二、iOS 11 UIKit
在适配 iOS 11 之前，我们首先要弄清楚 iOS 11 做了哪些改动，哪些改动会对我们现有的应用产生影响，这样有助于我们分析现象。建议大家看下 WWDC 的官方视频，视频中提到了如何适配 iOS 11 及如何设计和适配 iPhoneX 新机型：
1. UIKit’sBars
iOS11 UIKit’sBar 改动很大，对现有的应用来说 UINavigationBar 的 titleView 适配应该是最大的问题，LargeTitle 虽然看起来似乎是很大的改动，但是实际上对现有的应用没有太多的影响。iOS11 之后 UINavigationBar 和 UIToolbar 支持 Auto Layout ，开发者必须要提供自定义视图的 size。如果自定义 titleView 中使用了 Auto Layout，那么通过设置自定义 titleView 的 frame 的方式来设定 size 在某些场景下可能就不再合适了，开发者应该着重注意下自定义 view 内部的约束（具体案例将在下文中阐述）。如图 1 所示，我们可以通过以下三种方式来提供 size：
- 约束自身宽高；
- 实现 intrinsicContentSize 方法；
- 利用子视图宽高及间距来约束 titleView；
2. UIScrollView
iOS11 引入了安全区域的概念，默认情况下安全区域是指 NavigationBar 以下 TabBar 以上的区域（iPhoneX 则不包括底部的虚拟 Home 区域），也就是说 StatusBar、NavigationBar、TabBar、虚拟 Home 都不是安全区域（可参见图 2）。为了帮助开发者判断各个 view 与安全区域的距离关系，iOS11 在 UIView 加入了一个属性：
需要注意的是这个属性是描述 view 与页面安全区域的距离关系，如果 view 的某个方向超过了安全区域则这个方向的数值为正数，如果 view 完全在安全区域内则 safeAreaInsets 的值全为 0。如在图 3 所示一个空白页面中。
红、蓝 view 是父子视图的关系，且蓝色子视图完全在红色视图内，由于红、蓝两个 view 顶部超过安全区域 44 点（状态栏 44 高度），所以它们的 safeAreaInsets 都为 {44, 0, 0, 0}，也就是说在同一个控制器中，他们的安全区域是一致的，与视图层级无关。在一个控制器中，安全区域并不是固定不变的，可以通过 ViewController 的 additionalSafeAreaInsets 方法来修改页面的安全区域，如果此时将安全区域上延 11 个点。
那么它们的 safeAreaInsets 都会变为 {33, 0, 0, 0}。
我们再来看 UIScrollView 新增加的两个很重要的属性：
iOS 11 中 adjustedContentInset 是用来调整 scrollView 内容边距的属性，这个属性实际上是 contentInset和 safeAreaInsets 在各个方向上的加和，即 contentInset+safeAreaInsets。contentInsetAdjustmentBehavior 是控制采取何种策略来控制调整边距的属性，默认为 UIScrollViewContentInsetAdjustmentAutomatic。在 iOS 11 之前，控制是否自动调整内边距的属性是 UIViewController 的 automaticallyAdjustsScrollViewInsets，但是这个属性现在已经废弃，取而代之的是 UIScrollView 的 contentInsetAdjustmentBehavior。contentInsetAdjustmentBehavior 共有四种设置，如图 4 所示：
如果 UIScrollView 需要调整内容边距则加上安全区域的偏移，即 adjustedContentInset = contentInset+safeAreaInsets，如果不调整则 safeAreaInsets 不参与到计算中，即 adjustedContentInset = contentInset。简而言之，contentInsetAdjustmentBehavior 就是告诉 UIScrollView 在计算 adjustedContentInset 时要不要加上 safeAreaInsets。
3. UITableView
UITableView 除了继承自 UIScrollView 的特性外，还有自身 API 的变动。新系统中，UITableView 开启了估算行高，estimatedRowHeight、 estimatedSectionHeaderHeight、estimatedSectionFooterHeight不再默认是 0，而是 UITableViewAutomaticDimension（这个值打印输出是 -1），这一举措旨在帮助开发者提高性能，减少 heightForRowAtIndexPath: 方法的的调用次数，但是这样会导致 API 执行顺序发生变化。在没有开启估算行高之前 tableView 总是先执行：
再执行
API 调用顺序如图 5 所示：
而开启估算行高之后 tableView 会先执行：
再执行：
方法调用次数减少且调用顺序变为如图 6 所示：
由此可见：
的调用次数大大减少。但是如果开发者实现：
方法，那么无论是否关闭 estimatedRowHeight，API 的调用顺序和调用次数都是一样的，如图 7 所示。
因此我们要注意新系统中 API 执行顺序和执行次数的变化。
除此之外我们还应该注意在开启预估高度tableView.estimatedSectionHeaderHeight = UITableViewAutomaticDimension; 的情况下，如果不实现
和
那么
和
是不会被执行的。
三、58 同城的实战经历
适配 iPhoneX 首先要添加一个 1125x2436 的启动图，否则会在屏幕的上方和下方留下两道黑框。在适配开始前先简单介绍下 58 同城 iOS 客户端的页面结构，因为页面结构不同可能遇到的问题会不尽相同。58 同城 iOS 客户端的 key window 的 rootViewController 是一个导航控制器，而不是 UITabBarController。导航控制器的 rootViewController 是一个 UITabBarController 样式（非 UITabBarController）的 ViewController。了解了应用的结构之后，下面介绍下 58 同城 iOS 客户端适配过程中遇到的比较典型的问题：
1. 首页
先看下适配之前的首页，如图 8 所示：
适配前，首页主要存在的问题有 3 个：
- 顶部的天气与状态栏有重叠；
- 首页的动画默认已经进行了一部分；
- 底部的 tabBar 在非安全区域内。
先看问题 1，产生问题 1 的原因是由于 iPhoneX 的状态栏高度产生了变化，由 20 变成了 44，天气组件的位置没有预留出新增的 24 点，导致与状态栏重叠。解决的办法是对顶部 view 进行重新布局约束，根据机型来判断是够需要增加 24 点。机型的判断由于没有真机验证，我们无法准确地获取到设备名称，因此暂时采用设备高度来判断机型。如果屏幕高度为 812，则暂时可以认为是 iPhoneX：
问题 2 的原因是 tableView 的安全区域的引起的。由于首页 tableView 的 contentInsetAdjustmentBehavior 默认为 UIScrollViewContentInsetAdjustmentAutomatic， 在隐藏导航栏的情况下 tableView 的内容偏移为安全区域的 44 点，因此 tableView 自动偏移了 44 点，看起来像动画进行了一半。解决方法是将 contentInsetAdjustmentBehavior 设置为 never 忽略安全区域偏移。
问题 3 的原因是 iPhoneX 新增了 34 点高度的虚拟 home 区域替代了 home 实体键。虚拟 home 区域并不是安全区域，因此需要在 iPhoneX 的机型上，屏幕底部预留出 34 点高度。
适配后首页在 iPhoneX 上的效果如图 9：
2. 列表
在适配过程中，我们发现在二手物品列表，上拉加载数据时底部自定义的 tabBar 会来回反复地进行显示隐藏，tabBar 为下图蓝框内区域，如图 10 所示：
经过排查我们发现 tableView 的 contentOffset 在有新的内容被添加进来的时候会产生跳动，如：不断上拉的一个列表，列表的 contentOffset 的 Y 值会不断增大，如果上拉过程中触发网络请求添加了新的内容到列表中，那么列表的 contentOffset 会产生一个跳动。如图 11 所示，在 contentOffset 的 Y 值为 9000 左右的时候列表新增了一页数据，导致 contentOffset 的 Y 值变为 3000 左右。
当下拉返回顶部时，contentOffset 的 Y 值会产生一系列不连续的跳动，如当前 contentOffset 的 Y 值为 3600，下拉后变为 3500 左右然后又变为 3600 左右，如图 12 打印所示：
如果利用 contentOffset 的 Y 值变化判断滑动方向的话，那么现在会判断为方向时而向上时而向下，导致底部的 tabBar 反复隐藏显示。
问题根本原因是由于
方法中获取 aScrollView 的偏移量会存在跳动的现象。具体的解决办法与各自的实现逻辑有较强的关联，在此不进行详细阐述。
3. IM
在使用 iOS11 beta 版时我们发现 IM 会话页的很多消息都变成了未识别消息类型，图 13 中左侧为适配前效果，右侧为适配后效果：
当消息滑出屏幕再滑回来时消息才被正确解析出来。最开始以为是 Xcode9 beta 版的 bug，因为只有 Xcode 9 打包安装的应用才会出现这种问题，而通过 Xcode8 正式版打包后安装到 iOS11 的手机上并不会出现这种问题。不过随着 beta 版的不断稳定，这种现象并没有随之消失，因此我们觉得有必要查看下消息不识别的具体原因。经过排查后我们发现，异常情况出现的原 l 因是由于 tableView 没有取到可重用的 cell，代码如图 14：
会话页将未取到 cell 作为一种异常情况进行了处理，处理方式是将这种情况当做未识别消息展示，处理逻辑如图 15 所示：
经过分析，取不到 cell 很有可能是因为 cell 没有被注册，而之前代码中注册 cell 的逻辑在
方法中。由于 iOS11 默认开启了 estimatedRowHeight，导致
方法先执行，
后执行，因此 cell 没有被注册成功，代码走进了异常处理逻辑。为了尽量不修改之前的业务逻辑，我们采用的适配方式的将估算高度关闭。
除此之外，IM 还存在适配安全区域的问题。未适配之前，IM 会话页面的输入框在 iPhoneX 的非安全区域内，见图 16 标注区域。
因此页面的底部需要设置 34 点的边距。iPhoneX 与其他手机很明显的不同就是键盘的高度，iPhoneX 的键盘高度为 333，这个键盘是从屏幕底部抬起并跨过了底部的虚拟 home 区域，键盘在安全区域内的高度为（333-34）。因此在监听键盘的事件中要注意对抬起高度的处理，以 IM 会话页为例，在非 iPhoneX 手机上输入框会上升 keyboardHeight 的高度，但是在 iPhoneX 上则只需要上升 keyboardHeight-34 点的高度。在 iPhoneX 手机上我们要格外注意键盘高度和安全区域结合带来的潜在问题。
4. 发布
在适配发布页面的时候，我们发现小区搜索页面的 titleView 在 iOS11 手机上变得很小，没有完全展开，效果如图 17 所示：
图 16 中的导航栏的 titleView 是 WBPUBSearchBar 类型的。由于自定义的 WBPUBSearchBar 是原来是通过 initWithFrame: 来创建并指明宽高的，WBPUBSearchBar 内部布局是依赖 Masonry 的，但是布局并没有设置 textFiled 和 button 的宽度，仅仅指明了 textFiled 和 button 各自的左右间距。在此情况下，自定义的 titleView 无法依赖内部子视图的约束得到正确的宽度，因此 titleView 的宽度并不正确。因此需要实现方法：
向外界提供自身的 size。当然除了实现 intrinsicContentSize 方法外也可以通过添加自身约束的方式来设置自身的正确合理的 size。
5. 视频
58 同城的二手房详情页支持视频展示房源，当全屏播放视频的时候会导致虚拟 home 条遮挡住视频内容，适配前视频全屏播放效果如图 18。
由于在播放视频的时候有交互较少，苹果允许开发者在当前页面隐藏虚拟 home 条。因此可以在视频播放控制器中实现下述方法来隐藏虚拟 home 条：
- 在适当时机刷新虚拟 home。
- 实现 prefersHomeIndicatorAutoHidden 方法,返回是否需要隐藏虚拟 home。
当用户触碰屏幕时虚拟 home 会再次出现。这样就可以解决横屏虚拟 home 遮挡屏幕的问题。
6. 宠物
在使用 iOS11 beta 版时我们发现导航栏的自定义返回按钮距离屏幕左侧过远。这种情况只有在 Xcode9 编译时才会出现，Xcode8 编译打包在 iOS11 beta 的手机上运行并不会出现这种问题。对比导航栏的视图层级结构我们发现导航栏的层级做了很大的变动。
在 iOS11 下设置 UIBarButtonItem 时，系统新增了 _UINavigationBarContentView 和 _UIButtonBarStackView 两层 View，新增的两层 frame 是有偏移的，而且布局采用的是约束方式。因此需要遍历层级找到 _UIButtonBarStackView 这层视图并修改它与 _UINavigationBarContentView 间的约束，修改约束的时机放自定义导航控制器的在 viewDidLayoutSubviews 方法中。修改约束关键代码如图 21 所示：
四、总结
总结一下，58 同城 iOS 客户端在适配过程中遇到了以下问题：
-
由于安全区域的引入，引起了 UIScrollView 的偏移。安全区域引起的 UIScrollView 偏移导致的问题非常多，文中仅仅以首页为例向大家展示了 58 同城的解决方式。当然，解决方式有很多种，只要了解问题的原因，那么解决方式可以根据自己的场景自由决定。文中没有提及 RN 和 web 的适配方式，主要原因是 RN 和 web 的适配方式与 Native 的适配方式类似，最主要的工作仍然是适配安全区域。
-
tableView 的变化总体而言还是很大的，因此需要我们仔细观察现象排查代码。
-
对于导航栏的适配，我们应该注意 titleView 的内部约束，返回按钮的适配需要注意的是修改约束的时机。
-
键盘抬起本身并不会引起适配问题，但是涉及到安全区域的适配可能就会导致 UI 处理不正确。
-
开发者应该根据场景来控制虚拟 home 的显示和隐藏。
以上是 58 同城 iOS 客户端在适配过程中遇到的问题。当然，实际适配过程中遇到的问题远比文中描述的多，且情况要更为复杂。文中只是列出了一些比较典型的问题，希望对读者有所帮助。
（http://blog.csdn.net/csdnnews/article/details/78127641）
