diwu / runloopworkdistribution

iOS Fast Scrolling with RunLoop Work Distribution

iOS Fast Scrolling with RunLoop Work Distribution

• Go to work when UI thread gets idle. Step aside when UI thread gets busy.
• If deployed properly, it could:
  • Delay heavy tasks on the UI thread as late as possible.
  • Preload heavy tasks as soon as the UI thread enters its idling mode.
  • Allow you to distribute a heavy task as multiple smaller tasks, thus less blocking when UI thread suddenly gets busy again.
• 100% thread safe. Always runs on the UI thread.

What is A RunLoop?

RunLoop is a while(YES){...} loop that lives within your app's UI thread. It handles all kinds of events when your app is busy, while sleeps like a baby when there's nothing to do, until the next event wakes it up.

Not All RunLoop Passes are Created Equal

A RunLoop repeats itself as individual passes. However, not all passes are created equal. High priority passes take over when your app is tracking finger movements, while low priority passes begin to run when scrolling comes to an end and the metal has spare time to work on low priority tasks such as processing networking data.

Because the high priority passes are often filled with critical time sensitive tasks. We don't want to interfere with that. So here in this project we are only working in those low priority passes. Focusing on a single type of passes also gives us one huge advantage: all tasks we submit to this type of passes are guaranteed to run on a first-in-first-out sequential basis.

Why not Simply Multi-threading?

Too many times when we are optimizing cell drawing code in our cellForRow: method, we find ourselves buried under a bunch of UIKit APIs that are in no way thread safe. Even worse, some of them could easily block the main thread for one or more precious milliseconds. As facebook AsyncDisplayKit teaches us, "Your code usually has less than ten milliseconds to run before it causes a frame drop". Oops.

Why Distributing the Work Load?

So here we are executing low priority tasks on the UI thread while the UI thread is free and is about to sleep, so why not dumping those tasks all at once. The UI thread is not busy at that specific moment anyway.

Here's why: The next RunLoop pass, be it high or low priority, will never start unless the previous one hits the finishing line. As a result, if we dump too much work into the current low priority pass, and suddenly the high priority pass needs to take over (for example, touch events detected), the high priority pass will have to wait for the low priority task to finish before any touch events could be served. And that's when you notice the glitches.

If instead we slice our one big low priority task into smaller pieces, things would look much much different. Whenever high priority passes need to take over, they won't wait for long because every low priority task is now smaller and will be finished in no time. Hence the "Step aside when UI thread gets busy."

Example

Along with the source code there's an contrived example illustrating the technique. In the example there's a heavy task that loads and draws 3 big JPG files into the cell's contentView whenever a new cell goes onto the screen. If we follow the convention and load and draw the images right inside the cellForRow: callback, glitches will ensue, since loading and drawing each image takes quite some time even in a simulator.

So instead of doing it the old way, we slice our big task into 3 smaller ones, each loading and drawing 1 image. Then we submit the 3 tasks into the low priority tasks queue with the help of DWURunLoopWorkDistribution. Running the example, we can see that glitches are much less frequent now. Besides, instead of loading and drawing images for every indexPath that comes and goes during scrolling, only certain indexPaths now get to do the work, making the whole scrolling process more efficient.

Installation

Simply copy and paste DWURunLoopWorkDistribution.{h,m} into your project. Or, if you prefer, add the following line into your Podfile.

pod 'DWURunLoopWorkDistribution'

Usage

You can submit tasks by calling addTask:withKey:. In the case of cellForRow:, the key will be the NSIndexPath instance of that specific cell.

Since cells are regularly reused within a given tableView, be sure to set the currentIndexPath property of your cell and check its value against the indexPath captured by the task block to make sure you are not executing a task that should be abandoned. Cannot find the currentIndexPath property anywhere in the document? No worry, it's not there because it's not from Apple. It's a dynamic property injected into every UITableViewCell instance during runtime by DWURunLoopWorkDistribution.

runloopworkdistribution's Issues

首页不滑动在iOS 11下不展示图片,请问这个怎么解决

使用kCFRunLoopCommonModes是否会有更好的效果？

使用kCFRunLoopCommonModes替代kCFRunLoopDefaultMode是不是会更好些呢，这样在滚动的时候也能进行加载。还是说有其他我没想到的问题？

xcode8.3.3编译错误

占用内存太大了

占用内存太大了。
就一个页面，500多M

请求大神答复一个疑问

为什么我认为，这个不是每次RunLoop结束前执行一次任务，而且在一次RunLoop结束的前下执行了所有在tasks中的任务？
如果只执行一次的话，那么RunLoop休眠，页面保持静止，应该只加载一张图的啊。

while (result == NO && runLoopWorkDistribution.tasks.count) {
    DWURunLoopWorkDistributionUnit unit  = runLoopWorkDistribution.tasks.firstObject;
    result = unit();
    [runLoopWorkDistribution.tasks removeObjectAtIndex:0];
    [runLoopWorkDistribution.tasksKeys removeObjectAtIndex:0];
}

这个不是一次执行完的吗？

过来给你点个赞

点个赞

改造成uicollection view使用加载图片会出现跳动

我将这个Demo转换成给collectionview 使用，然后从网络上下载图片，发现在上下滚动collectionview的过程中，原本在item = 1位置的图片，变到item = 2的位置，item = 2 的图片变到item = 1 的位置，也就是两个图片互相交换了位置，然后再滑动collectionview的时候又互相交换位置了，一直滚动就一直重复出现这个问题。

视觉效果体验问题

我想问一下：对于这种优化，我们可以看到在tracking模式下，cell上面一片空白（或者你放一个比较小的背景占位图），但是当滑动停止，处于default模式了，这个时候渲染图片了，你会发现之前的空白（或占位图）会被填充，感觉视觉上的效果蛮差的。例如我们希望可以获得微信朋友圈或微博那样的体验，有没有更好的优化方案呢？我们抛开高度缓存这些角度，其他角度怎么优化呢？

快速上下滑动的时候容易出现复用的情况，还有部分图片没办法加载出来，我的max已经设置成50了

图片不显示

如果已进入页面不滑动页面就不会显示图片，

将 NSTimer 改成 [NSMachPort port] 是否更好

@implementation DWURunLoopWorkDistribution
- (instancetype)init
{
    if ((self = [super init])) {
        _maximumQueueLength = 30;
        _tasks = [NSMutableArray array];
        _tasksKeys = [NSMutableArray array];
//        _timer = [NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@selector(_timerFiredMethod:) userInfo:nil repeats:YES];
         // 如果不加延迟会导致启动黑屏,  可能是由于启动 App 时, 无法正常 Mode 切换的原因;
        dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.01 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
            NSRunLoop* runLoop = [NSRunLoop currentRunLoop];
            [runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];
            [runLoop run];
        });

    }
    return self;
}