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

图 1 UIKit’sBar 提供 size 的方法截图

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

图 2 安全区域示意图

iOS11 引入了安全区域的概念，默认情况下安全区域是指 NavigationBar 以下 TabBar 以上的区域（iPhoneX 则不包括底部的虚拟 Home 区域），也就是说 StatusBar、NavigationBar、TabBar、虚拟 Home 都不是安全区域（可参见图 2）。为了帮助开发者判断各个 view 与安全区域的距离关系，iOS11 在 UIView 加入了一个属性：

需要注意的是这个属性是描述 view 与页面安全区域的距离关系，如果 view 的某个方向超过了安全区域则这个方向的数值为正数，如果 view 完全在安全区域内则 safeAreaInsets 的值全为 0。如在图 3 所示一个空白页面中。

图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 所示：

图 4 contentInsetAdjustmentBehavior

如果 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 所示：

图 5 关闭预估高度方法执行顺序打印

而开启估算行高之后 tableView 会先执行：

再执行：

方法调用次数减少且调用顺序变为如图 6 所示：

图 6 开启预估高度方法执行顺序打印

由此可见：

的调用次数大大减少。但是如果开发者实现：

方法，那么无论是否关闭 estimatedRowHeight，API 的调用顺序和调用次数都是一样的，如图 7 所示。

图 7 实现预估高度方法后方法执行顺序打印

因此我们要注意新系统中 API 执行顺序和执行次数的变化。

除此之外我们还应该注意在开启预估高度tableView.estimatedSectionHeaderHeight = UITableViewAutomaticDimension; 的情况下，如果不实现

和

那么

和

是不会被执行的。

三、58 同城的实战经历

适配 iPhoneX 首先要添加一个 1125x2436 的启动图，否则会在屏幕的上方和下方留下两道黑框。在适配开始前先简单介绍下 58 同城 iOS 客户端的页面结构，因为页面结构不同可能遇到的问题会不尽相同。58 同城 iOS 客户端的 key window 的 rootViewController 是一个导航控制器，而不是 UITabBarController。导航控制器的 rootViewController 是一个 UITabBarController 样式（非 UITabBarController）的 ViewController。了解了应用的结构之后，下面介绍下 58 同城 iOS 客户端适配过程中遇到的比较典型的问题：

1. 首页

先看下适配之前的首页，如图 8 所示：

图 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：

图 9 适配后首页图

2. 列表

在适配过程中，我们发现在二手物品列表，上拉加载数据时底部自定义的 tabBar 会来回反复地进行显示隐藏，tabBar 为下图蓝框内区域，如图 10 所示：

图 10 带有 tab 的列表图

经过排查我们发现 tableView 的 contentOffset 在有新的内容被添加进来的时候会产生跳动，如：不断上拉的一个列表，列表的 contentOffset 的 Y 值会不断增大，如果上拉过程中触发网络请求添加了新的内容到列表中，那么列表的 contentOffset 会产生一个跳动。如图 11 所示，在 contentOffset 的 Y 值为 9000 左右的时候列表新增了一页数据，导致 contentOffset 的 Y 值变为 3000 左右。

图 11 上拉加载更多时 scrollView 的偏移量 Y 值打印图

当下拉返回顶部时，contentOffset 的 Y 值会产生一系列不连续的跳动，如当前 contentOffset 的 Y 值为 3600，下拉后变为 3500 左右然后又变为 3600 左右，如图 12 打印所示：

图 12 下拉返回时 scrollView 的偏移量 Y 值打印图

如果利用 contentOffset 的 Y 值变化判断滑动方向的话，那么现在会判断为方向时而向上时而向下，导致底部的 tabBar 反复隐藏显示。

问题根本原因是由于

方法中获取 aScrollView 的偏移量会存在跳动的现象。具体的解决办法与各自的实现逻辑有较强的关联，在此不进行详细阐述。

3. IM

在使用 iOS11 beta 版时我们发现 IM 会话页的很多消息都变成了未识别消息类型，图 13 中左侧为适配前效果，右侧为适配后效果：

图 13 IM 会话页适配前后对比图

