Block 实用指南

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2009-08-14-practical-blocks.html

Welcome back to another edition of Friday Q&A. I’m back from my break and ready to bring you more programming goodies. This week I want to take Landon Fuller’s suggestion to write a followup to my original Friday Q&A on blocks now that the design is finalized and code available for them.

Although Apple has yet to ship blocks with any of their developer tools, they have released code for their blocks implementation due to their participation in the open-source compilers gcc and clang. Landon has used this code to put together PLBlocks, which allows building and running blocks-based code on Mac OS X 10.5. While there are no blocks-based APIs on 10.5 (aside from the very basics which are part of the runtime), they can still be used to great effect.

I’m not going to cover the installation or basic use of PLBlocks here, as the PLBlocks page covers this in great detail. If you want to follow along, go there and follow the directions. For more information about how blocks work, see Clang’s blocks language spec and implementation spec.

I’m also going to assume that you know the basics of block syntax and usage, as covered in my last Friday Q&A on the subject. Today’s is essentially Part II of that one. If you haven’t already, go read that one first.

Fundamentals Blocks are Objective-C objects. When you write a block in code, that is an expression of object type, much like the @”…” constant string syntax gives you an expression of object type. You can then use this object like you would any other Objective-C object, by sending it messages that it responds to, putting it into containers, passing it as a parameter, returning it, etc.

There is a major difference from the constant string syntax. Unlike constant strings, blocks are not exactly the same each time through a piece of code. This is because blocks capture their enclosing scope, and that scope is different every time they’re called. In short, each time code execution hits a ^{…} construct, a new object is created.

Allocating a new object every time would be kind of slow, so blocks take an unusual approach: the object you get from a ^{…} construct is a stack object. This means that it has the same lifetime as local variables, and will be destroyed automatically upon leaving the current scope. Weird, huh?

It’s frequently useful for a block to outlive the scope where it was created. For example, you may want to return a block, or save it for later. For this to work, you must copy the block. You can do this like any other Objective-C object by sending it the -copy message. And like any other Objective-C object, if you aren’t running under Garbage Collection then you own the resulting object and must eventually dispose of it using -release or -autorelease.

This, then, is an example of returning a block from a method:

1
    - (void (^)(void))block { return [[^{ ... } copy] autorelease]; }

Note that external variable capture gives const copies of those variables by default. In other words, this is not legal:

1
    int i;
2
    ^{ i++; };

1
    __block int i;
2
    ^{ i++; };

Examples I’m going to be showing a bunch of examples for how to use blocks with PLBlocks on 10.5. Those of you who want to follow along may wish to look at the example project I built, which you can get out of my public subversion repository here:

1
    svn co http://www.mikeash.com/svn/PLBlocksPlayground/

Custom APIs That’s the basic idea of how they work, now let’s see what we can do with them.

As I mentioned in my first blocks post, blocks essentially allow you to build new control constructs without needing to modify the language. Before we get into it, I want to introduce a little typedef to keep things simple. Most control-construct blocks are blocks which take no parameters and return no value. As such, it’s nice to have that type wrapped up in something a little nicer to write:

1
    typedef void (^BasicBlock)(void);

1
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
2
    ...
3
    [pool release];

1
    void WithAutoreleasePool(BasicBlock block)
2
    {
3
        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
4
        block();
5
        [pool release];
6
    }

1
    for(id obj in array)
2
        WithAutoreleasePool(^{
3
            [self createLotsOfTemporaryObjectsWith:obj];
4
        });

Let’s attack something a little more complicated. It’s common in Cocoa programs to need to run some code after a short delay, using -performSelector:withObject:afterDelay:. Often we’ll use a zero delay to mean “run this code immediately after returning to the runloop”. The trouble with this is that it requires an object and a separate method, and getting the relevant context over can be painful. Let’s write a quickie blocks function instead:

1
    void RunAfterDelay(NSTimeInterval delay, BasicBlock block)
2
    {
3
        [[[block copy] autorelease] performSelector: @selector(my_callBlock) withObject: nil afterDelay: delay];
4
    }

1
    @implementation NSObject (BlocksAdditions)
2

3
    - (void)my_callBlock
4
    {
5
        void (^block)(void) = (id)self;
6
        block();
7
    }
8

9
    @end

1
    NSString *something = ...;
2
    RunAfterDelay(0, ^{
3
        NSLog(@"%@", something);
4
        [self doWorkWithSomething: something];
5
    });

Another thing that we frequently write is a critical section of code protected by a lock. Normally this would look like:

