manbetx官方网站

4.IOS(swift)-scrollView(tableView) ·图片加载逻辑的优化。iOS开发-UIScrollView实践深入上。

九月 30th, 2018  |  manbetx官方网站

Table View 中图纸加载逻辑的优化

尽管如此这种优化措施以今天的功用和网环境下或类似不那么必要,但在自我最初见到这方法是的
09 年(印象中凡 Tweetie 作者在 08 年形容的 Blog,可能发误),遥想 iPhone
3G/3GS 的功力,这个点子也多图的 table view
的习性带来特别挺的升级,也成了自我之秘密武器。而现,在走网环境下,你还是值得这样做来也用户节省流量。

先说一下原稿的笔触:

  1. 当用户手动 drag table view 的早晚,会加载 cell 中的图纸;
  2. 于用户快速滑动的减速过程中,不加载过程遭到 cell
    中的图片(但言信息还是会见为加载,只是减少减速过程中的网络支出和图片加载的出);
  3. 以减速结束晚,加载所有可见 cell 的图纸(如果需要的话);

UIScrollView (包括它的子类
UITableView和UICollectionView)是iOS开发被最好有扩展性的UI控件。UIScrollView
是 UIKit 中为数不多能响应滑动手势的
view,相比自己用UIPanGestureRecognizer 实现部分根据滑动手势的作用,用
UIScrollView 的优势在于 bounce 和 decelerate 等风味可为 App
的用户体验以及 iOS 系统的用户体验保持一致。本文通过有些实例讲解
UIScrollView 的性状与骨子里用着之涉。

问题 1:

前方提到,刚开拖动的早晚,dragging
为true,decelerating为false;decelerate过程中,dragging和decelerating都为true;decelerate
未终止时开下同样糟糕拖动,dragging和decelerating依然还也true。所以无法简单通过table
view的dragging和decelerating判断是在用户拖动还是减速过程。

缓解者问题十分简单,添加一个变量如userDragging,在
willBeginDragging中一经为true,didEndDragging中一经为false。那么tableView:
cellForRowAtIndexPath: 方法被,是否load 图片的逻辑就是是:

if (!self.userDragging && tableView.decelerating) {
     cell.pictureView.image = nil;
     println("拖动中和减速中,不显示图片")
} else {
     // code for loading image from network or disk
     println("拖动和减速结束,显示图片")
}

UIScrollView 和 Auto Layout

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

问题 2:

这般做的话,decelerate结束后,屏幕上之 cell
都是匪带图片的,解决此问题吧未麻烦,你要一个形如loadImageForVisibleCells的方,加载可见cell的图样:

func loadImageForVisibleCells(){
        var cells:NSArray = self.tableView.visibleCells()
        for cell in cells {
            var indexPath:NSIndexPath = self.tableView.indexPathForCell(cell as! UITableViewCell)!
            self.setupCell(cell as! TableViewCell, widthIndexPath: indexPath)
        }
}

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
属性判断是于用户拖拽还是放慢过程遭到之口舌或会见误判。

问题 3:

以此题目可能无轻给发觉,在减速过程遭到若用户开始新的拖动,当前屏幕的cell并无会见受加载(前文提到的调用顺序问题造成),而且题目
1 的方案并无克化解问题 3,因为这些 cell 已经以屏上,不见面再也通过
cellForRowAtIndexPath 方法。虽然非爱察觉,但解决好粗略,只需要在
scrollViewWillBeginDragging: 方法里啊调动用平等涂鸦 loadImageForVisibleCells
即可。

实例

脚通过一些实例,更详细地示范和描述以上各级 delegate 方法的用。

  1. Table View 中图纸加载逻辑的优化
    虽这种优化措施以如今的效果和网络环境下或接近不那么必要,但以自最初见到此措施是的
    09 年(印象中凡 Tweetie 作者在 08 年描绘的 Blog,可能来误),遥想
    iPhone 3G/3GS 的机能,这个法子为多图的 table view
    的性带来大死之升级换代,也改为了自之秘密武器。而现在,在活动网环境下,你依旧值得这样做来为用户节省流量。

优先说一下原稿的思路:

当用户手动 drag table view 的上,会加载 cell 中的图片;
于用户迅速滑动的减速过程被,不加载过程被 cell
中之图片(但言信息还是碰头让加载,只是减少减速过程被之大网支付和图加载的开支);
当减速结束晚,加载所有可见 cell 的图片(如果需要的话);

再优化

上述方式以挺年代的确提升了table
view的performance,但是若晤面发现以减速过程最后极缓慢的那零点几秒时,其实还是会被丁齐得有点焦急,尤其要你的
App 只发生图并未文字。在 iOS 5 引入了 scrollViewWillEndDragging:
withVelocity: targetContentOffset: 方法后,配合
SDWebImage,我尝试再度优化了一下这法子为提升用户体验:

  1. 要内存中生出图的缓存,减速过程中呢会见加载该图片
  2. 倘图片属于 targetContentOffset 能看出的
    cell,正常加载,这样一来,快速轮转的终极一屏出去的的经过中,用户就可知顾目标区域的图纸逐渐加载
  3. 若得尝试用类似 fade in 或者 flip
    的法力缓解生硬的黑马出现(尤其是如本例这样单发图表的 App)

中心代码:

func scrollViewWillBeginDragging(scrollView: UIScrollView) {
        self.userDragging = true
        self.targetRect = nil;
        self.loadImageForVisibleCells()
}

func scrollViewWillEndDragging(scrollView: UIScrollView, withVelocity velocity: CGPoint, targetContentOffset: UnsafeMutablePointer<CGPoint>) {

        var targetRect:CGRect = CGRectMake(targetContentOffset.memory.x, targetContentOffset.memory.y, scrollView.frame.size.width, scrollView.frame.size.height)
         self.targetRect = NSValue(CGRect: targetRect)
}

func scrollViewDidEndDecelerating(scrollView: UIScrollView) {
        println("结束减速")
        self.targetRect = nil;
        self.loadImageForVisibleCells()
}

是否需要加载图片的逻辑:

var shouldLoadImage:Bool = true
//判断是否重叠
if(self.targetRect != nil  && CGRectIntersectsRect(self.targetRect!.CGRectValue(), cellFrame)){
 //判断是否有缓存,加载缓存
   var manager:SDWebImageManager=SDWebImageManager.sharedManager()
   var cache:SDImageCache = manager.imageCache
   var key:String = manager.cacheKeyForURL(targetURL)
     if((cache.imageFromMemoryCacheForKey(key)) != nil){
                            shouldLoadImage = false
      }
}               
//如果没有缓存,缓存图片
if(shouldLoadImage){
}

复值得高兴的凡,通过判断是否 nil,targetRect 同时从及了原本 userDragging
的用意。

Paste_Image.png

问题 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
的企图。

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
的办法)。

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
为用对象的例子,该例子同时演示了联动效应,具体表现下单例。

4. 联动/视差滚动

达一个例证里 main scroll view 和 title view 里的 scroll view
就是一个联动的例子,所谓联动,就是当 A 滚动的时候,在
scrollViewDidScroll: 里根据 A 的 contentOffset 动态计算 B 的
contentOffset 并要为 B。同样于非 scroll view 的 C,也可动态计算 C 的
frame 或是 transform(Glow
的血泡为例)实现视差滚动或者其他高级动画,这当今天无数下的导页面里会给用到。

UIScrollView代码

标签:, ,

Your Comments

近期评论

    功能


    网站地图xml地图