前言
UIScrollView
的分页方式实际上已经是老生常谈。一行自信的scrollView.pagingEnabled = YES
就搞定需求也不是一两次了。然而最近在开发一个如下的需求时发现,在分页尺寸小于scrollView.bounds.size
时,事情似乎并不是那么简单。
需要开发的页面类似下图。开发过程中遇到了什么问题,最终采用了什么解决方案,详见下文。
一开始拿到需求,想都不想,一行scrollView.pagingEnabled = YES
就写下去了。也就是下文所说的方式1.
分页方案1 - 系统实现
设置UIScrollView
及其子类的scrollView.pagingEnabled = YES
, 即可实现UIScrollView
的自带分页效果,默认的分页尺寸就是scrollView.bounds.size
。非常好用,非常方便,安卓同学看了会哭泣。
只是需求中要求的分页尺寸小于scrollView.bounds.size
,于是。。
分页方案1扑街~
转而尝试分页方式2,描述如下:
分页方案2 - 利用额外显示区域
google一搜全都是这种方案。
这是个取巧的方案,大致的思路是设置scrollView.clipsToBound = NO
允许展示滚动内容超出scrollView.frame
以外的部分。然后通过一个view容器来显示这部分额外显示区域的大小。伪代码如下:
UIEdgeInsets insets;// 额外展示区域的尺寸
// 用一个容器view包裹scrollView
UIView *container = UIView.new;
[container addSubview:scrollView];
// 设置scrollView和容器view的insets,决定前一个或者后一个页面的可见区域
[scrollView mas_makeConstraints:^(MASConstraintMaker *make) {
make.edges.equalTo(container).insets(insets);
}];
// 设置使用默认分页效果
scrollView.pagingEnabled = YES;
// 让scrollView的超出试图的部分也显示出来
scrollView.clipsToBounds = NO;
实现非常简单,在额外显示区域不大的时候不太影响操作,显示区域大的话也可以通过在container
中实现hitTest:withEvent:
方法来处理,是一个可行的解决方案。
但这个方案的局限性在于,如果承载内容的scrollView
是UITableView
或者UICollectionView
这类具有视图复用机制的子类,那么额外显示区域的UITableViewCell
或者UICollectionViewCell
是会被回收复用的。
然而,我用来实现需求的正是UICollectionView
,尴尬😅
分页方案2扑街~
转而投奔分页方案3
分页方案3 - 自立更生方案
经过大(反)量(复)调(折)试(腾),终于寻找到了合适的分页计算方发,最终产出如下方案:
- 先设置三个属性记录状态
// 单页宽度
@property (assign, nonatomic, readonly) CGFloat pageWidth;
// 手势开始时的起始页数
@property (assign, nonatomic) NSInteger pageOnBeginDragging;
// 手势开始时scrollView的contentOffset.X
@property (assign, nonatomic) CGFloat offsetXOnBeginDragging;
- 判断当前页数,更新UI分页信息
- (void)scrollViewDidScroll:(UIScrollView *)scrollView {
CGFloat offsetX = scrollView.contentOffset.x;
int i = (offsetX + self.pageWidth*0.5)/self.pageWidth;
self.indicator.currentPage = i;
}
- 重点!判断用户手势,决定手势结束后的最终页面
// 用户拖拽开始时记录状态,包括起始页数 & scrollView的contentOffset.X
- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView {
self.pageOnBeginDragging = self.indicator.currentPage;
self.offsetXOnBeginDragging = scrollView.contentOffset.x;
}
/*
这个代理方法在用户拖拽即将结束时被调用,velocity代表结束时scrollView滚动的速度
velocity > 0代表正在往contentOffset值增加的方向滚动,
velocity < 0滚动方向相反
targetContentOffset参数有inout修饰,可以通过修改改值决定最终scrollView滚动到的位置,一看就是用来判断/实现翻页的完美方法 :D
*/
- (void)scrollViewWillEndDragging:(UIScrollView *)scrollView withVelocity:(CGPoint)velocity targetContentOffset:(inout CGPoint *)targetContentOffset {
CGFloat targetX = (*targetContentOffset).x;
NSInteger targetPage = self.pageOnBeginDragging;
// 综合考虑velocity和targetContentOffset这两方面因素决定targetpage
if (velocity.x == 0) {
targetPage = (targetX + self.pageWidth*0.5)/self.pageWidth;
} else {
NSInteger vote = 0;
vote = velocity.x>0 ? vote+1:vote-1;
vote = (scrollView.contentOffset.x-self.offsetXOnBeginDragging >0)? vote+1:vote-1;
if (vote>0 && (targetPage+1<self.indicator.numberOfPages)) {
targetPage++;
}
if (vote<0 && targetPage-1>=0) {
targetPage--;
}
}
// 根据民主投票决定的targetPage计算最终的targetContentOffset,设置targetContentOffset
CGPoint offset = CGPointMake(self.pageWidth*targetPage, 0);
*targetContentOffset = offset;
}
结论
以上三个方案都是可行的方案,适用于不同的场景。系统方案最简单,适用范围最小。自定义翻页的方案稍显复杂,但是适用范围最广。后续考虑把相关逻辑封装到UIScrollView的category中,方便复用。