1
    [lock lock];
2
    ...do stuff...
3
    [lock unlock];

1
    [lock lock];
2
    @try
3
    {
4
        ...do stuff...
5
    }
6
    @finally
7
    {
8
        [lock unlock];
9
    }

1
    @implementation NSLock (BlocksAdditions)
2

3
    - (void)whileLocked: (BasicBlock)block
4
    {
5
        [self lock];
6
        @try
7
        {
8
            block();
9
        }
10
        @finally
11
        {
12
            [self unlock];
13
        }
14
    }
15

16
    @end

A Stylistic Note There are two interesting choices in the above code, both due to the same reason. The first choice is that these are functions, not methods. Since blocks are NSObjects, category methods on NSObjects can be used for them. Rather than a RunAfterDelay function, we could write a -runAfterDelay: method on NSObject. The second choice is to always put the block parameter last, even though it’s the most significant parameter and would make more sense to go first.

The reason for both of these is that you want the block to come absolutely last so that your code remains readable when the block is split onto multiple lines. For example, imagine some nested blocks code using the above functions recast using methods instead:

1
    [^{
2
        for(id obj in array)
3
            [^{
4
                [self doImportantWork:obj];
5
            } withAutoreleasePool];
6
    } runAfterDelay: 0];

Collections Using blocks with collections can make for powerful looping constructs. Let’s start out with this really simple substitute for a for loop, as a method on NSArray:

1
    - (void)do: (void (^)(id obj))block
2
    {
3
        for(id obj in self)
4
            block(obj);
5
    }

1
    NSArray *array = ...;
2
    [array do: ^(id obj){ NSLog(@"%@", obj); }];

1
    - (NSArray *)map: (id (^)(id obj))block
2
    {
3
        NSMutableArray *new = [NSMutableArray array];
4
        for(id obj in self)
5
        {
6
            id newObj = block(obj);
7
            [new addObject: newObj ? newObj : [NSNull null]];
8
        }
9
        return new;
10
    }

1
    NSArray *people = ...;
2
    NSArray *names = [people map: ^(id person){
3
        return [NSString stringWithFormat: @"%@ %@", [person firstName], [person lastName]];
4
    }];

One more example, this allows filtering an array:

1
    - (NSArray *)select: (BOOL (^)(id obj))block
2
    {
3
        NSMutableArray *new = [NSMutableArray array];
4
        for(id obj in self)
5
            if(block(obj))
6
                [new addObject: obj];
7
        return new;
8
    }

1
    NSArray *longStrings = [strings select: ^ BOOL (id obj) { return [obj length] > 5; }];

Here’s an example of a use in a GUI application, for getting all the text fields inside a particular view:

1
    NSArray *textFields = [[view subviews] select: ^(id obj){ return [obj isKindOfClass: [NSTextField class]]; }];

Callbacks Callbacks-based APIs are a place where blocks really shine. Instead of passing a selector/delegate pair, or a function pointer/context pointer pair, pass a block. It makes it much easier to pass context around (since the block packages up all needed context automatically) and keeps all of the code nearby.

An obvious example of a callback is notifications. While there’s often a benefit to having separated methods for notifications, the implementation is easy and it can sometimes make for nicer code:

1
    @implementation NSNotificationCenter (BlocksAdditions)
2

3
    - (void)addObserverForName: (NSString *)name object: (id)object block: (void (^)(NSNotification *note))block
4
    {
5
        [self addObserver: [block copy] selector: @selector(my_callBlockWithObject:) name: name object: object];
6
    }
7

8
    @end

You can use it like so:

1
    [[NSNotificationCenter defaultCenter] addObserverForName: NSApplicationDidBecomeActiveNotification
2
                                                      object: nil
3
                                                       block: ^(NSNotification *note){ NSLog(@"Did become active"); }];

Sheets are a good example of a painful callbacks-based API in Cocoa. You have to implement a callback method, then cram all of the state associated with the sheet, which is often large, either into the single void * context parameter provided, or into instance variables. Neither way is particularly nice.

Here is a small category which translates this API to use blocks instead:

1
    @implementation NSApplication (SheetAdditions)
2

3
    - (void)beginSheet: (NSWindow *)sheet modalForWindow:(NSWindow *)docWindow didEndBlock: (void (^)(NSInteger returnCode))block
4
    {
5
        [self beginSheet: sheet
6
          modalForWindow: docWindow
7
           modalDelegate: self
8
          didEndSelector: @selector(my_blockSheetDidEnd:returnCode:contextInfo:)
9
             contextInfo: [block copy]];
10
    }
