—–自动释放（Auto release）与便捷方法(convenience method)—–

有时候一个所有者创建一个对象后，会立刻将该对象的指针传递给其它所有者。这时，这个创建者不希望再拥有这个对象，但如果立刻给它发送一个release消息会导致这个对象被立刻释放掉——这样其它所有者还没有来得及保留该对象。解决这个两难问题的方法是，给对象发送一个autorelease消息：这样创建者不再拥有该对象的所有权；该对象成为自动释放的对象，但是不会立刻被释放掉；其它所有者可以有时间保留或复制该对象，并成为其唯一所有者。

我们来看一个自动释放的例子（代码清单3-1）。一个所有者先用alloc方法创建一个对象；此时该所有者拥有这个对象，对象的引用计数为1。紧接着，所有者自动释放该对象；所有者此时已经放弃了所有权，但对象的引用计数在一段时间内依然为1。我们可以看出自动释放的另一个好处：你不会因为在后面忘记给对象发送release消息而造成内存泄露。

代码清单3-1

与自动释放相关的，有一大类构造方法（constructor method），由它们构造的对象直接就是自动释放的对象；这一类构造方法叫做便捷方法。比如下面这句的字符串就是一个自动释放的对象，stringWithFormat:就是一个便捷方法。

NSString* string = [NSString stringWithFormat:@”autoreleaseString”];

再举几个便捷方法的例子，方便读者以后的开发。

1.NSArray的arrayWithObjects:和arrayWithArray:。

2.UIImage的imageNamed:。

3.NSNumber的numberWithBool等。

现在我们已经解释了，autorelease方法会在一段时间以后释放掉一个对象，在这段时间内我们可以安全地使用该对象。那么这段时间究竟是多久呢？我们需要先更多地了解自动释放的机制，再来回答这个问题。

让我们先来看看自动释放池。自动释放池是NSAutoreleasePool的实例，其中包含了收到autorelease消息的对象。当一个自动释放池自身被销毁（dealloc）时，它会给池中每一个对象发送一个release消息（如果你给一个对象多次发送autorelease消息，那么当自动释放池销毁时，这个对象也会收到同样数目的release消息）。可以看出，一个自动释放的对象，它至少能够存活到自动释放池销毁的时候。

那么自动释放池何时被创建，又何时被销毁呢？在每一个事件周期（event cycle）的开始，系统会自动创建一个自动释放池；在每一个事件周期的结尾，系统会自动销毁这个自动释放池。一般情况下，你可以理解为：当你的代码在持续运行时，自动释放池是不会被销毁的，这段时间内你也可以安全地使用自动释放的对象；当你的代码运行告一段落，开始等待用户输入（或者其它事件）时，自动释放池就会被释放掉，池中的对象都会收到一个release消息，有的可能会因此被销毁。

到此为止，相信你已经对自动释放的机制有了一个大体的了解。自动释放而非直接释放，可以帮助你节省一些代码量，提高开发速度。但是它有一个直接的缺点：它延缓了对象的释放，在有大量自动释放的对象时，会占用大量内存资源。因此，你需要避免将大量对象自动释放。并且，在以下两种情况下，你需要手动建立并手动销毁掉自动释放池：

1.当你在主线程外开启其它线程时：系统只会在主线程中自动生成并销毁掉自动释放池。

2.当你在短时间内制造了大量自动释放对象时：及时地销毁有助于有效利用iPad上有限地内存资源。

我所感动的是，导师对我的决定很理解和支持。她说她支持我去“follow my heart”。跟随她做科研的三年里，虽然挨了不少批评，但是我学会了怎样去追求完美。我在三年里学过的知识也许会被遗忘，但追求完美的精神被铭刻住了是不会消失的，也会用到我今后的开发之中。

我会有更多的时间去做我所热爱的开发，既是为了生存，更是为了梦想。我也会更多地更新这个博客，记录自己的成长，也帮助每一位有梦想的开发者。

本系列文章版权归李晨所有，出版权归华章公司所有，谢绝转载。

－－－－－对象所有权（ownership）与引用计数（retain count、reference count）－－－－－

当一个所有者（owner，其本身可以是任何一个Objective-C对象）做了以下某个动作时，它拥有对一个对象的所有权（ownership）：

1. 创建一个对象。包括使用任何名称中包含“alloc”、“new”、或者“copy”的方法。

2. 保留（retain）一个对象。

一个对象可以有多个所有者，一个所有者也可以拥有多个对象。

相应的，引用计数增减的基本规则是：

1.当所有者创建一个对象时，该对象的引用计数为1。

2.当所有者保留它时，该对象的引用计数加1。

3.当所有者释放（release）它时，该对象的引用计数减1。

