58 同城 iOS 客户端 iOS11 及 iPhone X 适配实践


一、前言


前段时间 WWDC 大会上苹果推出了 iOS11 系统 和 iPhone X 新机型,相信各个 iOS 团队的开发者都已经在计划新系统和新机型的适配工作了。不得不说,新系统和新机型的发布确实是给 iOS 开发者带来了不小的工作量,因此有必要将 58 同城 iOS 客户端适配过程中遇到的问题跟大家分享一下。


二、iOS 11 UIKit


在适配 iOS 11 之前,我们首先要弄清楚 iOS 11 做了哪些改动,哪些改动会对我们现有的应用产生影响,这样有助于我们分析现象。建议大家看下 WWDC 的官方视频,视频中提到了如何适配 iOS 11 及如何设计和适配 iPhoneX 新机型:


  • Updating Your App for iOS 11:https://developer.apple.com/videos/play/wwdc2017/204/

  • Building Apps for iPhone X:https://developer.apple.com/videos/play/fall2017/201/

  • Designing for iPhone X:https://developer.apple.com/videos/play/fall2017/801/


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 客户端在适配过程中遇到了以下问题:


  1. 由于安全区域的引入,引起了 UIScrollView 的偏移。安全区域引起的 UIScrollView 偏移导致的问题非常多,文中仅仅以首页为例向大家展示了 58 同城的解决方式。当然,解决方式有很多种,只要了解问题的原因,那么解决方式可以根据自己的场景自由决定。文中没有提及 RN 和 web 的适配方式,主要原因是 RN 和 web 的适配方式与 Native 的适配方式类似,最主要的工作仍然是适配安全区域。


  2. tableView 的变化总体而言还是很大的,因此需要我们仔细观察现象排查代码。


  3. 对于导航栏的适配,我们应该注意 titleView 的内部约束,返回按钮的适配需要注意的是修改约束的时机。


  4. 键盘抬起本身并不会引起适配问题,但是涉及到安全区域的适配可能就会导致 UI 处理不正确。


  5. 开发者应该根据场景来控制虚拟 home 的显示和隐藏。


以上是 58 同城 iOS 客户端在适配过程中遇到的问题。当然,实际适配过程中遇到的问题远比文中描述的多,且情况要更为复杂。文中只是列出了一些比较典型的问题,希望对读者有所帮助。



阅读更多
上一篇ARKit:也许是 iPhone 十周年最好的新开始
下一篇微信全文搜索优化之路
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