iOS开发日记42-UIScrollView与UITableview

今天博主有一个UIScrollView的需求,遇到了一些困难点,在此和你们分享,但愿可以共同进步.

UIScrollView（包括它的子类 UITableView 和 UICollectionView）是 iOS 开发中最经常使用也是最有意思的 UI 组件，大部分 App 的核心界面都是基于三者之一或三者的组合实现。

UIScrollView 是 UIKit 中为数很少能响应滑动手势的 view，相比本身用 UIPanGestureRecognizer 实现一些基于滑动手势的效果，用 UIScrollView 的优点在于 bounce 和 decelerate 等特性可让 App 的用户体验与 iOS 系统的用户体验保持一致。本文经过一些实例讲解 UIScrollView 的特性和实际使用中的经验。

UIScrollView 和 Auto Layout

iPhone 5 刚出来的时候，大部分不支持横屏的 App 都不须要作太多的适配工做，由于屏幕宽度没有变，table view 多个 cell 也不须要加 code。

可是在 iPhone 6 和 iPhone 6 Plus 发布之后，多分辨率适配终于再也不是 Android 开发的专利了。因而，从 iOS 6 起就存在的 Auto Layout 终于有了用武之地。

关于 Auto Layout 的基本用法再也不赘述，能够参考 Ray Wenderlich 上的教程（Part 2）。

但 UIScrollView 在 Auto Layout 是一个很特殊的 view，对于 UIScrollView 的 subview 来讲，它的 leading/trailing/top/bottom space 是相对于 UIScrollView 的 contentSize 而不是 bounds 来肯定的，因此当你尝试用 UIScrollView 和它 subview 的 leading/trailing/top/bottom 来互相决定大小的时候，就会出现「Has ambiguous scrollable content width/height」的 warning。

正确的姿式是用 UIScrollView 外部的 view 或 UIScrollView 自己的 width/height 肯定 subview 的尺寸，进而肯定 contentSize。

由于 UIScrollView 自己的 leading/trailing/top/bottom 变得很差用，因此我习惯的作法是在 UIScrollView 和它原来的 subviews 之间增长一个 content view，这样作的好处有：

• 不会在 storyboard 里留下 error/warning
• 为 subview 提供 leading/trailing/top/bottom，方便 subview 的布局
• 经过调整 content view 的 size（能够是 constraint 的 IBOutlet）来调整 contentSize
• 不须要 hard code 与屏幕尺寸相关的代码
• 更好地支持 rotation

Sample 中的 AutoLayout 演示了 UIScrollView + Auto Layout 的例子。

UIScrollViewDelegate

UIScrollViewDelegate 是 UIScrollView 的 delegate protocol，UIScrollView 有意思的功能都是经过它的 delegate 方法实现的。

了解这些方法被触发的条件及调用的顺序对于使用 UIScrollView 是颇有必要的，本文主要讲拖动相关的效果，因此 zoom 相关的方法跳过不提，拖动相关的 delegate 方法按调用顺序分别是：

- (void)scrollViewDidScroll:(UIScrollView *)scrollView

这个方法在任何方式触发 contentOffset 变化的时候都会被调用（包括用户拖动，减速过程，直接经过代码设置等），能够用于监控 contentOffset 的变化，并根据当前的 contentOffset 对其余 view 作出随动调整。

- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView

用户开始拖动 scroll view 的时候被调用。

- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset

该方法从 iOS 5 引入，在 didEndDragging 前被调用，当 willEndDragging 方法中 velocity 为 CGPointZero（结束拖动时两个方向都没有速度）时，didEndDragging 中的 decelerate 为 NO，即没有减速过程，willBeginDecelerating 和 didEndDecelerating 也就不会被调用。

反之，当 velocity 不为 CGPointZero 时，scroll view 会以 velocity 为初速度，减速直到 targetContentOffset。

值得注意的是，这里的 targetContentOffset 是个指针，没错，你能够改变减速运动的目的地，这在一些效果的实现时十分有用，实例章节中会具体提到它的用法，并和其余实现方式做比较。

- (void)scrollViewDidEndDragging:(UIScrollView *)scrollView willDecelerate:(BOOL)decelerate

