xcode project文件

xcode的project工程文件

1、xcuserdata文件夹。
You can safely delete the xcuserdata directories. It basically contains personal settings like breakpoints, user interface layout, open files, automatic snapshots configuration and so on.

ACK

ACK可以是下列意思：

• ACK (计算机)，一种讯号，用于确认（acknowledgement）

ACK

【计】 确认字符, 肯定, 确认

ACK0

【计】 确认, 肯定, 偶肯定应答

ACK1

【计】 确认, 肯定, 奇肯定应答

ACKI

【计】 确认输入

ACKO

【计】 确认输出

acknowledgement

*[әk'nɒlidʒmәnt]

n. 承认, 确认, 感谢, 收到的通知

【计】 确认; 肯定

u_int32_t vs uint32_t

iOS官网文档里面 都用的 uint32_t

uint32_t 是在 usr/include/stdint.h 头文件定义

u_int32_t 是在 usr/include/i386/types.h 头文件定义的

We need to explain how the typedefs "u_int32_t" vs "uint32_t" conform to 
various standards in ANSI or ISO.

I do not have access to the OpenBSD files, but include the relevent statements from Solaris:


Excerpted from  on Solaris 10:

#pragma ident   "@(#)int_types.h        1.9     04/06/14 SMI"

/*
 * This file, , is part of the Sun Microsystems 
implementation
 * of  defined in the ISO C standard, ISO/IEC 9899:1999
 * Programming language - C.
 *
 * Programs/Modules should not directly include this file.  Access to the
 * types defined in this file should be through the inclusion of one of the
 * following files:
 *
 *                 Provides only the "_t" types defined in this
 *                              file which is a subset of the contents of
 *                              .  (This can be appropriate for
 *                              all programs/modules except those claiming
 *                              ANSI-C conformance.)
 *
 *              Provides the Kernel and Driver appropriate
 *                              components of .
 *
 *                  For use by applications.
 *
 * See these files for more details.
 */

#include 
#include 

#ifdef __cplusplus
extern "C" {
#endif

/*
 * Basic / Extended integer types
 *
 * The following defines the basic fixed-size integer types.
 *
 * Implementations are free to typedef them to Standard C integer types or
 * extensions that they support. If an implementation does not support one
 * of the particular integer data types below, then it should not define the
 * typedefs and macros corresponding to that data type.  Note that int8_t
 * is not defined in -Xs mode on ISAs for which the ABI specifies "char"
 * as an unsigned entity because there is no way to define an eight bit
 * signed integral.
 */
#if defined(_CHAR_IS_SIGNED)
typedef char                    int8_t;
#else
#if defined(__STDC__)
typedef signed char             int8_t;
#endif
#endif
typedef short                   int16_t;
typedef int                     int32_t;
#ifdef  _LP64
#define _INT64_TYPE
typedef long                    int64_t;
#else   /* _ILP32 */
#if defined(_LONGLONG_TYPE)
#define _INT64_TYPE
typedef long long               int64_t;
#endif
#endif

typedef unsigned char           uint8_t;
typedef unsigned short          uint16_t;
typedef unsigned int            uint32_t;
#ifdef  _LP64
typedef unsigned long           uint64_t;
#else   /* _ILP32 */
#if defined(_LONGLONG_TYPE)
typedef unsigned long long      uint64_t;
#endif
#endif

Blocks and Variables

对于 Block 的用法，一定要注意下面的红字。

如果使用的是自定义的 Block，并且这个 Block 在某个对象的生命周期内会一直存在，一定要注意红字，遵循规则。
否则，则很容易出现 retain cycle。
所以，现在官方的 Api 提供的 block 使用，也是类似动画这种 block，它只在某个对象的生命周期内出现瞬间，然后销毁，这样就不会有 retain cycle。

Objective-C Objects

1. In a manually reference-counted environment, local variables used within the block are retained when the block is copied. Use of instance variables within the block will cause the object itself to be retained. If you wish to override this behavior for a particular object variable, you can mark it with the __block storage type modifier.
2. If you are using ARC, object variables are retained and released automatically as the block is copied and later released.

Note In a garbage-collected environment, if you apply both __weak and __block modifiers to a variable, then the block will not ensure that it is kept alive.

1. If you use a block within the implementation of a method, the rules for memory management of object instance variables are more subtle:
2. If you access an instance variable by reference, self is retained;
3. If you access an instance variable by value, the variable is retained.

The following examples illustrate the two different situations:

dispatch_async(queue, ^{

      // instanceVariable is used by reference, self is retained

      doSomethingWithObject(instanceVariable);
  });

  id localVariable = instanceVariable;
  dispatch_async(queue, ^{

      // localVariable is used by value, localVariable is retained (not self)

      doSomethingWithObject(localVariable);
  });

C++ Objects
In general you can use C++ objects within a block. Within a member function, references to member variables and functions are via an implicitly imported this pointer and thus appear mutable. There are two considerations that apply if a block is copied: 

iOS 编译静态库

1. 静态库有两种：第一种为在真机上使用的静态库，第二种为在模拟器中使用的静态库。
2. 静态库的创建，创建一个新的Project 或者 在已有的Project添加Target，只要在添加时选择Framework&Library，下面有一个 Cocoa Touch Static Library。
3. 检测编译好的静态库，可以使用在什么平台架构下。命令 lipo -info /path/to/your/library.a 即可看到此库使用的架构 i386、x86_64、armv6、armv7等等。
4. 将真机和模拟器的静态库合并，利用 lipo 将这两个文件打包成一个通用的a文件。命令如下：lipo -create arm/libstaticlib.a i386/libstaticlib.a -output libstaticlib.a。现在我们这个静态库，支持的构架已经是 armv6 armv7 i386了。
5. 如果你想直接使用 <>, 如 #include 。需要设置search hearder path 选项，告诉xcode去哪里寻找头文件。如果你的库的安装路径是/usr/AAA的话，那AAA下肯定有include , lib两大文件夹。 那你在选项中，请直接填/usr/AAA，不需要多此一举选择到include文件夹中，苹果会自动替你搜索进去。
6. 创建一个空的静态库后，添加你要编译的源文件到 Build Phases 的 Compile Sources 里，如果你想创建 .a 文件时，同时也生成include头文件夹，就添加头文件到 Build Phases 的 CopyFiles 中

Everything you need to know about ARC

http://www.learn-cocos2d.com/2011/11/everything-know-about-arc/#third-party-libraries

Development Requirements for ARC apps

• Xcode 4.2
• Apple LLVM compiler 3.0 (Build Setting)
• iOS app development: Snow Leopard 10.6 and newer
• Mac app development: Lion 10.7 and newer

There’s no ARC development for Mac apps under Snow Leopard! And Xcode 4.1 and earlier don’t come bundled with the Apple LLVM 3.0 compiler (Clang) which is the first Clang compiler version to support ARC.

Minimum Deployment Targets for ARC apps

• iOS devices: iOS 4.0 or newer
• Mac computer: Mac with 64-Bit processor running Snow Leopard 10.6 or newer.

Mac OS X apps with ARC enabled are always 64-Bit apps. You can not build 32-Bit ARC apps.

Macs with at least a Core 2 Duo CPU will be able to run 64-Bit apps. Macs with the 32-Bit Core Duo or Core Solo (Yonah) CPUs can’t run ARC apps. The 32-Bit Macs have been discontinued near the end of 2006, with the exception of the Core Duo Mac mini which was discontinued in August 2007.

Required Deployment Targets with zeroing weak references

• iOS devices: iOS 5.0 or newer
• Mac computer: Lion 10.7 or newer.

You can not “accidentally” use zeroing weak references without noticing it. You will either have to use the @property keyword weak or the __weak keyword when declaring a variable. If you use one of these keywords, the compiler will generate an error if you haven’t yet set the deployment target accordingly to either iOS 5.0 or Mac OS X 10.7.

All Macs capable of running Lion 10.7 can run 64-Bit ARC apps. Lion is the first 64-Bit-only Mac OS X operating system.

How to enable ARC in your project

You will need to make sure that the Build Setting for Compiler for C/C++/Objective-C is set toApple LLVM compiler 3.0.

This is particularly important for existing projects which may still be set to use LLVM GCC 4.2 or another compiler. If you don’t select the LLVM 3.0 compiler, none of the ARC related settings will show up in the Build Settings list.

With LLVM 3.0 selected as compiler the Build Setting Objective-C Automatic Reference Countingcan be set to YES. If you create a new project from an Xcode template you will also have the option to enable ARC in the new project wizard by selecting Use Automatic Reference Counting.

Compile errors after switching to LLVM 3.0

If you previously were using a different compiler, it is absolutely possible that LLVM 3.0 will generate new warnings and errors where there were none before, even with ARC disabled. This is the LLVM 3.0 compiler which got a little better at detecting potentially dangerous code.

I recommend to first build your app with LLVM 3.0 compiler and ARC disabled, to make sure all LLVM 3.0 related issues have been fixed before attempting to convert your code to ARC.

For example, LLVM 3.0 is now able to detect some potential “array out of bounds” issues thanks to the SAFECode project, and it’s a bit more nagging when it comes to casting one type to another, in particular related to format strings. Most of these issues are easy to resolve. In fact, LLVM 3.0 helps you determine where the issue is through expressive diagnostics, but unfortunately Xcode hides that pretty well from the user.

To see expressive diagnostics in Xcode, go to the Log Navigator (Command+7) and select the most recent log with the warning or error in it:

Then click the details button to the right of the warning/error symbol (just above the “more” link) to see the LLVM 3.0 expressive diagnostics statement, pointing exactly to the character or range of characters causing the issue:

Getting third party libraries to build with ARC

The first thing to do with incompatible third party libraries is to build them as a separate static library. Take for example Cocos2D whose Xcode project template simply puts all of the Cocos2D code into your project’s target. It would be a nightmare to try and update the entire Cocos2D library code to support ARC. While you can disable ARC for individual source code files with the -fno-objc-arc compiler flag, it would be tedious to do so for more than just a few files.

Once you build the Cocos2D source code separately as a static library, the required changes are limited to three places: CCDirector (remove NSAutoreleasePool), CCActionManager (add __unsafe_unretained) and CCArray (add __unsafe_unretained, refactor inline code into implementation file). Tiny Tim Games have outlined these changes and provide a fork of cocos2d-iphone that is compatible with ARC – if built as a static library.

By the way, Kobold2D is fully compatible with ARC. In fact it has ARC enabled by default in all projects while retaining full backwards compatibility if you don’t want to use ARC!

If building a static library still causes too many issues with that library, then go to that library’s forum, look for ARC related posts and/or request ARC support. Many open source libraries don’t even compile cleanly with LLVM 3.0 yet, let alone support ARC. This needs to change quickly because library developer support directly influences the adoption rate of ARC.

Converting an existing app to ARC

There’s an app for that!

Well, to be precise there’s a menu option in Xcode 4.2 for that. You’ll find it if you open your project in Xcode and choose Edit -> Refactor -> Convert to Objective-C ARC….

You will be presented with a list of targets that you want to convert. Make sure you don’t select any static library that you haven’t written yourself. Static libraries can be linked to an ARC-enabled app without actually having to be ARC compatible. Although you may have to make some changes to the library’s header files. More on that later.

“Cannot Convert to Objective-C ARC”

Oh dear!

In some cases automatic conversion is not as automatic as you’d hope it would be. In many cases this is because of incompatible static libraries.

In most cases the problems are related solely to id or other pointer types stored in a C struct, passing pointers to and from C/C++ code or the use of the NSAutoreleasePool class which is not available when building an app with ARC enabled. Read on for solutions to the most common issues.

Fixing pointer types in C structs

ARC will complain about a C struct that stores pointer types:

[cc lang="cpp"]typedef struct {
id someObject;
void* somePointer;
SomeClass* someClassInstance;
} someStruct;
[/cc]

This is easy enough to fix by prepending the pointer types with the __unsafe_unretained keyword:

[cc lang="cpp"]typedef struct {
__unsafe_unretained id someObject;
__unsafe_unretained void* somePointer;
__unsafe_unretained SomeClass* someClassInstance;
} someStruct;
[/cc]

This tells ARC that the memory for these pointer types is managed manually, ie. the old-school way. Henceforth the pointer type is “unretained” by ARC, and it is “unsafe” because the memory may be deallocated but the pointer isn’t set to nil automatically, which can possibly create a dangling pointer. That’s the way it has been all the time, ARC just wants you to expressly admit that you’re doing something that is considered unsafe.

If your code worked fine before, __unsafe_unretained will simply make sure it compiles under ARC. But for new code you should avoid having to use that keyword. One option is to change all C structs into lightweight Objective-C classes with properties.

Fixing C/C++ pointer transfers with bridged casts

In cases where you’re passing id or object pointers to and from C/C++ code, the compiler will complain about the conversion and suggest a bridged cast:

[cc lang="cpp"]// Assigning sprite to Box2D userdata
b2BodyDef bodyDef;
bodyDef.userData = aSprite; // ERROR!

// Getting the userdata sprite from Box2D
CCSprite* sprite = (CCSprite*)body->GetUserData(); // ERROR!
[/cc]

Again this is easy to fix by properly casting the pointer type and prepending it with the __bridgekeyword:

[cc lang="cpp"]// Assigning sprite to Box2D userdata
b2BodyDef bodyDef;
bodyDef.userData = (__bridge void*)aSprite;

// Getting the userdata sprite from Box2D
CCSprite* sprite = (__bridge CCSprite*)body->GetUserData();
[/cc]

The __bridge keyword simply means that the pointer is transferred from or to Objective-C land unchanged. ARC will neither retain nor release that pointer.

The special keywords __bridge_transfer and __bridge_retain should only be used when dealing with toll-free bridged Core Foundation objects where you would normally have to call CFRetainand/or CFRelease to manage the Core Foundation object’s lifetime.

Fixing NSAutoreleasePool with @autoreleasepool

ARC replaced the NSAutoreleasePool class with the @autoreleasepool compiler directive.

You must replace code using NSAutoreleasePool:

[cc lang="cpp"]NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
// create some temporary objects here …
[pool release];
pool = nil;
[/cc]

With the @autoreleasepool keyword:

[cc lang="cpp"]@autoreleasepool
{
// create some temporary objects here …
}
[/cc]

Methods you can’t call (or override) anymore

You will have to remove all calls to these methods without substitution:

• retain
• retainCount
• release
• autorelease
• dealloc

You also can’t use the retain keyword with properties anymore. Instead, use the strong keyword.

You can no longer override these methods in your class:

• retain
• retainCount
• release
• autorelease

You can still override -(void) dealloc {}

You can not call dealloc but you can still override the -(void) dealloc {} method. This is useful to release the memory of C/C++ objects. For example you still need to be able to free the memory of a Box2D world instance. Similarly there are instances where you need to remove self as the delegate of another class when the self class is deallocated.

There’s one particular habit that you need to let go of. Since you can’t call dealloc, you also must not call [super dealloc]. The compiler will generate the [super dealloc] call behind the scenes automatically.

Property naming restriction

You can not create a property whose name begins with “new”. That’s all.

New Property keywords: strong and weak

The @property keyword strong is synonymous to retain:

[cc lang="cpp"]// synonym for: @property(retain) MyClass *myObject;
@property(strong) MyClass *myObject;
[/cc]

Whereas weak is similar to assign, except that a weak property will be set to nil automatically when the object is deallocated (hence: zeroing weak reference):

[cc lang="cpp"]// similar to “@property(assign) MyClass *myObject;”
@property(weak) MyClass *myObject;
[/cc]

Zeroing weak references are only available when targeting iOS 5.0 and newer, or Mac OS X Lion 10.7 and newer.

ARC forbids synthesizing a readonly property without ownership qualifier

Normally, when you declare a readonly property, it doesn’t matter what the storage type is (retain, assign, copy) since readonly properties can’t be assigned to. Take this one for example:

[cc lang="cpp"]@property (nonatomic, readonly) MyView* myViewController;
[/cc]

Now with ARC, if you don’t declare the ivar manually (@synthesize can generate ivars) you will encounter a strange error on the @synthesize line, stating:

error: ARC forbids synthesizing a property of an Objective-C object with unspecified ownership or storage attribute [4]

As odd as it may seem, in this case you will have to specify the storage keyword on a readonly property, by adding either strong or weak:

[cc lang="cpp"]@property (strong, nonatomic, readonly) MyView* myViewController;[/cc]

This specifies the ownership qualifier of the ivar through the @property declaration. The alternative would be to declare the ivar manually, which will force the property to use the same ownership qualifier as the ivar.

For experts: detecting at compile-time if ARC is enabled

If you need to find out whether your code is built with or without ARC, for example if you’re the developer of a public library, you can use the following macros to determine whether ARC is enabled at compile time.

[cc lang="cpp"]// define some LLVM3 macros if the code is compiled with a different compiler (ie LLVMGCC42)
#ifndef __has_feature
#define __has_feature(x) 0
#endif
#ifndef __has_extension
#define __has_extension __has_feature // Compatibility with pre-3.0 compilers.
#endif

#if __has_feature(objc_arc) && __clang_major__ >= 3
#define ARC_ENABLED 1
#endif // __has_feature(objc_arc)
[/cc]

For experts: allow use of ARC keywords with ARC disabled

As a library author, one of the worst things you could do to ensure backward compatibility of your library is to #ifdef every ARC-specific keyword and write every such line twice: once without the ARC keyword, once with the ARC keyword.

[cc lang="cpp"]// BAD PRACTICE!!
#ifdef ARC_ENABLED
void* pointerToSelf = (__bridge void*)self;
#else
void* pointerToSelf = (void*)self;
#endif // ARC_ENABLED
[/cc]

Instead I propose to simply define the ARC keywords as “noop” statements when ARC is unavailable. Thus your code using ARC keywords will still compile under Xcode 4.1 or LLVM GCC4.2, and you don’t need to #ifdef anything related to those keywords.

[cc lang="cpp"]// not using clang LLVM compiler, or LLVM version is not 3.x
#if !defined(__clang__) || __clang_major__ < 3

#ifndef __bridge
#define __bridge
#endif
#ifndef __bridge_retained
#define __bridge_retained
#endif
#ifndef __bridge_transfer
#define __bridge_transfer
#endif
#ifndef __autoreleasing
#define __autoreleasing
#endif
#ifndef __strong
#define __strong
#endif
#ifndef __weak
#define __weak
#endif
#ifndef __unsafe_unretained
#define __unsafe_unretained
#endif

#endif // __clang_major__ < 3
[/cc]

Now it is safe to write code like this regardless of whether ARC is available or not, because compilers that don't support ARC will only see the regular (void*) cast:

[cc lang="cpp"]void* pointerToSelf = (__bridge void*)self;
[/cc]

Myth: ARC has not been proven reliable

As if automatic memory management has some magic property that occasionally goes bonkers.

ARC still follows the same alloc, retain, release cycle of Objective-C code. There are no ambiguities and no special cases when it comes to applying the few and simple alloc-retain-release rules. This is entirely deterministic and the compiler can do that job just as well, no, better than you. There’s nothing inherently and potentially unreliable about ARC.

If you’ve heard about issues with ARC, then they’re likely related to situations where an ARC app interfaces with the Core Foundation or other C/C++ code. In those situations you will have to correctly apply the various new keywords (bridge casts for the most part). Make a mistake there and you got yourself a problem. But that’s not the fault of ARC. The same goes for retain cycles, which are still a possibility in ARC apps.

I also bet my life that Apple wouldn’t announce, promote and implement ARC for iOS and Mac OS X apps if it hadn’t been proven stable. If that doesn’t convince you, then maybe this quote of the ARC developer Chris Lattner does:

ARC is carefully built to be a reliable programming model that errs on the side of producing a compiler error instead of silently producing a runtime memory problem.

That also explains a bit why you’ll see more (initial) compile errors with ARC enabled.

Myth: ARC takes away control over Memory Management

Some argue that ARC takes away your control over memory management. That in turn would lead to less than optimal runtime performance. Henceforth ARC is bad and should be avoided.

You could apply the same pointless argument to power steering. There are some die-hards who would rather not have power steering, just because of some subjective feeling about losing control. Ignore these people! Not because they’re wrong, they are correct in some circumstances – it’s just that those circumstances are rare, very specialized and require a high level of skill that the remaining 99% of users simply don’t have, nor would want to exercise.

And even if you do have the skills, you’re still subject to errors of judgement or other human errors. So even the experts will benefit from using ARC (or power steering for that matter) in everyday situations.

Some people who argue that ARC takes away control don’t seem to understand what ARC does. Memory Management is about the lifetime of objects, whether the memory management is automated with ARC or manual. If an object’s lifetime is throughout the entire scene (view, level, app, etc) then that object is allocated once when the scene is initialized, and deallocated when the scene is deallocated. Whether you do this manually, or automatically, results in the same behavior of the application.

Everyone needs to understand that ARC is deterministic. It is not to be mistaken for garbage collection! Garbage collection cycles can kick in at any random moment in time when the garbage collector finds it necessary to free up some memory. In a garbage collected environment, such as C#, you do lose some control over memory management and in some situations this leads to unsteady runtime performance. But not with ARC.

To say that ARC removes control over memory management is just plain wrong and probably based on the assumption that ARC is equal to garbage collection. It may also stem from the “false positives” that the Clang Static Analyzer produces, which may have instilled doubt about “automated” Clang technologies in general, even though static analysis and ARC are completely separate pieces of technology.

Either way, in some cases you may need to exercise control over memory management and with ARC you can still do that, usually with the new ARC keywords strong and weak, as well as bridge casts for pointers that are crossing boundaries from or to C/C++ land. As long as you are aware of the lifetime of your objects you will have no problem influencing how the lifetime of objects is managed by ARC.

ARC always allocates and releases an object’s memory at the same point in time in the same situation (deterministic). Thus Objective-C with ARC can not be compared to garbage collected languages like C#. If you see someone comparing ARC with C#, please send them this link.

ARC Reference Documentation and related articles

Further reading for those who want to learn more about ARC in detail.

• Clang: Automatic Reference Counting documentation
• Apple: Transitioning to ARC Release Notes
• Apple: Xcode New Features User Guide: Automatic Reference Counting
• Mike Ash: Friday Q&A about Automatic Reference Counting
• StackOverflow: How does automatic reference counting work?
• StackOverflow: What are the advantages and disadvantages of using ARC?
• StackOverflow: What is the difference between automatic reference counting and garbage collection?
• informIT: Automatic Reference Counting in Objective-C, Part 1
• informIT: Automatic Reference Counting in Objective-C, Part 2 The Details
• Mike Ash: Zeroing weak references without ARC
• Github: Support for zeroing weak references on iOS 4 / OS X 10.6

Please let me know if I forgot to add anything about ARC! Especially if you think it should be common knowlARCdge. And don’t forget to retweet this article if you like it, thanks!

ARC

http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1

Transitioning to ARC Release Notes

https://developer.apple.com/library/ios/#releasenotes/ObjectiveC/RN-TransitioningToARC/Introduction/Introduction.html#//apple_ref/doc/uid/TP40011226

1. ARC is supported in Xcode 4.2 for OS X v10.6 and v10.7 (64-bit applications) and for iOS 4 and iOS 5. Weak references are not supported in OS X v10.6 and iOS 4.
2. ARC 需要知道它的作用域，这样才能正确的释放这个对象。
3. sortedResults 在 @autoreleasepool 的作用域中定义， 在它的外部不能被访问到。 为了修正这个问题，你需要将变量的定义放到创建 NSAutoreleasePool 的上面。
4. You also need to take care with objects passed by reference. The following code will work:

   NSError *error;

   BOOL OK = [myObject performOperationWithError:&error];

   if (!OK) {

   // Report the error.

   // ...

   However, the error declaration is implicitly:

   NSError * __strong e;

   and the method declaration would typically be:

   -(BOOL)performOperationWithError:(NSError * __autoreleasing *)error;

   The compiler therefore rewrites the code:

   NSError * __strong error;

   NSError * __autoreleasing tmp = error;

   BOOL OK = [myObject performOperationWithError:&tmp];

   error = tmp;

   if (!OK) {

   // Report the error.

   // ...

   The mismatch between the local variable declaration (__strong) and the parameter (__autoreleasing) causes the compiler to create the temporary variable. You can get the original pointer by declaring the parameter id __strong * when you take the address of a __strong variable. Alternatively you can declare the variable as __autoreleasing.
   
   
5. You cannot give an accessor a name that begins with new. This in turn means that you can’t, for example, declare a property whose name begins with new unless you specify a different getter:

   // Won't work:

   @property NSString *newTitle;

   // Works:

   @property (getter=theNewTitle) NSString *newTitle;

6. Use Lifetime Qualifiers to Avoid Strong Reference Cycles

   You can use lifetime qualifiers to avoid strong reference cycles. For example, typically if you have a graph of objects arranged in a parent-child hierarchy and parents need to refer to their children and vice versa, then you make the parent-to-child relationship strong and the child-to-parent relationship weak. Other situations may be more subtle, particularly when they involve block objects.
   In manual reference counting mode, __block id x; has the effect of not retaining x. In ARC mode, __block id x; defaults to retaining x (just like all other values). To get the manual reference counting mode behavior under ARC, you could use __unsafe_unretained __block id x;. As the name__unsafe_unretained implies, however, having a non-retained variable is dangerous (because it can dangle) and is therefore discouraged. Two better options are to either use __weak (if you don’t need to support iOS 4 or OS X v10.6), or set the __block value to nil to break the retain cycle.
   The following code fragment illustrates this issue using a pattern that is sometimes used in manual reference counting.

   MyViewController *myController = [[MyViewController alloc] init…];

   // ...

   myController.completionHandler = ^(NSInteger result) {

   [myController dismissViewControllerAnimated:YES completion:nil];

   };

   [self presentViewController:myController animated:YES completion:^{

   [myController release];

   }];

   As described, instead, you can use a __block qualifier and set the myController variable to nil in the completion handler:

   MyViewController * __block myController = [[MyViewController alloc] init…];

   // ...

   myController.completionHandler = ^(NSInteger result) {

   [myController dismissViewControllerAnimated:YES completion:nil];

   myController = nil;

   };

   Alternatively, you can use a temporary __weak variable. The following example illustrates a simple implementation:

   MyViewController *myController = [[MyViewController alloc] init…];

   // ...

   MyViewController * __weak weakMyViewController = myController;

   myController.completionHandler = ^(NSInteger result) {

   [weakMyViewController dismissViewControllerAnimated:YES completion:nil];

   };

   For non-trivial cycles, however, you should use:

   MyViewController *myController = [[MyViewController alloc] init…];

   // ...

   MyViewController * __weak weakMyController = myController;

   myController.completionHandler = ^(NSInteger result) {

   MyViewController *strongMyController = weakMyController;

   if (strongMyController) {

   // ...

   [strongMyController dismissViewControllerAnimated:YES completion:nil];

   // ...

   }

   else {

   // Probably nothing...

   }

   };

   In some cases you can use __unsafe_unretained if the class isn’t __weak compatible. This can, however, become impractical for nontrivial cycles because it can be hard or impossible to validate that the __unsafe_unretained pointer is still valid and still points to the same object in question.
   
   

strong 用来修饰强引用的属性

@property (strong) SomeClass * aObject; 
对应原来的
@property (retain) SomeClass * aObject; 和 @property (copy) SomeClass * aObject; 

weak 用来修饰弱引用的属性
@property (weak) SomeClass * aObject; 
对应原来的 
@property (assign) SomeClass * aObject; 

__weak, __strong 用来修饰变量，此外还有 __unsafe_unretained, __autoreleasing 都是用来修饰变量的。
__strong 是缺省的关键词。
__weak 声明了一个可以自动 nil 化的弱引用。
__unsafe_unretained 声明一个弱应用，但是不会自动nil化，也就是说，如果所指向的内存区域被释放了，这个指针就是一个野指针了。
__autoreleasing 用来修饰一个函数的参数，这个参数会在函数返回的时候被自动释放。