有没有办法让drawRect立即工作？

Question

如果您是drawRect的高级用户，您就会知道drawRect当然不会真正运行，直到“所有处理完成”。

setNeedsDisplay 将视图和操作系统标记为无效，并基本上等待所有处理完成。在您希望拥有的常见情况下，这可能会令人恼火：

• 视图控制器 1
• 启动某个功能 2
• ，该功能逐渐增加 3
  • 创作出越来越复杂的艺术作品并且 4
  • 在每一步中，您都设置了NeedsDisplay（错误！）5
• 直到完成所有工作 6

当然，当您执行上面的 1-6 时，所发生的只是运行了drawRect 第 6 步后仅一次。

您的目标是在第 5 点刷新视图。该怎么办？

Answer 1

如果我正确理解你的问题，有一个简单的解决方案。在长时间运行的例程中，您需要告诉当前运行循环在您自己的处理中的某些点处理单次迭代（或多次运行循环）。例如，当您想要更新显示时。当您运行 runloop 时，任何具有脏更新区域的视图都将调用其 drawRect: 方法。

告诉当前的运行循环处理一次迭代（然后返回给您...）：

[[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate: [NSDate date]];

这是一个（低效）长时间运行例程的示例，具有相应的绘制矩形 - 每个例程都在自定义 UIView 的上下文中：

- (void) longRunningRoutine:(id)sender
{
    srand( time( NULL ) );

    CGFloat x = 0;
    CGFloat y = 0;

    [_path moveToPoint: CGPointMake(0, 0)];

    for ( int j = 0 ; j < 1000 ; j++ )
    {
        x = 0;
        y = (CGFloat)(rand() % (int)self.bounds.size.height);

        [_path addLineToPoint: CGPointMake( x, y)];

        y = 0;
        x = (CGFloat)(rand() % (int)self.bounds.size.width);

        [_path addLineToPoint: CGPointMake( x, y)];

        x = self.bounds.size.width;
        y = (CGFloat)(rand() % (int)self.bounds.size.height);

        [_path addLineToPoint: CGPointMake( x, y)];

        y = self.bounds.size.height;
        x = (CGFloat)(rand() % (int)self.bounds.size.width);

        [_path addLineToPoint: CGPointMake( x, y)];

        [self setNeedsDisplay];
        [[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate: [NSDate date]];
    }

    [_path removeAllPoints];
}

- (void) drawRect:(CGRect)rect
{
    CGContextRef ctx = UIGraphicsGetCurrentContext();

    CGContextSetFillColorWithColor( ctx, [UIColor blueColor].CGColor );

    CGContextFillRect( ctx,  rect);

    CGContextSetStrokeColorWithColor( ctx, [UIColor whiteColor].CGColor );

    [_path stroke];
}

这里是演示此技术的完整工作示例。

通过一些调整，您可能可以调整它以使 UI 的其余部分（即用户输入）也能响应。

更新（使用此技术的警告）

我只是想说，我同意这里其他人的大部分反馈，说这个解决方案（调用 runMode: 强制调用drawRect:）不一定是一个好主意。我已经回答了这个问题，我认为这是对所陈述问题的事实“这就是如何”的答案，并且我并不打算将其宣传为“正确”的架构。另外，我并不是说可能没有其他（更好？）的方法来达到相同的效果 - 当然可能还有其他我不知道的方法。

更新（对 Joe 的示例代码和性能问题的回应）

您看到的性能下降是在绘图代码的每次迭代上运行运行循环的开销，其中包括将图层渲染到屏幕上以及运行循环执行的所有其他处理，例如输入收集和处理。

一种选择可能是降低调用运行循环的频率。

另一种选择可能是优化您的绘图代码。就目前情况而言（我不知道这是否是您的实际应用程序，或者只是您的示例......）您可以采取一些措施来使其更快。我要做的第一件事是将所有 UIGraphicsGet/Save/Restore 代码移到循环之外。

然而，从架构的角度来看，我强烈建议考虑这里提到的一些其他方法。我认为没有理由不能将绘图构造为在后台线程上进行（算法不变），并使用计时器或其他机制向主线程发出信号，以某种频率更新其 UI，直到绘图完成。我认为大多数参与讨论的人都会同意这将是“正确”的方法。

Answer 2

用户界面的更新发生在当前运行循环结束时。这些更新是在主线程上执行的，因此任何在主线程中运行很长时间的内容（冗长的计算等）都会阻止界面更新的启动。此外，任何在主线程上运行一段时间的内容也会导致触摸处理无响应。

这意味着无法从主线程上运行的进程中的其他点“强制”进行 UI 刷新。 正如 Tom 的回答所示，前面的陈述并不完全正确。您可以允许运行循环在主线程上执行的操作中间完成。但是，这仍然可能会降低应用程序的响应能力。

一般来说，建议您将需要一段时间才能执行的任何操作移至后台线程，以便用户界面可以保持响应。但是，您希望对 UI 执行的任何更新都需要在主线程上完成。

也许在 Snow Leopard 和 iOS 4.0+ 下执行此操作的最简单方法是使用块，如以下基本示例所示：

dispatch_queue_t main_queue = dispatch_get_main_queue();
dispatch_async(queue, ^{
    // Do some work
    dispatch_async(main_queue, ^{
        // Update the UI
    });
});

上面的 Do some work 部分可能是一个冗长的计算或操作循环多个值。在此示例中，UI 仅在操作结束时更新，但如果您希望在 UI 中持续跟踪进度，则可以将调度放置到主队列中需要执行 UI 更新的位置。

对于较旧的操作系统版本，您可以手动或通过 NSOperation 中断后台线程。对于手动后台线程，您可以使用

[NSThread detachNewThreadSelector:@selector(doWork) toTarget:self withObject:nil];

或

[self performSelectorInBackground:@selector(doWork) withObject:nil];

然后更新您可以使用的 UI

[self performSelectorOnMainThread:@selector(updateProgress) withObject:nil waitUntilDone:NO];

请注意，我发现在处理连续进度条时需要在上一个方法中使用 NO 参数来获取不断的 UI 更新。

这个示例应用程序我为我的班级创建了如何使用 NSOperations 和用于执行后台工作并在完成后更新 UI 的队列。此外，我的 Molecules 应用程序使用后台线程来处理新结构，状态栏会随着进展而更新。你可以下载源代码来看看我是如何实现这一点的。

Answer 3

您可以在循环中重复执行此操作，它会正常工作，没有线程，不会扰乱运行循环等。

[CATransaction begin];
// modify view or views
[view setNeedsDisplay];
[CATransaction commit];

如果在循环之前已经存在隐式事务，则需要在之前使用 [CATransaction commit] 提交该事务这会起作用。

Answer 4

为了让drawRect尽快被调用（这不一定是立即的，因为操作系统可能仍然要等到下一次硬件显示刷新等），应用程序应该尽快空闲它的UI运行循环，通过退出 UI 线程中的任何和所有方法，并且持续非零时间。

您可以在主线程中执行此操作，方法是将任何花费超过动画帧时间的处理切成更短的块，并仅在短暂的延迟后安排继续工作（因此drawRect可能会在间隙中运行），或者通过在后台线程，定期调用 PerformSelectorOnMainThread 以某个合理的动画帧速率执行 setNeedsDisplay。

立即更新显示的非 OpenGL 方法（这意味着在下一次或三次硬件显示刷新时）是将可见的 CALayer 内容与您绘制的图像或 CGBitmap 交换。应用程序几乎可以随时将 Quartz 绘制到 Core Graphics 位图中。

新添加的答案：

请参阅下面 Brad Larson 的评论和 Christopher Lloyd 对此处另一个答案的评论，作为实现此解决方案的提示。

[ CATransaction flush ];

会导致在已完成 setNeedsDisplay 请求的视图上调用 drawRect，即使刷新是从阻塞 UI 运行循环的方法内部完成的。

请注意，当阻塞 UI 线程时，还需要刷新 Core Animation 来更新更改的 CALayer 内容。因此，为了用动画图形内容来显示进度，这些最终可能都是同一事物的形式。

上面新添加的答案的新添加注释：

刷新速度不要超过您的drawRect或动画绘制可以完成的速度，因为这可能会使刷新排队，导致奇怪的动画效果。

Answer 5

无需质疑这样做是否明智（您应该这样做），您可以这样做：

[myView setNeedsDisplay];
[[myView layer] displayIfNeeded];

-setNeedsDisplay 将把视图标记为需要重绘。
-displayIfNeeded 将强制视图的支持层重绘，但前提是它已被标记为需要显示。

然而，我要强调的是，您的问题表明了可以进行一些重新设计的架构。除了极少数情况外，您应该永远不需要或不想强制视图立即重绘。 UIKit 并没有考虑到这个用例，如果它有效，那你就很幸运了。

Answer 6

您是否尝试过在辅助线程上进行繁重的处理并回调主线程来安排视图更新？ NSOperationQueue 让这种事情变得非常简单。

---

示例代码采用 NSURL 数组作为输入并异步下载所有这些内容，并在每个内容完成并保存时通知主线程。

- (void)fetchImageWithURLs:(NSArray *)urlArray {
    [self.retriveAvatarQueue cancelAllOperations];
    self.retriveAvatarQueue = nil;

    NSOperationQueue *opQueue = [[NSOperationQueue alloc] init];

    for (NSUInteger i=0; i<[urlArray count]; i++) {
        NSURL *url = [urlArray objectAtIndex:i];

        NSInvocation *inv = [NSInvocation invocationWithMethodSignature:[self methodSignatureForSelector:@selector(cacheImageWithIndex:andURL:)]];
        [inv setTarget:self];
        [inv setSelector:@selector(cacheImageWithIndex:andURL:)];
        [inv setArgument:&i atIndex:2];
        [inv setArgument:&url atIndex:3];

        NSInvocationOperation *invOp = [[NSInvocationOperation alloc] initWithInvocation:inv];
        [opQueue addOperation:invOp];
        [invOp release];
    }

    self.retriveAvatarQueue = opQueue;
    [opQueue release];
}

- (void)cacheImageWithIndex:(NSUInteger)index andURL:(NSURL *)url {
    NSData *imageData = [NSData dataWithContentsOfURL:url];

    NSFileManager *fileManager = [NSFileManager defaultManager];
    NSString *filePath = PATH_FOR_IMG_AT_INDEX(index);
    NSError *error = nil;

    // Save the file      
    if (![fileManager createFileAtPath:filePath contents:imageData attributes:nil]) {
        DLog(@"Error saving file at %@", filePath);
    }

    // Notifiy the main thread that our file is saved.
    [self performSelectorOnMainThread:@selector(imageLoadedAtPath:) withObject:filePath waitUntilDone:NO];

}

Answer 7

我认为，最完整的答案来自 Jeffrey Sambell 的博客文章 'iOS 中的异步操作与 Grand Central Dispatch' 它对我有用！
它与上述 Brad 提出的解决方案基本相同，但根据 OSX/IOS 并发模型进行了充分解释。

dispatch_get_current_queue函数将返回当前队列
从中调度块和dispatch_get_main_queue
函数将返回您的 UI 运行的主队列。

dispatch_get_main_queue函数对于更新
iOS 应用程序的 UI 作为 UIKit 方法不是线程安全的（有一些
例外），因此您为更新 UI 元素而进行的任何调用都必须始终是
从主队列完成。

典型的 GCD 调用如下所示：

// 在主线程上做一些事情
dispatch_queue_t myQueue =dispatch_queue_create("我的队列",NULL);
dispatch_async(myQueue, ^{

// 执行长时间运行的进程   
dispatch_async(dispatch_get_main_queue(), ^{
    // 更新用户界面   
    }); 
}); 

// 继续做其他事情  
// 进程运行时的主线程。

这是我的工作示例（iOS 6+）。它使用 AVAssetReader 类显示存储视频的帧：

//...prepare the AVAssetReader* asset_reader earlier and start reading frames now:
[asset_reader startReading];

dispatch_queue_t readerQueue = dispatch_queue_create("Reader Queue", NULL);
dispatch_async(readerQueue, ^{
    CMSampleBufferRef buffer;
    while ( [asset_reader status]==AVAssetReaderStatusReading )
    {
        buffer = [asset_reader_output copyNextSampleBuffer];
        if (buffer!=nil)
        {
            //The point is here: to use the main queue for actual UI operations
            dispatch_async(dispatch_get_main_queue(), ^{
                // Update the UI using the AVCaptureVideoDataOutputSampleBufferDelegate style function
                [self captureOutput:nil didOutputSampleBuffer:buffer fromConnection:nil];
                CFRelease (buffer);
            });
        }
    }
});

此示例的第一部分可以在 此处在达米安的回答中。

Answer 8

我想为给定的问题提供一个干净的解决方案。

我同意其他发帖者的观点，在理想情况下，所有繁重的工作都应该在后台线程中完成，但是有时这根本不可能，因为耗时的部分需要大量访问非线程安全方法，例如UIKit 提供的那些。就我而言，初始化 UI 非常耗时，而且我无法在后台运行任何内容，因此我最好的选择是在初始化期间更新进度栏。

然而，一旦我们考虑理想的 GCD 方法，解决方案实际上很简单。我们在后台线程中完成所有工作，将其划分为在主线程上同步调用的卡盘。运行循环将为每个卡盘运行，更新 UI 和任何进度条等。

- (void)myInit
{
    // Start the work in a background thread.
    dispatch_async(dispatch_get_global_queue(0, 0), ^{

        // Back to the main thread for a chunk of code
        dispatch_sync(dispatch_get_main_queue(), ^{
            ...

            // Update progress bar
            self.progressIndicator.progress = ...: 
        });

        // Next chunk
        dispatch_sync(dispatch_get_main_queue(), ^{
            ...

            // Update progress bar
            self.progressIndicator.progress = ...: 
        });

        ...
    });
}

当然，这本质上与 Brad 的技术相同，但他的答案并没有完全解决当前的问题 - 运行大量定期更新 UI 时的非线程安全代码。

Answer 9

Joe——如果您愿意对其进行设置，以便您的冗长处理全部发生在drawRect内部，您就可以使其工作。我刚刚写了一个测试项目。有用。请参阅下面的代码。

LengthyComputationTestAppDelegate.h：

#import <UIKit/UIKit.h>
@interface LengthyComputationTestAppDelegate : NSObject <UIApplicationDelegate> {
    UIWindow *window;
}

@property (nonatomic, retain) IBOutlet UIWindow *window;

@end

LengthComputationTestAppDelegate.m：

#import "LengthyComputationTestAppDelegate.h"
#import "Incrementer.h"
#import "IncrementerProgressView.h"

@implementation LengthyComputationTestAppDelegate

@synthesize window;


#pragma mark -
#pragma mark Application lifecycle

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {    

    // Override point for customization after application launch.
    IncrementerProgressView *ipv = [[IncrementerProgressView alloc]initWithFrame:self.window.bounds];
    [self.window addSubview:ipv];
    [ipv release];
    [self.window makeKeyAndVisible];
    return YES;
}

Incrementer.h：

#import <Foundation/Foundation.h>

//singleton object
@interface Incrementer : NSObject {
    NSUInteger theInteger_;
}

@property (nonatomic) NSUInteger theInteger;

+(Incrementer *) sharedIncrementer;
-(NSUInteger) incrementForTimeInterval: (NSTimeInterval) timeInterval;
-(BOOL) finishedIncrementing;

incrementer.m：

#import "Incrementer.h"

@implementation Incrementer

@synthesize theInteger = theInteger_;

static Incrementer *inc = nil;

-(void) increment {
    theInteger_++;
}

-(BOOL) finishedIncrementing {
    return (theInteger_>=100000000);
}

-(NSUInteger) incrementForTimeInterval: (NSTimeInterval) timeInterval {
    NSTimeInterval negativeTimeInterval = -1*timeInterval;
    NSDate *startDate = [NSDate date];
    while (!([self finishedIncrementing]) && [startDate timeIntervalSinceNow] > negativeTimeInterval)
        [self increment];
    return self.theInteger;
}

-(id) init {
    if (self = [super init]) {
        self.theInteger = 0;
    }
    return self;
}

#pragma mark --
#pragma mark singleton object methods

+ (Incrementer *) sharedIncrementer { 
    @synchronized(self) {
        if (inc == nil) {
            inc = [[Incrementer alloc]init];        
        }
    }
    return inc;
}

+ (id)allocWithZone:(NSZone *)zone {
    @synchronized(self) {
        if (inc == nil) {
            inc = [super allocWithZone:zone];
            return inc;  // assignment and return on first allocation
        }
    }
    return nil; // on subsequent allocation attempts return nil
}

- (id)copyWithZone:(NSZone *)zone
{
    return self;
}

- (id)retain {
    return self;
}

- (unsigned)retainCount {
    return UINT_MAX;  // denotes an object that cannot be released
}

- (void)release {
    //do nothing
}

- (id)autorelease {
    return self;
}

@end

IncrementerProgressView.m：

#import "IncrementerProgressView.h"


@implementation IncrementerProgressView
@synthesize progressLabel = progressLabel_;
@synthesize nextUpdateTimer = nextUpdateTimer_;

-(id) initWithFrame:(CGRect)frame {
    if (self = [super initWithFrame: frame]) {
        progressLabel_ = [[UILabel alloc]initWithFrame:CGRectMake(20, 40, 300, 30)];
        progressLabel_.font = [UIFont systemFontOfSize:26];
        progressLabel_.adjustsFontSizeToFitWidth = YES;
        progressLabel_.textColor = [UIColor blackColor];
        [self addSubview:progressLabel_];
    }
    return self;
}

-(void) drawRect:(CGRect)rect {
    [self.nextUpdateTimer invalidate];
    Incrementer *shared = [Incrementer sharedIncrementer];
    NSUInteger progress = [shared incrementForTimeInterval: 0.1];
    self.progressLabel.text = [NSString stringWithFormat:@"Increments performed: %d", progress];
    if (![shared finishedIncrementing])
        self.nextUpdateTimer = [NSTimer scheduledTimerWithTimeInterval:0. target:self selector:(@selector(setNeedsDisplay)) userInfo:nil repeats:NO];
}

- (void)dealloc {
    [super dealloc];
}

@end

Answer 10

关于最初的问题：

总之，你可以(A)背景大画，并调用前台进行UI更新或(B ）可以说是有争议的有四种“立即”方法建议不使用后台进程。要获得有效结果，请运行演示程序。它为所有五个方法提供了#defines。

---

或者，汤姆·斯威夫特 (

Tom Swift) 解释了非常简单地操纵运行循环的惊人想法。以下是触发运行循环的方法：

[[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode beforeDate: [NSDate date]];

这是一个真正令人惊叹的工程。当然，在操作运行循环时应​​该非常小心，正如许多人指出的那样，这种方法仅供专家使用。

---

然而，出现了一个奇怪的问题......

尽管许多方法都有效，但它们实际上并没有“起作用”，因为您将在演示中清楚地看到一个奇怪的渐进减速伪像。

滚动到我粘贴在下面的“答案”，显示控制台输出 - 您可以看到它如何逐渐减慢。

这是新的 SO 问题：
运行循环/drawRect中神秘的“渐进减慢”问题

这是演示应用程序的V2...
http://www.fileswap.com/dl/p8lU3gAi/stepwiseDrawingV2.zip。 html

您将看到它测试了所有五种方法，

#ifdef TOMSWIFTMETHOD
 [self setNeedsDisplay];
 [[NSRunLoop currentRunLoop]
      runMode:NSDefaultRunLoopMode beforeDate:[NSDate date]];
#endif
#ifdef HOTPAW
 [self setNeedsDisplay];
 [CATransaction flush];
#endif
#ifdef LLOYDMETHOD
 [CATransaction begin];
 [self setNeedsDisplay];
 [CATransaction commit];
#endif
#ifdef DDLONG
 [self setNeedsDisplay];
 [[self layer] displayIfNeeded];
#endif
#ifdef BACKGROUNDMETHOD
 // here, the painting is being done in the bg, we have been
 // called here in the foreground to inval
 [self setNeedsDisplay];
#endif

• 您可以自己查看哪些方法有效，哪些无效。

• 你可以看到奇怪的“渐进式减速”。为什么会发生这种情况？

• 可以看到，用备受争议的TOMSWIFT方法，其实响应能力完全没有问题。随时点击响应（但仍然是奇怪的“渐进减速”问题）

所以压倒性的事情是这个奇怪的“渐进减速”：在每次迭代中，由于未知的原因，循环所花费的时间减少。请注意，这适用于“正确”执行（背景外观）或使用“立即”方法之一。

---

实用的解决方案？

对于未来阅读的人来说，如果由于“神秘的渐进式减速”而实际上无法使其在生产代码中工作，Felz 和 Void 都在另一个具体问题中提出了令人震惊的解决方案。