与此相关的，当一个所有者对于一个对象的引用计数的增减总计为0时，它放弃了对这个对象的所有权。

现在我们可以从两个不同的角度来看Objective-C的内存管理问题。从对象所有权的角度来看，当一个对象有着至少一个所有者（owner）的时候，它依然存在；当它没有任何所有者的时候，它会被释放掉。从引用计数的角度看，一个对象存在时，其引用计数大于零；当一个对象的引用计数为零时，它会调用dealloc方法并释放掉。这两个角度的关系是：在所有权的背后起作用的机制是引用计数机制；我们通过引用计数的增减来理解所有权的概念；但是你只应当使用所有权的概念来管理内存，因为如果你试图直接获取对象的引用计数，那么得到的数将让你感到匪夷所思——系统的一些框架会“偷偷”增减对象的引用计数。

回顾一下，内存管理的目标是：当一个对象的某个所有者依然需要使用它时，保证这个对象的存在；当一个对象的所有所有者都不再需要它时，保证这个对象被销毁。因此只要任何一个所有者在使用完一个对象之后释放掉它，那么以上内存管理的目标就可以实现。我们可以得出任何一个所有者（记住，所有者本身也只是一个对象）所应当遵守的基本步骤：

拥有一个对象 -> 使用一个对象 -> 放弃对象的所有权。

从引用计数的角度来看就是：

还需要这个对象时，保持对其增减为正；不再需要这个对象时，保持对其增减为0。

下图很好地诠释了这些基本规则:所有者1和所有者2单独地执行了拥有对象、使用对象、放弃对象所有权的步骤；当所有者1不再需要该对象时及时放弃了所有权，但此时所有者2依然拥有该对象，因此该对象依然存在，所有者2可以继续使用它；当所有者2也不再需要该对象时，也放弃掉所有权，这时对象以不再有任何所有者（相应的引用计数也变为0），因此立刻被销毁掉。

需要注意的是，所有者2只是复制了该对象的指针，并没有使用copy方法，因此复制指针这个操作本身并不增加对象的引用计数；而正因为所有者2希望能使用该对象，因此通过retain方法成为它的所有者，也保证了所有者1放弃该对象时，对象不被销毁。

在此用我微不足道的一点声音来纪念他们！

简介：Openfeint是一个在线游戏系统，用于iPhone或者iPad游戏计分、挑战、多人对战等。可以在官网免费下载它的SDK。

环境：Openfeint 2.5.1，XCode 3.2.3，iPhone SDK 4.0，Cocos 2d 0.94。

步骤：

1. 将下载好的Openfeint文件夹加入工程之中。

2. 移除其中不需要的文件夹

－ 如果你的游戏只支持landscape或者只支持iPad，移除iPhone_Portrait文件夹

－ 如果你的游戏只支持Portrait或者只支持iPad，移除iPhone_Landscape文件夹

－ 如果你的游戏不支持iPad，移除iPad文件夹

3. 在Project Settings中，

－ 选择Build页，Configuration设置为All Configurations

－ 找到Other Linker Flags，设置为 -ObjC

－ 确保Call C++ Default Ctors/Dtors in Objective-C被打了钩  

4. 添加以下framework

* Foundation* UIKit* CoreGraphics* QuartzCore* Security* SystemConfiguration* libsqlite3.0.dylib (located in (iPhoneSDK Folder)/usr/lib/)* CFNetwork* CoreLocation* MapKit (if building with SDK 3.0 or newer)* libz.1.2.3.dylib (alternatively you can add a OF_EXCLUDE_ZLIB preprocessor definition) 

5. 在工程的prefix.pch文件中加入

#import “OpenFeintPrefix.pch”

6. 使用.mm后缀名（而不是.m）

7. 在Openfeint官网下载offline configuration文件（你每次更改设置都需要重新下载）。将这个文件添加到工程当中。

8. 在应用中加入SampleOFDelegate.h文件

#import “OpenFeintDelegate.h”

@interface SampleOFDelegate : NSObject< OpenFeintDelegate >

- (void)dashboardWillAppear;

- (void)dashboardDidAppear;

- (void)dashboardWillDisappear;

- (void)dashboardDidDisappear;

- (void)userLoggedIn:(NSString*)userId;

- (BOOL)showCustomOpenFeintApprovalScreen;

@end

9. 加入SampleOFDelegate.mm文件

#import “OpenFeint.h”
#import “SampleOFDelegate.h”
#import “cocos2d.h”

@implementation SampleOFDelegate

- (void)dashboardWillAppear
{}

- (void)dashboardDidAppear
{
[[CCDirector sharedDirector] pause];
[[CCDirector sharedDirector] stopAnimation];
}

- (void)dashboardWillDisappear
{}

