广西城乡住房建设厅网站,搞好姓氏源流网站建设,淘宝活动策划网站,毕设给学校做网站起始 做开发也有一段时间了#xff0c;经历了第一次完成项目的激动#xff0c;也经历了天天调用系统的API的枯燥#xff0c;于是就有了探索底层实现的想法。 关于scrollView的思考 在iOS开发中我们会大量用到scrollView这个控件#xff0c;我们使用的tableView/collectionv…起始 做开发也有一段时间了经历了第一次完成项目的激动也经历了天天调用系统的API的枯燥于是就有了探索底层实现的想法。 关于scrollView的思考 在iOS开发中我们会大量用到scrollView这个控件我们使用的tableView/collectionview/textView都继承自它。scrollView的频繁使用让我对它的底层实现产生了兴趣它到底是如何工作的如何实现一个scrollView读完本篇博客相信你一定也可以自己实现一个简易的scrollView。 我们首先来思考以下几个问题 scrollView继承自谁它如何检测到手指滑动 scrollView如何实现滚动 scrollView里的各种属性是如何实现的如contentSize/contentOffSet...... 通过一步步解决上边的问题我们就能实现一个自己的scrollView。 一步一步实现scrollView 1.毫无疑问我们都知道scrollView继承自UIView检测手指滑动应该是在view上放置了一个手势识别实现代码如下 1 - (instancetype)initWithFrame:(CGRect)frame {
2 self [super initWithFrame:frame];
3 if (self) {
4 UIPanGestureRecognizer *panGesture [[UIPanGestureRecognizer alloc] init];
5 [panGesture addTarget:self action:selector(panGestureAction:)];
6 [self addGestureRecognizer:panGesture];
7 }
8 return self;
9 } 2.要搞清楚第二个问题首先我们必须理解frame和bounds的概念。 提到它们大家都知道frame是相对于父视图坐标系来说自己的位置和尺寸bounds相对于自身坐标系来说的位置和尺寸并且origin一般为00。但是bounds的origin有什么用处改变它会出现什么效果呢 当我们尝试改变bounds的origin时我们就会发现视图本身没有发生变化但是它的子视图的位置却发生了变化why其实当我们改变bounds的origin的时候视图本身位置没有变化但是由于origin的值是基于自身的坐标系所以自身坐标系的位置被我们改变了。而子视图的frame正是基于父视图的坐标系当我们更改父视图bounds中origin的时候子视图的位置就发生了变化这就是实现scrollView的关键点 是不是很好理解基于这点我们很容易实现一个简单的最初级版本的scrollView代码如下 1 - (void)panGestureAction:(UIPanGestureRecognizer *)pan {2 // 记录每次滑动开始时的初始位置3 if (pan.state UIGestureRecognizerStateBegan) {4 self.startLocation self.bounds.origin;5 NSLog(%, NSStringFromCGPoint(self.startLocation));6 }7 8 // 相对于初始触摸点的偏移量9 if (pan.state UIGestureRecognizerStateChanged) {
10 CGPoint point [pan translationInView:self];
11 NSLog(%, NSStringFromCGPoint(point));
12 CGFloat newOriginalX self.startLocation.x - point.x;
13 CGFloat newOriginalY self.startLocation.y - point.y;
14
15 CGRect bounds self.bounds;
16 bounds.origin CGPointMake(newOriginalX, newOriginalY);
17 self.bounds bounds;
18 }
19 } 3.理解了上边内容的关键点下边我们将对我们实现的scrollView做一个简单的优化。 通过contentSize限制scrollView的内部空间实现代码如下 1 if (newOriginalX 0) {2 newOriginalX 0;3 } else {4 CGFloat maxMoveWidth self.contentSize.width - self.bounds.size.width;5 if (newOriginalX maxMoveWidth) {6 newOriginalX maxMoveWidth;7 }8 }9 if (newOriginalY 0) {
10 newOriginalY 0;
11 } else {
12 CGFloat maxMoveHeight self.contentSize.height - self.bounds.size.height;
13 if (newOriginalY maxMoveHeight) {
14 newOriginalY maxMoveHeight;
15 }
16 } 通过contentOffset设置scrollView的初始偏移量相信大家已经懂了如何设置偏移量了吧没错我们只需设置view自身bounds的origin是实现代码如下 1 - (void)setContentOffset:(CGPoint)contentOffset {
2 _contentOffset contentOffset;
3 CGRect newBounds self.bounds;
4 newBounds.origin contentOffset;
5 self.bounds newBounds;
6 } 防止scrollView的子视图超出scrollView 1 self.layer.masksToBounds YES; 总结 UIScrollView还有很多其它强大的功能以上我们只是完成了一个特别简单的scrollView以后如果有时间我会对它进行完善。当然如果你有兴趣你完全可以对它进行扩展,下载地址放在这里。同时我也会继续研究UIKit中其它控件的底层实现欢迎您的持续关注 文PaulLi哥简书作者原文链接http://www.jianshu.com/p/a9a1ca54ca54著作权归作者所有转载请联系作者获得授权并标注“简书作者”。 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 与屏幕尺寸相关的代码更好地支持 rotationSample 中的 AutoLayout 演示了 UIScrollView Auto Layout 的例子。 UIScrollViewDelegate UIScrollViewDelegate 是 UIScrollView 的 delegate protocolUIScrollView 有意思的功能都是通过它的 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 viewdidEndDecelerating 不会被调用并且这时 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 为 YESdecelerating 为 NOdecelerate 过程中dragging 和 decelerating 都为 YESdecelerate 未结束时开始下一次拖动dragging 和 decelerating 依然都为 YES。所以无法简单通过 table view 的 dragging 和 decelerating 判断是在用户拖动还是减速过程。 解决这个问题很简单添加一个变量如 userDragging在 willBeginDragging 中设为 YESdidEndDragging 中设为 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 } 更值得高兴的是通过判断是否 niltargetRect 同时起到了原来 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 重用机制这种重用机制减少了内存开销也提高了 performanceUIScrollView 作为 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 或是 transformGlow 的气泡为例实现视差滚动或者其他高级动画这在现在许多应用的引导页面里会被用到。 联动/视差滚动部分原理上其实比较简单不再赘述写了个简单的例子 Parallax。 写在最后 不知不觉就写了很多关于 UIScrollView 的内容其实还有很多可写由于时间关系只好停笔。在我看来UIScrollView 就好像提供了一个跳脱二维空间束缚的途径如果你有足够的想象力它能帮你实现更丰富的跳出平面束缚的用户体验。本来还准备写一个综合性的例子但是由于时间关系还没完成后面有时间会继续更新。 此外例子中可能会有错误或可以改进的地方欢迎在 GitHub 直接提 Issue 或 PR。 转自http://tech.glowing.com/cn/ 转载于:https://www.cnblogs.com/oc-bowen/p/5953194.html