在用户结束拖动后被调用，decelerate 为 YES 时，结束拖动后会有减速过程。

注，在 didEndDragging 以后，若是有减速过程，scroll view 的 dragging 并不会当即置为 NO，而是要等到减速结束以后，因此这个 dragging 属性的实际语义更接近 scrolling。

- (void)scrollViewWillBeginDecelerating:(UIScrollView *)scrollView

减速动画开始前被调用。

- (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView

减速动画结束时被调用，这里有一种特殊状况：当一次减速动画还没有结束的时候再次 drag scroll view，didEndDecelerating 不会被调用，而且这时 scroll view 的 dragging 和 decelerating 属性都是 YES。

新的 dragging 若是有加速度，那么 willBeginDecelerating 会再一次被调用，而后才是 didEndDecelerating；若是没有加速度，虽然 willBeginDecelerating 不会被调用，但前一次留下的 didEndDecelerating 会被调用，因此连续快速滚动一个 scroll view 时，delegate 方法被调用的顺序（不含 didScroll）多是这样的：

scrollViewWillBeginDragging: scrollViewWillEndDragging: withVelocity: targetContentOffset: scrollViewDidEndDragging: willDecelerate: scrollViewWillBeginDecelerating: scrollViewWillBeginDragging: scrollViewWillEndDragging: withVelocity: targetContentOffset: scrollViewDidEndDragging: willDecelerate: scrollViewWillBeginDecelerating: ... scrollViewWillBeginDragging: scrollViewWillEndDragging: withVelocity: targetContentOffset: scrollViewDidEndDragging: willDecelerate: scrollViewWillBeginDecelerating: scrollViewDidEndDecelerating: 

虽然不多有由于这个致使的 bug，可是你须要知道这种很常见的用户操做会致使的中间状态。例如你尝试在 UITableViewDataSource 的 tableView:cellForRowAtIndexPath: 方法中基于 tableView 的 dragging 和 decelerating 属性判断是在用户拖拽仍是减速过程当中的话可能会误判（见例 1）。

Sample 中的 Delegate 简单输出了一些 Log，你能够快速了解这些方法的调用顺序。

实例

下面经过一些实例，更详细地演示和描述以上各 delegate 方法的用途。

1. Table View 中图片加载逻辑的优化

虽然这种优化方式在如今的机能和网络环境下可能看似不那么必要，但在我最初看到这个方法是的 09 年（印象中是 Tweetie 做者在 08 年写的 Blog，可能有误），遥想 iPhone 3G/3GS 的机能，这个方法为多图的 table view 的性能带来很大的提高，也成了个人秘密武器。而如今，在移动网络环境下，你依然值得这么作来为用户节省流量。

先说一下原文的思路：

• 当用户手动 drag table view 的时候，会加载 cell 中的图片；
• 在用户快速滑动的减速过程当中，不加载过程当中 cell 中的图片（但文字信息仍是会被加载，只是减小减速过程当中的网络开销和图片加载的开销）；
• 在减速结束后，加载全部可见 cell 的图片（若是须要的话）；

问题 1：

前面提到，刚开始拖动的时候，dragging 为 YES，decelerating 为 NO；decelerate 过程当中，dragging 和 decelerating 都为 YES；decelerate 未结束时开始下一次拖动，dragging 和 decelerating 依然都为 YES。因此没法简单经过 table view 的 dragging 和 decelerating 判断是在用户拖动仍是减速过程。

解决这个问题很简单，添加一个变量如 userDragging，在 willBeginDragging 中设为 YES，didEndDragging 中设为 NO。那么 tableView: cellForRowAtIndexPath: 方法中，是否 load 图片的逻辑就是：

if (!self.userDragging && tableView.decelerating) { cell.imageView.image = nil; } else { // code for loading image from network or disk } 

问题 2：

这么作的话，decelerate 结束后，屏幕上的 cell 都是不带图片的，解决这个问题也不难，你须要一个形如 loadImageForVisibleCells 的方法，加载可见 cell 的图片：

- (void)loadImageForVisibleCells { NSArray *cells = [self.tableView visibleCells]; for (GLImageCell *cell in cells) { NSIndexPath *indexPath = [self.tableView indexPathForCell:cell]; [self setupCell:cell withIndexPath:indexPath]; } } 

问题 3：

这个问题可能不容易被发现，在减速过程当中若是用户开始新的拖动，当前屏幕的 cell 并不会被加载（前文提到的调用顺序问题致使），并且问题 1 的方案并不能解决问题 3，由于这些 cell 已经在屏上，不会再次通过 cellForRowAtIndexPath 方法。虽然不容易发现，但解决很简单，只须要在 scrollViewWillBeginDragging: 方法里也调用一次 loadImageForVisibleCells 便可。

再优化

上述方法在那个年代的确提高了 table view 的 performance，可是你会发如今减速过程最后最慢的那零点几秒时间，其实仍是会让人等得有些心急，尤为若是你的 App 只有图片没有文字。在 iOS 5 引入了 scrollViewWillEndDragging: withVelocity: targetContentOffset: 方法后，配合 SDWebImage，我尝试再优化了一下这个方法以提高用户体验：

• 若是内存中有图片的缓存，减速过程当中也会加载该图片
• 若是图片属于 targetContentOffset 能看到的 cell，正常加载，这样一来，快速滚动的最后一屏出来的的过程当中，用户就能看到目标区域的图片逐渐加载
• 你能够尝试用相似 fade in 或者 flip 的效果缓解生硬的忽然出现（尤为是像本例这样只有图片的 App）

核心代码：

- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView { self.targetRect = nil; [self loadImageForVisibleCells]; } - (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset { CGRect targetRect = CGRectMake(targetContentOffset->x, targetContentOffset->y, scrollView.frame.size.width, scrollView.frame.size.height); self.targetRect = [NSValue valueWithCGRect:targetRect]; } - (void)scrollViewDidEndDecelerating:(UIScrollView *)scrollView { self.targetRect = nil; [self loadImageForVisibleCells]; } 

是否须要加载图片的逻辑：

BOOL shouldLoadImage = YES; if (self.targetRect && !CGRectIntersectsRect([self.targetRect CGRectValue], cellFrame)) { SDImageCache *cache = [manager imageCache]; NSString *key = [manager cacheKeyForURL:targetURL]; if (![cache imageFromMemoryCacheForKey:key]) { shouldLoadImage = NO; } } if (shouldLoadImage) { // load image } 

更值得高兴的是，经过判断是否 nil，targetRect 同时起到了原来 userDragging 的做用。本例完整的代码见 Sample 中的 LazyLoad

2. 分页的几种实现方式

利用 UIScrollView 有多种方法实现分页，可是各自的效果和用途不尽相同，其中方法 2 和方法 3 的区别也正是一些同类 App 在模仿 Glow 的首页 Bubble 翻转效果时跟 Glow 体验上的的差距所在（希望他们不会看到本文而且调整他们的实现方式）。本例经过三种方法实现类似的一个场景，你能够经过安装到手机上来感觉三种实现方式的不一样用户体验。为了区分每一个例子的重点，本例没有重用机制，重用相关内容见例 3。

2.1 pagingEnabled

这是系统提供的分页方式，最简单，可是有一些局限性：

• 只能以 frame size 为单位翻页，减速动画阻尼大，减速过程不超过一页
• 须要一些 hacking 实现 bleeding 和 padding（即页与页之间有 padding，在当前页能够看到先后页的部份内容）

Sample 中 Pagination 有简单实现 bleeding 和 padding 效果的代码，主要的思路是：

• 让 scroll view 的宽度为 page 宽度 + padding，而且设置 clipsToBounds 为 NO
• 这样虽然能看到先后页的内容，可是没法响应 touch，因此须要另外一个覆盖指望的可触摸区域的 view 来实现相似 touch bridging 的功能

适用场景：上述局限性同时也是这种实现方式的优势，好比通常 App 的引导页（教程），Calendar 里的月视图，均可以用这种方法实现。

2.2 Snap

这种方法就是在 didEndDragging 且无减速动画，或在减速动画完成时，snap 到一个整数页。核心算法是经过当前 contentOffset 计算最近的整数页及其对应的 contentOffset，经过动画 snap 到该页。这个方法实现的效果都有个通病，就是最后的 snap 会在 decelerate 结束之后才发生，总感受很突兀。

2.3 修改 targetContentOffset

经过修改 scrollViewWillEndDragging: withVelocity: targetContentOffset: 方法中的 targetContentOffset 直接修改目标 offset 为整数页位置。其中核心代码：

- (CGPoint)nearestTargetOffsetForOffset:(CGPoint)offset { CGFloat pageSize = BUBBLE_DIAMETER + BUBBLE_PADDING; NSInteger page = roundf(offset.x / pageSize); CGFloat targetX = pageSize * page; return CGPointMake(targetX, offset.y); } - (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset { CGPoint targetOffset = [self nearestTargetOffsetForOffset:*targetContentOffset]; targetContentOffset->x = targetOffset.x; targetContentOffset->y = targetOffset.y; } 

适用场景：方法 2 和 方法 3 的原理近似，效果也相近，适用场景也基本相同，但方法 3 的体验会好不少，snap 到整数页的过程很天然，或者说用户彻底感知不到 snap 过程的存在。这两种方法的减速过程流畅，适用于一屏有多页，但须要按整数页滑动的场景；也适用于如图表中自动 snap 到整数天的场景；还适用于每页大小不一样的状况下 snap 到整数页的场景（不作举例，自行发挥，其实只须要修改计算目标 offset 的方法）。

完整代码参见 Pagination

3. 重用

大部分的 iOS 开发应该都清楚 UITableView 的 cell 重用机制，这种重用机制减小了内存开销也提升了 performance，UIScrollView 做为 UITableView 的父类，在不少场景中也很适合应用重用机制（其实不仅是 UIScrollView，任何场景中会反复出现的元素都应该适当地引入重用机制）。

你能够参照 UITableView 的 cell 重用机制，总结重用机制以下：

• 维护一个重用队列
• 当元素离开可见范围时，removeFromSuperview 并加入重用队列（enqueue）
• 当须要加入新的元素时，先尝试从重用队列获取可重用元素（dequeue）而且从重用队列移除
• 若是队列为空，新建元素
• 这些通常都在 scrollViewDidScroll: 方法中完成

实际使用中，须要注意的点是：

• 当重用对象为 view controller 时，记得 addChildeViewController
• 当 view 或 view controller 被重用但其对应 model 发生变化的时候，须要及时清理重用前留下的内容
• 数据能够适当作缓存，在重用的时候尝试从缓存中读取数据甚至以前的状态（如 table view 的 contentOffset），以获得更好的用户体验
• 当 on screen 的元素数量可肯定的时候，有时候能够提早 init 这些元素，不会在 scroll 过程当中遇到由于 init 开销带来的卡顿（尤为是以 view controller 为重用对象的时候）

例 2 中的场景很适合以 view 为重用单位，本例新增一个以 view controller 为重用对象的例子，该例子同时演示了联动效果，具体见下个例子。

完整代码参见 Reuse

4. 联动/视差滚动

上一个例子里 main scroll view 和 title view 里的 scroll view 就是一个联动的例子，所谓联动，就是当 A 滚动的时候，在 scrollViewDidScroll: 里根据 A 的 contentOffset 动态计算 B 的 contentOffset 并设给 B。一样对于非 scroll view 的 C，也能够动态计算 C 的 frame 或是 transform（Glow 的气泡为例）实现视差滚动或者其余高级动画，这在如今许多应用的引导页面里会被用到。

联动/视差滚动部分原理上其实比较简单，再也不赘述，写了个简单的例子 Parallax。

写在最后

不知不觉就写了不少关于 UIScrollView 的内容，其实还有不少可写，因为时间关系只好停笔。在我看来，UIScrollView 就好像提供了一个跳脱二维空间束缚的途径，若是你有足够的想象力，它能帮你实现更丰富的跳出平面束缚的用户体验。原本还准备写一个综合性的例子，可是因为时间关系还没完成，后面有时间会继续更新。

此外，例子中可能会有错误或能够改进的地方，欢迎在 GitHub 直接提 Issue