- (void)dashboardDidDisappear
{
[[CCDirector sharedDirector] resume];
[[CCDirector sharedDirector] startAnimation];
}

- (void)userLoggedIn:(NSString*)userId
{
OFLog(@”New user logged in! Hello %@”, [OpenFeintlastLoggedInUserName]);
}

- (BOOL)showCustomOpenFeintApprovalScreen
{
return NO;
}

@end

10. 在应用启动时加入以下代码；其中launchDashboard一句可以加在其它地方。

#import “OpenFeint.h”

// Initialize OpenFeint on the title screen after you’ve displayed any splash screens.

// OpenFeint will present a modal the first time it’s initialized to conform with apple regulations.

- (void)initializeOpenfeint

{

   [OpenFeint initializeWithProductKey:yourProductKey

   andSecret:yourProductSecret

   andDisplayName:yourApplicationNameForUsers

   andSettings:aDictionaryOfOpenFeintSettings // see OpenFeintSettings.h

   andDelegates:aDelegateContainer]; // see OFDelegatesContainer.h

   // You probably want to invoke this from a button instead of directly here.

   [OpenFeint launchDashboard];

}

- (void)applicationDidBecomeActive:(UIApplication *)application

{

[OpenFeint applicationDidBecomeActive];

}

- (void)applicationWillResignActive:(UIApplication *)application

{

[OpenFeint applicationWillResignActive];

}

- (void)applicationDidEnterBackground:(UIApplication *)application

{

[OpenFeint applicationDidEnterBackground];

}

- (void)applicationWillEnterForeground:(UIApplication *)application

{

[OpenFeint applicationWillEnterForeground];

}

比如下面这段代码就利用NSLog，在程序运行时判断设备种类并显示出来

NSString *deviceType = [UIDevice currentDevice].model;
NSLog(@”device type: %@.”, deviceType);

使用NSLog的一个风险是：它的运行会占用时间和设备资源。当我们用Simulator时，NSLog的资源占用并不引人注意，风险也不会显示出来。但是如果你写的是一个即时战略游戏，而你在每一个action中都加入了NSLog——那么NSLog将成为一个魔鬼。灾难的具体表现常常是：你在Simulator中运行游戏畅通无阻，但到了真机上，会发现很“卡”，不论是拖动一个单位还是缩放一个场景，FPS也降到了各位数。

简单而粗暴的解决方案是：在一个游戏release前，将所有的NSLog注释掉。简单有效，但副作用是：下次你要调试时，又得将NSLog一个个取消注释。

我找到了一个最为有效的解决方案：你以release模式编译的程序不会用NSLog输出，而你以debug模式编译的程序将执行NSLog的全部功能。

#ifndef __OPTIMIZE__
# define NSLog(…) NSLog(__VA_ARGS__)
#else
# define NSLog(…) {}
#endif

代码来源

这个代码的魔术在于：release模式通常会定义 __OPTIMIZE__，当然debug模式不会。将这段代码放在你的头文件当中，你就可以放心的使用NSLog了！

iOS 4 is ready for downloading at 10:15AM PDT, Jun 21, 2010!

对于任何做iPhone游戏的开发者，如何保存游戏是一个必需解决的问题。这里转一篇非常赞的文章，里面简单明了地介绍了解决办法。我懒得翻译了，如果你更懒以至于不愿意读英文说明的话，可以直接看代码，挺清晰的。

原文链接：http://deadpanic.com/howtosave

How to save your game (or any object) on the iPhone

Warning to some, bonus to others: this post is less markety and more code-heavy. It also reveals some info about the architecture of “Dead Panic.”

Newcomers to iPhoneDevSDK often ask how to convert a string to bytes for writing to a file and other questions about data persistence that belie their real question: how do I save an object and restore it at a later time? NSUserDefaults is fine for storing some strings or bools, but what about an entire custom object? This is called “archiving” and the Apple docs are here.

In short, as long as an object conforms to the NSCoding protocol you can save it to a file just by calling archiveRootObject:toFile:. Most built-in objects already conform to the protocol; you can save an entire NSArray of NSStrings, NSNumbers, and NSDictiories with that one line of code. If you want to save your own custom objects, though, you must make them conform to the NSCoder protocol by adding two methods – encodeWithCoder and initWithCoder.

How to save an object

In “Dead Panic” I instantly save the game whenever they press the home button, and restore their saved game whenever the game is launched again. To do that I need to save some information about which map they’re on, the player’s progress, and the player and enemy positions and health.

Here is my code for saving the map to a coder:

//Map.m

//encode the map data

- (void) encodeWithCoder: (NSCoder *)coder