当消息滑出屏幕再滑回来时消息才被正确解析出来。最开始以为是 Xcode9 beta 版的 bug，因为只有 Xcode 9 打包安装的应用才会出现这种问题，而通过 Xcode8 正式版打包后安装到 iOS11 的手机上并不会出现这种问题。不过随着 beta 版的不断稳定，这种现象并没有随之消失，因此我们觉得有必要查看下消息不识别的具体原因。经过排查后我们发现，异常情况出现的原 l 因是由于 tableView 没有取到可重用的 cell，代码如图 14：

图 14 tableView 获取 Cell 的方法图

会话页将未取到 cell 作为一种异常情况进行了处理，处理方式是将这种情况当做未识别消息展示，处理逻辑如图 15 所示：

图 15 IM 会话列表异常处理代码

经过分析，取不到 cell 很有可能是因为 cell 没有被注册，而之前代码中注册 cell 的逻辑在

方法中。由于 iOS11 默认开启了 estimatedRowHeight，导致

方法先执行，

后执行，因此 cell 没有被注册成功，代码走进了异常处理逻辑。为了尽量不修改之前的业务逻辑，我们采用的适配方式的将估算高度关闭。

除此之外，IM 还存在适配安全区域的问题。未适配之前，IM 会话页面的输入框在 iPhoneX 的非安全区域内，见图 16 标注区域。

图 16 IM 会话页底部输入未适配前图

因此页面的底部需要设置 34 点的边距。iPhoneX 与其他手机很明显的不同就是键盘的高度，iPhoneX 的键盘高度为 333，这个键盘是从屏幕底部抬起并跨过了底部的虚拟 home 区域，键盘在安全区域内的高度为（333-34）。因此在监听键盘的事件中要注意对抬起高度的处理，以 IM 会话页为例，在非 iPhoneX 手机上输入框会上升 keyboardHeight 的高度，但是在 iPhoneX 上则只需要上升 keyboardHeight-34 点的高度。在 iPhoneX 手机上我们要格外注意键盘高度和安全区域结合带来的潜在问题。

4. 发布

在适配发布页面的时候，我们发现小区搜索页面的 titleView 在 iOS11 手机上变得很小，没有完全展开，效果如图 17 所示：

图 17 小区选择未适配前图

图 16 中的导航栏的 titleView 是 WBPUBSearchBar 类型的。由于自定义的 WBPUBSearchBar 是原来是通过 initWithFrame: 来创建并指明宽高的，WBPUBSearchBar 内部布局是依赖 Masonry 的，但是布局并没有设置 textFiled 和 button 的宽度，仅仅指明了 textFiled 和 button 各自的左右间距。在此情况下，自定义的 titleView 无法依赖内部子视图的约束得到正确的宽度，因此 titleView 的宽度并不正确。因此需要实现方法：

向外界提供自身的 size。当然除了实现 intrinsicContentSize 方法外也可以通过添加自身约束的方式来设置自身的正确合理的 size。

5. 视频

58 同城的二手房详情页支持视频展示房源，当全屏播放视频的时候会导致虚拟 home 条遮挡住视频内容，适配前视频全屏播放效果如图 18。

图 18 房源视频全屏播放图

由于在播放视频的时候有交互较少，苹果允许开发者在当前页面隐藏虚拟 home 条。因此可以在视频播放控制器中实现下述方法来隐藏虚拟 home 条：

在适当时机刷新虚拟 home。

实现 prefersHomeIndicatorAutoHidden 方法,返回是否需要隐藏虚拟 home。

当用户触碰屏幕时虚拟 home 会再次出现。这样就可以解决横屏虚拟 home 遮挡屏幕的问题。

6. 宠物

在使用 iOS11 beta 版时我们发现导航栏的自定义返回按钮距离屏幕左侧过远。这种情况只有在 Xcode9 编译时才会出现，Xcode8 编译打包在 iOS11 beta 的手机上运行并不会出现这种问题。对比导航栏的视图层级结构我们发现导航栏的层级做了很大的变动。

图 19 iOS 11 前导航栏层级结构和实际展示图

图 20 iOS11 导航栏层级结构和实际展示图

在 iOS11 下设置 UIBarButtonItem 时，系统新增了 _UINavigationBarContentView 和 _UIButtonBarStackView 两层 View，新增的两层 frame 是有偏移的，而且布局采用的是约束方式。因此需要遍历层级找到 _UIButtonBarStackView 这层视图并修改它与 _UINavigationBarContentView 间的约束，修改约束的时机放自定义导航控制器的在 viewDidLayoutSubviews 方法中。修改约束关键代码如图 21 所示：

图 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）