11

12
    - (void)my_blockSheetDidEnd: (NSWindow *)sheet returnCode: (NSInteger)returnCode contextInfo: (void *)contextInfo
13
    {
14
        void (^block)(NSInteger returnCode) = contextInfo;
15
        block(returnCode);
16
        [block release];
17
    }
18

19
    @end

Another example of a similarly painful API is NSURLConnection. It provides two modes: synchronous and asynchronous. The synchronous mode can only be used from a secondary thread which can be blocked for arbitrarily long amounts of time, since any network operation can take a long time to complete. The asynchronous mode requires writing a lot of boilerplate code. Let’s write a method that adds an asynchronous mode that simply makes a single call to a block when it’s done to hand over the data, the response metadata, and the error, if any. To do this, we’ll just use the synchronous API in a background thread. This code uses two functions, RunInBackground and RunOnThread, which are blocks-based APIs for spawning a new thread and running a block on an existing thread, respectively. These functions are pretty straightforward to implement and I won’t duplicate them here, but you can get them in the sample project if you need.

Here’s what the code looks like:

1
    @implementation NSURLConnection (BlocksAdditions)
2

3
    + (void)sendAsynchronousRequest: (NSURLRequest *)request
4
                    completionBlock: (void (^)(NSData *data, NSURLResponse *response, NSError *error))block
5
    {
6
        NSThread *originalThread = [NSThread currentThread];
7

8
        RunInBackground(^{
9
            WithAutoreleasePool(^{
10
                NSURLResponse *response = nil;
11
                NSError *error = nil;
12
                NSData *data = [self sendSynchronousRequest: request returningResponse: &response error: &error;];
13
                RunOnThread(originalThread, NO, ^{ block(data, response, error); });
14
            });
15
        });
16
    }
17

18
    @end

Here’s an example of using this API:

1
    NSURLRequest *request = [NSURLRequest requestWithURL: [NSURL URLWithString: @"http://www.google.com/"]];
2
    [NSURLConnection sendAsynchronousRequest: request
3
                             completionBlock: ^(NSData *data, NSURLResponse *response, NSError *error){
4
        NSLog(@"data: %ld bytes  response: %@  error: %@", (long)[data length], response, error);
5
    }];

Caveats It should be no surprise that there are some things to look out for when working with blocks.

When blocks are copied, any local object variables they refer to get automatically retained. They are then automatically released when the block is destroyed. This is convenient to ensure that the references remain valid. Any reference to self is a reference to a local object variable, causing self to be retained. Any reference to an instance variable is an implicit reference to self and causes the same thing. However, this makes it easy to cause a retain cycle in some instances. Imagine using a more fleshed-out version of that blocks-based notification API which allows unregistering the notification. If your block refers to self in any way, and you do the standard Cocoa thing of unregistering the notification in -dealloc, your object will leak because the block will hold a reference to your object.

A simple workaround to this lies in the fact that __block variables are not retained. This is because such variables are mutable, and automatic memory management of them would require each mutation to generate memory management code behind the scenes. This was seen as too intrusive and difficult to get right, especially since the same block may be executing from multiple threads simultaneously. Thus you can avoid the retain cycle like so:

1
    __block MyClass *blockSelf = self;
2
    ^{
3
        [blockSelf message];
4
        [blockSelf->ivar message];
5
    };

Another pitfall with blocks is due to the fact that they are stack objects. Using the ^{…} syntax is essentially the same, behind the scenes, as declaring a local variable and then taking its address for something. The address can be passed around, but as soon as you leave the scope in which the local variable was declared, it’s no longer valid. Thus, something as innocent as this ends up being broken code:

1
    BasicBlock block;
2
    if(condition)
3
        block = ^{...};
4
    else
5
        block = ^{...};

1
    BasicBlock block;
2
    if(condition)
3
        block = [[^{...} copy] autorelease];
4
    else
5
        block = [[^{...} copy] autorelease];

Conclusion That wraps up this week’s Friday Q&A. You’ve seen how to get blocks up and running with your current tool chain, a few examples of how they can be used in a useful manner, and some problems to watch out for. Now you’re ready to start using blocks in your 10.5 apps today, no need to wait for 10.6 to ship.

Questions about blocks? Have your own ideas for how best to use them? Post below.

Come back next week for another edition of Friday Q&A. As always, Friday Q&A is driven by your ideas. If you have a topic that you would like to see covered here, post it below or e-mail it to me.