{

//code the level name

[coder encodeObject: currentLevelName forKey:@"currentLevelName" ];

// code the length of the event list (progress through the level)

NSNumber *listCount = [NSNumber numberWithInt: [eventList count]];

[coder encodeObject: listCount forKey:@"eventList.count" ];

// code the list of players

[coder encodeObject: charList forKey:@"charList" ];

}

Notice I didn’t save anything about the structure of the map or the what it looks like – that’s all static data I can get elsewhere. When I load this object I’ll know the level name, and I can get all of the static data from there.

What about the positions of all of the players? Well, you can see that I’m encoding “charList” above, which is an NSArray of the players. That means encodeWithCoder will be called for each item in that array, so I leave it up to the player class to save the important data for each player. Here’s the code for saving a player:

//Player.m

//encode a player or monster character

- (void) encodeWithCoder: (NSCoder *)coder

{

//save type number

[coder encodeObject: [NSNumber numberWithInt:type] forKey:@”type” ];

//save x and y position

[coder encodeObject:

[NSNumber numberWithFloat:position.x] forKey:@”position.x” ];

[coder encodeObject:

[NSNumber numberWithFloat:position.y] forKey:@”position.y” ];

//save health

[coder encodeObject: [NSNumber numberWithInt: health] forKey:@”health” ];

}

You can see that there are many things I save, but there’s more data that I don’t save. I don’t save the maximum health of a character, or weapon range, or firing rate, or information about how he is drawn – that info is already in the default constructor, and there is no need to save it redundantly. Avoiding redundancy helps speed up the save process, and it should reduce bugs – a player loaded from a coder should behave the same as one created from scratch.

How to load an object

Of course we need to load the objects too; here is the code for that

//Map.m

//init a map from a coder

- (id) initWithCoder: (NSCoder *) coder

{

[self init];

// load the level name

self.currentLevelName = [coder decodeObjectForKey:@"currentLevelName"];

// load the current event number

int eventsRemaining = [[coder decodeObjectForKey:@"eventList.count"] intValue];

// load level based on level name

[self loadLevel: currentLevelName];

//skip events until we get to the current event number

int length = [eventList count];

NSRange deletionRange = NSMakeRange(0, length-eventsRemaining);

[eventList removeObjectsInRange:deletionRange];

//get the list of characters

NSArray *tempCharList = [coder decodeObjectForKey:@"charList"];

//add chars to map, set team counts

for (id newChar in tempCharList)

[self addChar: newChar];

return self;

}

There are some tricks to look at there. I call the default init for the class, then I load a level based on the current level name. This is the same loadLevel method that I use when starting a normal game – I try to keep the custom code for loaded games to a minimum. After I load the level I remove items from the event stack until it matches the length of the saved stack. I could have saved the event stack instead, but again, I’m trying not to duplicate any data.

I also restore the list of characters, but then I add them one at a time using another method of this object – that’s because I have some custom code that must be run for every object on the map. Rather than duplicate that code, I call the method the same way it would be called in regular gameplay.

//Player.m

//init a player or monster from a coder

- (id) initWithCoder: (NSCoder *) coder

{

type = [[coder decodeObjectForKey:@"type" ] intValue]; //load type number

//init based on type number

[self initWithType: type];

// load x and y position

position.x = [[coder decodeObjectForKey:@"position.x" ] floatValue];

position.y = [[coder decodeObjectForKey:@"position.y" ] floatValue];

health = [[coder decodeObjectForKey:@"health" ] intValue];

return self;

}

The only trick here is that I find out what type of player I’m dealing with first, and then init the correct type. Other than that both snippets follow the same pattern – init the object with the regular initializer (the same one I would use when starting a new game) and then apply the information from the saved game.

The final part you can’t see is the game information that I discard entirely – like any particles or damage decals on the screen, or currently playing sound effects. These are all short-term effects that don’t affect the gameplay, and the player won’t miss them when the game reloads. Any ongoing effects – like flames that can damage characters or poisonous clouds to be avoided- would have to be saved, though. You have to decide what is just a visual effect, and what is part of the simulation.

Starting the party

In case you’ve forgotten how all these methods get called, we kick it all off with these lines:

//load the map from disk; its array of players gets loaded too.

//This causes “intiWithCoder” to be called

myMap = [NSKeyedUnarchiver unarchiveObjectWithFile: filePath];

//take some action if myMap == nil (will happen if save file does not exist)

//save the map to disk; it contains an array of players, so they get saved too.

//This caused “encodeWithCoder” to be called

[NSKeyedArchiver archiveRootObject: myMap toFile:filePath];

That’s all there is to it – make your custom objects conform to NSCoder by adding the two methods, try to save only the data that is necessary, and try to use existing initializers and methods wherever possible. Then kick it all off with unarchiveObjectWithFile or archiveRootObject.

PS – be sure to add <NSCoding> to the list of protocols for your object in the .h file to eliminate any warnings.