原文地址 eleme 移动组博客
饿了么在5.8版本的时候对餐厅页做了很大的改动, 在视觉和交互上都带来了很不错的效果. 为了实现这种效果, 我们内部的PhilCai同学用UIPanGestureRecognizer和UIKit Dynamics模拟了系统的UIScrollView, 包括惯性滚动, 弹性, 橡皮筋(RubberBanding)效果.
首先说明一下视图的结构:
<ParentViewController.View>
| <Container> //UIView
| | <SegmentView>
| | <ScrollView> //仅左右滑动(pagingEnabled)
| | | <ChildViewController1.View>
| | | | <CategoryListView>
| | | | <FoodListView>
| | | <ChildViewController2.View>
| | | | <RatingListView>
| | | <ChildViewController3.View>
| | | | <SummaryListView>
ParentViewController就是从首页Push进入的ViewController, 在它的View上放置了一个Container(一个普通的UIView), Container的上方是SegmentView,下方是一个左右滑动的ScrollView; 在ScrollView上, 从左往右放置了三个ViewController的View; 所有的tableView视图的bounce都禁用.
和竞品一样，我们都是在一个UIScrollView上面嵌套一个UITableView作为子视图，但是他们的方案都有一种问题：只在contentOffset变化时就立即把scrollView移动到了头部，带来了非常明显的“不跟手”的交互体验。
而我们的交互是：FoodListView 在 Container 向上推动的时候不滑动，只有 Container 到顶部 Fix住 FoodListView 才开始滑动。假如基于这种简单的 contentOffSet 来做，会有几个问题：
- FoodListView 在被向上推的时候不滑动，需要禁用手势。
- Container 在 Fix 的时候需要把 FoodListView 手势启用。
- 但是这时候 FoodListView会停住，因为它没有被滑动过，需要抬手再次去滑动
考虑到这个效果订制程度很高,我们自己实现了一套UIScrollView的滑动效果。
[Container mas_makeConstraints:^(MASConstraintMaker *make) {
make.left.right.bottom.equalTo(ParentViewController.View);
make.top.equalTo(ParentViewController.View).offset(topOffset);
}];
Container的left, right, bottom都对应ParentViewController.View的left,right,bottom, 我们只需要修改topOffset对应的约束, 就可以做出如下的效果:
接下来关闭所有scrollView的手势（包括tableView），然后在Container上加上自己的PanGestureRecognizer. 这样之后只要是和上下滚动相关的交互(tableView的滚动和Container的top的约束)都由自己实现的PanGestureRecognizer完成.
这么做有两点优势：
- 当在上下滑动的时候PanGestureRecognizer一定会触发, 并且在滑动的时候, 可以精确的控制当前手势的位移是修改Container的顶部约束还是修改当前页面的tableView的contentOffset;
- 在手势结束的时候, 可以获取最后手势的速度
-[UIPanGestureRecognizer velocityInView:]这方便了之后模拟惯性效果.
在模拟ScrollView的三个特性里面, 最简单的是RubberBanding(橡皮筋效果), 惯性滚动和弹性原理是类似的.
RubberBanding
因为只启用了自定义的pan手势, 在普通情况下, 要修改tableView的contentOffset 或者修改Container的顶部约束, 只需要在pan.state == UIGestureRecognizerStateChanged, 根据[pan translationInView: Container].y获取垂直方向的手势位移, 修改contentOffset或者约束的变化等于手势位移. 至于RubberBanding, 在垂直方向上有两种可能: Container距离顶部超过某个预设的值, 手势继续向下拖动; 或者tableView的拉到底部之后手势继续向上. 这个时候修改contentOffset或者顶部约束的变化小于手势位移(比如乘以一个小于1的因数), 就可以模仿出RubberBanding效果.
惯性 & 弹性
这里说的惯性效果不仅包括模仿tableView自身的惯性减速修改contentOffset.
还包括:
- 在手势结束之后, Container根据惯性的效果动态改变它的顶部约束.
- Container按照惯性效果到顶部后(top约束减小, Container向上移动), 惯性效果没有消失, 继续驱动tableView的
contentOffset修改. (速度传递) - tableView按照惯性减小
contentOffset.y到0后, 惯性效果继续驱动Container修改顶部约束. (速度传递)
同样, 弹性效果也不只是tableView到达超过底部之后放手回弹, 也包括Container距离顶部超过一定距离之后放手回弹效果, 以及可能因为速度传递后导致的回弹.
先简单的考虑只在手势结束后发生的惯性和弹性, 很幸运的是可以获取手势最后一刻的速度[pan velocityInView:Container].y. 第一反应是使用UIView的springAnimation, 因为它接受传入速度. 但是其他参数比如duration, 其实没有太好的方案去指定, 如果加上速度传递的效果, 它就更无能为力了. 反复滑动系统的ScrollView, 在调用栈发现它是由CADisplayLink驱动的, 发现它的行为和UIKit Dynamics的动画很符合, 而且UIKit Dynamics背后也是CADisplayLink,加上UIDynamicBehavior有个action属性:
When running, the dynamic animator calls the action block on every animation step.
在每一帧动画的时候都会调用下. 这些组合起来, 足够去模拟ScrollView的各种行为了.
一般我们使用UIKit Dynamics的时候, 我们是把各种Behaviour直接添加到UIView上, 然后视图就会在它到作用下动起来. 但在现在的情况下, 并不能够直接对视图添加Behaviour. 由于Behaviour实际是对遵循UIDynamicItem协议的对象做物理动画, 所以可以把contentOffset或者顶部约束的值做一层抽象.
@interface DynamicItem : NSObject<UIDynamicItem>
@property (nonatomic, readwrite) CGPoint center;
@property (nonatomic, readonly) CGRect bounds;
@property (nonatomic, readwrite) CGAffineTransform transform;
@end
@implementation DynamicItem
- (instancetype)init {
if (self = [super init]) {
_bounds = CGRectMake(0, 0, 1, 1);
}
return self;
}
@end
DynamicItem的实例可以看作是一个质点, 在垂直方向上, 它的位置(center)可以用来代表Container的位置(top), 也可以用来代表tableView的contentOffset.y, 它的transform属性可以不用考虑.
无论是修改Container的位置还是tableView的contentOffset, 在惯性或弹性效果的情况下, 只要在action中将约束的值或者contentOffset.y设置为DynamicItem的center.y就可以. UIKit Dynamics自己会在每一帧去修改.
比如惯性效果下修改Container的顶部约束大概是这样的:
// when pan.state == UIGestureRecognizerStateEnded
NVMDynamicItem *item = [NVMDynamicItem new];
// topOffset表示当前Container距离顶部的距离
item.center = CGPointMake(0, topOffset);
// velocity是在手势结束的时候获取的竖直方向的手势速度
UIDynamicItemBehavior *inertialBehavior = [[UIDynamicItemBehavior alloc] initWithItems:@[ item ]];
[inertialBehavior addLinearVelocity:CGPointMake(0, velocity) forItem:item];
// 通过尝试取2.0比较像系统的效果
inertialBehavior.resistance = 2.0;
inertialBehavior.action = ^{
CGFloat itemTop = item.center.y;
[Container mas_updateConstraints:^(MASConstraintMaker *make) {
make.top.equalTo(ParentViewController.View).offset(itemTop);
}];
};
[self.animator addBehavior:inertialBehavior];
类似的弹性效果只需使用UIAttachmentBehavior并且设置合适的值, 尝试下来length = 0, damping = 1, frequency = 1.6, 就有不错的回弹效果.
修改contentOffset也是类似, 只不过是将在action中修改约束的部分改为修改contentOffset.
对于速度传递, 完全一样的原理, 唯一的变化就是从获取手势的速度变为获取-[UIDynamicItemBehavior linearVelocityForItem]的线速度, 然后UIDynamicAnimator移除不需要的动画, 按照上面的例子传入速度再次做惯性动画.
甚至还可以把UIAttachmentBehavior和UIDynamicItemBehavior同时使用, 模仿有初速度的回弹效果.
大致的思路就是这样, 只需要注意什么时候调用-[UIDynamicAnimator removeBehavior]停止动画(比如手势刚开始的时候), 以及action中注意retain cycle.
有个2014年的博客已经有了类似的例子, 只是交互简单一些, 原理是一样的.
而在运用自己的手势去实现ScrollView之后, 碰到了一些细节问题.
- 自己加到Container上的手势, 很容易误触发tableView的
-tableView:didSelectRowAtIndexPath:indexPath协议方法, 导致很容易Push到下一个页面, 很影响使用. 解决的原理比较简单, 在合适的时机将当前的tableView.userInteractionEnabled设置为NO, 之后在需要的时候恢复. 正好UIDynamicAnimatorDelegate提供了动画将要开始dynamicAnimatorWillResume:和暂停(包括移除bahaviour)dynamicAnimatorDidPause:的回调. 就在这两个地方分别设置, 效果还可以接受. - 当tableView在UIKit Dynamics的作用下滚动时, 或者是快速上下滑动的时候, 很容易触发左右滑动的ScrollView切换页面. 解决方案比较tricky: 自定义了UIScrollView的子类, 在子类中将gestureRecognizerShouldBegin:重写, 对于panGestureRecognizer的情况, 在它的水平速度和垂直速度的夹角在一定范围内强制返回NO. 这样就大大减小了误触发左右滚动的操作. 但是还是希望有更好的解决方案.
- 还有一个很常见的问题, 点击状态栏, 正常情况下系统能够将ScrollView滚动到顶部, 而在一个Window中有多个ScrollView的时候, 它是不一定成功的. 正确的解决方案应该是将当前页面需要响应系统statusBar点击的ScrollView的
scrollsToTop设置为YES, 其他都设置为NO, 并且scrollsToTop为YES的只能有一个, 这种情况下理论上是可以work的. 但是在解决第一个问题的时候, 导致了这种解决方法有时候不成功. 因为发现在一个UIScrollView的userInteractionEnabled == NO的时候, 状态栏点击返回顶部效果是无效的(比如正在惯性滚动的时候, 状态还是NO, 这个时候点击statusBar); 加上在最左边的页面有两个tableView需要同时滚动到顶部. 只能换个解决方案. 子类化了全局的UIWindow, 重写它的-pointInside:withEvent:, 在statusBar区域被点击的时候发出通知, 监听到后手动设置contentOffset到0. - 由于之前很多控件是AutoLayout写的, 比如cell, 因为现在实现的方案会频繁修改约束, 导致滑动很卡(之前在iPhone 6就感受到卡顿了). 之后用手动布局改了一部分cell, 确实流畅了很多.
虽然UIKit Dynamics平时很少用到, 不过在关键时刻也发挥了巨大的作用, 很好奇Apple在实现UIScrollView会不会也用到了它.
- EOF -
