iPhone开发之深入浅出 (3) — ARC之前世今生

前两节我们对 ARC(Automatic Reference Counting) 有了一个基本的理解，但是 ARC 是怎么产生的，为什么苹果要在其最新的 iOS/Mac OS X 上导入该框架？ 如果不理解其背后的基本原理，只是死记硬背那些规则/方法，是毫无意义的。就像我们从小接受的填鸭式教育，基本上到后来都还给老师了。

本节，我们先来看看 ARC 产生之前的 Objective-C 内存管理世界，然后再来看看导入 ARC 后，新的 LLVM 编译器在背后为我们做了什么。

Objective-C 内存管理

和许多面向对象语言一样，Objective-C 中内存管理的方式其实就是指 引用计数 （Reference Counting）的使用准则。如下图所示，对象生成的时候必定被某个持有者拿着，如果有多个持有者的话，其引用计数就会递增；相反失去一个持有者那么引用计数即会递减，直到失去所有的持有者，才真正地从内测中释放自己。

基本原则

内存管理的依循下面的基本原则

• 自己生成的对象，那么既是其持有者
• 不是自己生成的对象，也可成为其持有者（一个对象可以被多个人持有）
• 如果不想持有对象的时候，必须释放其所有权
• 不能释放已不再持有所有权的对象

结合 Objective-C 语言中的方法，我们来看看基本的内存管理。

实际上这些函数并不能说是 Objective-C 语言所特有的，而是 OS X / iOS 系统库中包含的基类函数；具体说就是 Cocoa Framework::Foundation::NSObject 基类的成员函数。

Objective-C 语言内部严格遵守上面表格中的定义；首先是 alloc/new/copy/mutableCopy 这几个函数，并且是alloc/new/copy/mutableCopy 开头的函数，比如：allpcMyObject/newTheObject/copyThis/mutableCopyTheObject 等都必须遵循这个原则。

反而言之，如果不是 alloc/new/copy/mutableCopy 开头的函数，而且要返回对象的话，那么调用端只是生成对象，而不是其持有者。

1
2
3
4
5
6
7
8
9
10
11

-(id)allocObject {
    /*
     * 生成对象并拥有所有权
     */
    id obj = [[NSObject alloc] init];

    /*
     * 自己一直是持有对象状态
     */
    return obj;
}

如上面的例子，alloc 生成的对象，其所有权会传递给函数的调用端；即满足了 alloc 开头函数的命名规则。

再看下面的例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

-(id)object {
    id obj = [[NSObject alloc] init];

    /*
     * 自己一直是持有对象状态
     */

    [obj autorelease];

    /*
     * 对象还存在，只是并不持有它的所有权
     */

    return obj;
}

这里我们用到了 autorelease 函数。它的作用既是将对象放入 NSAutoreleasePool 中，由其来维护其生命周期。换句话说对象的持有者是 NSAutoreleasePool；上面的例子中，object 返回后，调用者将不持有其所有权。（除非再调用 retain。）

用 autorelease 的一个理由既是让程序员来控制对象的存活周期，而不像 C/C++ 等语言中，出栈后，栈中数据都被自动废弃，或者用 { } 框住的自动变量，当出了范围就看不到了。在 Objective-C 中，只有当 [pool drain] 被调用的时候，才清空 pool 中所有登录的对象实体，在这之前，你可以像往常一样正常使用对象。

当然可以想象得到的，如果一个程序只有一个 NSAutoreleasePool，并在 main 中声明，程序结束时才 [pool drain]/[pool release] 的话，那么所有 autorelease 的对象都将塞满这个 pool，会耗掉系统大部分内存。所以，使用 NSAutoreleasePool 的时候也尽量建议局部使用，比如下面的循环。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

for (i=0; i < 100; i++) {
    NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

    // 下面的函数由于不属于 alloc/new/copy/mutableCopy 范畴的函数，所以都使用了 autorelease
    NSMutableArray* array = [NSMutableArray array];
    NSString *str = [NSString stringWithFormat:@"TestCode"];

    /*
     * 其他使用autorelease定义的对象
     */
    Test *test = [[[Test alloc] init] autorelease];

    // 通过下面的函数，可以随时监控pool中的对象
    // iOS以外的运行库的情况下，也可以使用 _objc_autoreleasePoolPrint() 私有函数，只是需要下面的声明
    // extern void _objc_autoreleasePoolPrint();
    [NSAutoreleasePool showPools];

    // 这里把所有pool中的对象都释放掉
    [pool release];
}

当然 NSAutoreleasePool 也可以嵌套，基本上都依存大括号规则。

编程准则

基于以上原则，在 ARC 诞生之前，我们往往用下面准则来写代码。

生成对象时，使用autorelease

一般情况下，我们这样生成对象并使用

1
2
3

MyController* controller = [[MyController alloc] init];
// ......
[controller release];

如果在 [controller release] 之前函数return了怎么样，内存泄露了不是；为了防患于未然，一般像下面一样 生成对象时，使用autorelease。这样一来，该对象就被自动加入到最近的那个 pool 中。

1

MyController* controller = [[[MyController alloc] init] autorelease];

对象代入时，先autorelease后再retain

对象代入的时候，如果之前不将变量所持有的对象释放，那么很可能引起内存泄露。比如下面的代码

1
2
3
4
5
6
7
8
9
10
11
12

{
  _member = [[TempValue alloc] init];
}

- (void)setValue:(TempValue *)value {
  _member = value;
  // 这时，之前持有的对象因为没有 release 而引起内存泄露
  // 当然，先 [_member release] 后再代入也是可以的，
  // 但是当与「对象在函数中返回时」的问题一同考虑时，
  // 如果没有 return [[object retain] autorelease] 的保证，这里即使 [_member release]也是百搭
  // 详细的解释见下
}

鉴于以上原因，我们将原先的对象先autorelease后再将新对象retain代入。

1
2
3
4
5
6
7
8
9
10

{
  _member = [[TempValue alloc] init];
  // 这里，即使使用【生成对象时，使用autorelease】的准则，也没有关系
  // 使用autorelease一次就将制定对象放入pool中，放几次[pool drain]的时候就释放几次
}

- (void)setValue:(TempValue *)value {
  [_member autorelease];
  _member = [value retain];
}

该原则遵循 Failed Self 的原则，虽然从性能上看有所损耗但是保证了代码质量。

对象在函数中返回时，使用return [[object retain] autorelease]

严格地说，是除 alloc/new/copy/mutableCopy 开头函数以外的函数中，有对象放回时，使用return [[object retain] autorelease]。

我们结合下面的例子来说明，并总结出该问题的几种解决方案

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

@implementation FooClass

- (void)setObject:(MyObject *)object;
 {
     // 这里故意没有使用 autorelease，以便说明问题
     [_object release];
     _object = [object retain];
 }

- (id)object;
 {
     return _object;
 }

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

@end

@implementation BarClass

- (void)doStuff;
 {
    FooClass * foo = [[FooClass alloc] init];

    // 创建第一个对象，引用计数 = 1
    MyObject * firstObject = [[MyObject alloc] init];
    // setObject中由于 [object retain] ，引用计数 = 2
    [foo setObject:firstObject];
    // 释放一次，引用计数 = 1；这之后对象有正确的所有权属性
    [firstObject release];

    // 通过非 alloc/new/copy/mutableCopy 开头函数得到对象
    // anObject 指向第一个对象，但是并没有其所有权，对象引用计数 = 1
    MyObject * anObject = [foo object];
    [anObject testMethod];

    // 创建第二个对象
    MyObject * secondObject = [[MyObject alloc] init];
    // setObject中由于 [_object release]; 第一个对象引用计数 = 0，内存被释放
    [foo setObject:secondObject];
    [secondObject release];

    // 程序在这里崩溃了，因为 anObject 指向了一个空地址
    [anObject testMethod];
}

@end

从结论我们来看看该问题的几种可行的解决方案；各种方案中没有列出的代码与原先代码一致。

生成对象时，使用autorelease

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

@implementation BarClass

- (void)doStuff;
 {
    FooClass * foo = [[FooClass alloc] init];

    MyObject * firstObject = [[[MyObject alloc] init] autorelease];
    [foo setObject:firstObject];

    MyObject * anObject = [foo object];
    [anObject testMethod];

    MyObject * secondObject = [[[MyObject alloc] init] autorelease];
    [foo setObject:secondObject];

    [anObject testMethod];
}

@end

对象生成时，即被放入最近的 pool 中，不需要人为特殊的维护，对象的生命周期将被延续，出 {} 范围之时即对象释放之际。

对象代入时，先autorelease后再retain

1
2
3
4
5
6
7
8
9
10
11

- (void)setObject:(MyObject *)object;
 {
     [_object autorelease];
     _object = [object retain];
 }

- (id)object;
 {
     // 遵循非 alloc/new/copy/mutableCopy 开头的函数，不赐予所有权原则
     return _object;
 }

同样的，对象被放入最近的 pool 中，第二次 setObject 后对象引用计数仍为1， pool 清空时才执行最后一次对象release，从而保证了代码的正确性。

对象在函数中返回时，使用return [[object retain] autorelease];

1
2
3
4
5
6
7
8
9
10
11

- (void)setObject:(MyObject *)object;
 {
     [_object release];
     _object = [object retain];
 }

- (id)object;
 {
     // 遵循非 alloc/new/copy/mutableCopy 开头的函数，不赐予所有权原则
     return [[_object retain] autorelease];
 }

好不容易回到了本小节要说明的方法；可以看到这是从另一个角度解决了该问题：[foo object] 的时候保证引用计数是2，并将对象放入pool中维护。

总结上面上面3中方法，虽说是从不同角度入手解决了这个问题，但是基本原则不变，利用 NSAutoreleasePool 机制帮程序员维护代码，管理内存。

如果你觉得3种编码原则怎么搭配使用，在什么样的场合下选择比较麻烦，不要紧，都用就得了。我们牺牲的只是 NSAutoreleasePool 中的一些内存，一小许性能损失罢了，这总比我们的程序崩溃了强。

ARC 诞生

ARC 是什么我不需要再解释，若有不明白，可以看iPhone开发之深入浅出 (1) — ARC是什么。

ARC 严格遵守 Objective-C 内存管理的基本原则

• 自己生成的对象，那么既是其持有者
• 不是自己生成的对象，也可成为其持有者（一个对象可以被多个人持有）
• 如果不想持有对象的时候，必须释放其所有权
• 不能释放已不再持有所有权的对象

并从编译器角度维护了该原则，比如如果不是 alloc/new/copy/mutableCopy 开头的函数，编译器会将生成的对象自动放入 autoReleasePool 中。如果是 __strong 修饰的变量，编译器会自动给其加上所有权。等等，详细，我们根据不同的关键字来看看编译器为我们具体做了什么。并从中总结出 ARC 的使用规则。

__strong

我们先来看看用 __strong 修饰的变量，以及缺省隐藏的 __strong 情况。

1
2
3
4
5
6
7
8
9
10
11
12
13

{
    /*
     * 生成对象并拥有所有权
     */
    id __strong obj = [[NSObject alloc] init];

    /*
     * 自己一直是持有对象状态
     */
}
    /*
     * 变量出生命周期时，失去全部所有者，对象内存空间被释放
     */

这种情况毫无悬念，缺省使用 alloc/new/copy/mutableCopy 开头的函数也是这样的结果。并且在这里，编译器帮我们自动的调用了对象的 release 函数，不需要手工维护。再看看下面的情况。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

{
    /*
     * 生成对象但是并没有其所有权
     */
    id __strong obj = [NSMutableArray array];

    /*
     * 由于变量声明是强引用，自己一直是持有对象状态
     * 编译器根据函数名，再将该对象放入 autoreleasepool 中
     */
}
    /*
     * 变量出生命周期时，失去全部所有者，对象内存空间被释放
     */

由上，虽然不是用 alloc/new/copy/mutableCopy 开头的函数得到的对象，由于是强参照，我们任然成为对象的持有者。而这，正是编译器帮我们做到的。

具体做的是什么呢？其实就是【对象在函数中返回时，使用return [[object retain] autorelease]】所描述的；如果你反汇编一下ARC生成的代码，可以看到这时会自动调用名为 objc_retainAutoreleaseReturnValue 的函数，而其作用和 [[object retain] autorelease] 一致。编译器通过函数名分析，如果不是 alloc/new/copy/mutableCopy 开头的函数，自动加入了这段代码。

另外，缺省 __strong 修饰的变量，对象代入的时候也正确地保证对象所有者规则；代入新对象时，自动释放旧对象的参照，代入nil的时候，表示释放当前对象的强参照。

__weak

虽然大部分场合，大部分问题使用 __strong 来编码就足够了；但是为了解决循环参照的问题 __weak 关键字修饰【弱参照】变量就发挥了左右。关于循环参照的问题，准备在以后的博文中介绍；今天，主要看看编译器在背后怎么处理 __weak 变量的。

__weak 声明的变量其实是被放入一个weak表中，该表和引用计数的表格类似，是一个Hash表，都是以对象的内存地址做key，同时，针对一个对象地址的key，可以同时对应多个变量的地址。

当一个 __weak 所指对象被释放时，系统按下面步骤来处理

• 从weak表中，通过对象地址（key）找到entry
• 将entry中所有指向该对象的变量设为nil
• 从weak表中删除该entry
• 从对象引用计数表中删除对象entry(通过通过对象地址找到)

另外，当使用 __weak 修饰的变量的时候，变量将放入 autoreleasepool 中，并且用几次放几次。比如下面的简单例子。

1
2
3
4
5
6
7
8

{
    id __weak o = obj;
    NSLog(@"1 %@", o);
    NSLog(@"2 %@", o);
    NSLog(@"3 %@", o);
    NSLog(@"4 %@", o);
    NSLog(@"5 %@", o);
}

这里我们用了5次，那么pool中就被登录了5次；从效率上考虑这样当然不是很好，可以通过代入 __strong 修饰的强参照变量来避开这个问题。

1
2
3
4
5
6
7
8
9

{
    id __weak o = obj;
    id temp = o;
    NSLog(@"1 %@", temp);
    NSLog(@"2 %@", temp);
    NSLog(@"3 %@", temp);
    NSLog(@"4 %@", temp);
    NSLog(@"5 %@", temp);
}

另外，还有通过重载 allowsWeakReference/retainWeakReference 函数来限制 __weak 声明变量使用回数的方法，毕竟不在本次讨论范畴之内，就此省略。

话说回来，为什么使用弱参照变量的时候，要将其放入 autoreleasepool 中呢？想想弱参照的定义就应该明白了 —- 如果在访问弱参照对象时，该对象被释放了怎么办，程序不就崩溃了嘛；所以为了解决该问题，又再一次用到了 pool。

__autoreleasing

虽然上面还没有降到该关键字，但是编译器在很多时候已经用到了 autoreleasepool。比如非 alloc/new/copy/mutableCopy 开头的函数返回一个对象的时候，又比如使用一个 __weak 声明的变量的时候。

实际上，写ARC代码的时候，明示 __autoreleasing 声明变量和明示 __strong 声明变量一样基本上没有，因为编译器已经为我们做了很多，很智能了（前提是我们要按ARC的规则写代码）。

还有一种编译器缺省使用 __autoreleasing 关键字声明变量的时候：对象指针类型。比如下面的对应关系。

1
2

   id *obj == id __autoreleasing *obj
   NSObject **obj == NSObject * __autoreleasing *obj

所以，下面两个函数的是等价的。

1
2
3

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

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

像下面的函数调用，为什么是可行的呢？

1
2

NSError __strong *error = nil;
BOOL result = [obj performOperationWithError:&error];

其实，编译器是这样解释这段代码的。

1
2
3
4

NSError __strong *error = nil;
NSError __autoreleasing *tmp = error;
BOOL result = [obj performOperationWithError:&tmp];
error = tmp;

那么我们这样声明函数不就可以了吗？

1

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

答案是肯定的，你可以这样做，编译是可以通过，但你违反了非 alloc/new/copy/mutableCopy 开头的函数，不返回对象持有权的原则。这里是没有问题了，但也许影响到其他地方NG。

ARC 规则

结合上面的讲解，我想你也应该能够总结出来使用ARC时的规则

（这里只列出本讲中涉及的内容，其他的内容以后总结）

• 代码中不能使用retain, release, retain, autorelease
• 不能使用NSAllocateObject, NSDeallocateObject
• 不能使用NSAutoReleasePool、而需要@autoreleasepool块
• 严守内存管理相关函数命名规则

关于函数命名，伴随ARC的导入，还有一系列函数的定义也被严格定义了，那就是以 init 开头的函数。init 函数作为alloc生成对象的初期化函数，需要按原样直接传递对象给调用段，所以下面的声明是OK的。

1

-(id)initWithObject:(id)obj;

而下面的是NG的。

1

-(void)initWithObject;

不过声明为 -(void) initialize; 是没有问题的。

iPhone开发技巧之发布篇（7）— 制作自己的Cydia发布源

针对越狱的iPhone，大家肯定都知道用Cydia来安装各种免费应用的经历。Cydia中是否能指定我们自己的发布源，让我们自己随心所欲地发布程序给别人呢？答案是肯定的，我们只要创建Cydia的发布repository即可。

Linux Debian

首先，我们需要有Linux Debian或者Ubuntu系统来制作Cydia的发布源。如果你没有Linux Debian系统的机器，不要紧，可以随时用VMware Player或VirtualBox虚拟机来安装一个。

安装的时候用i386的iso即可，如果是64bit的OS用amd64的image来安装。安装的时候，选择Graphical Install，其他缺省安装。

脚本工具

下载下面两个脚本文件到本地，并加上可执行属性。

• 下载dpkg-scanpackages到/usr/bin
• 下载dpkg-gettext.pl到/etc/perl。

制作deb文件

以名称为MyProgram的程序微粒，首先在home目录下建立下面的目录结构

1
2
3
4
5
6
7
8
9
10

Cydia
   +- MyProgram
      +- DEBIAN
      |  +- control
      +- var
         +- mobile
            +- MyProgram.app
                +- Info.plist
                +- MyProgram
                +- icon.png

可以看出来，我们需要把程序MyProgram安装到/var/mobile/中去.

DEBIAN目录下面有一个名为control的文件，我们来看看它的内容。

1
2
3
4
5
6
7
8
9

Package: net.yifeiyang.MyProgram
Name: MyProgram
Version: 1.0.4-1
Architecture: iphoneos-arm
Description: test text.
Homepage: http://www.yifeiyang.net
Maintainer: YIFEIYANG <kane_yj@hotmail.com>
Author: YIFEIYANG <kane_yj@hotmail.com>
Section: Games

编译在制作DEB文件很简单，只需要

1
2

cd ~/Cydia
dpkg-deb –b MyProgram

这之后，我们就可以试试该deb文件，用iFile将文件上传到iPhone上并安装，查看/var/mobile/下的情况。这里我们可以使用iPhone开发技巧之发布篇（6）— 不需Developper认证的真机调试方法中的方法制作我们的程序，从而不需要验证信息。

制作Repository

每次追加新的deb文件，或者是deb文件有更新时，需要做下面两步

1
2

dpkg-scanpackages –m . /dev/null >Packages
bzip2 Packages

OK了，接下来我们就可以把Packages.bz2和MyProgram.deb这两个文件上传到你的web服务器中，然后把地址作为Source添加到Cydia中就搞定了。如果没有web服务器也没有关系，可以使用Dropbox等共享网盘，得到唯一的一个URL即可。

iPhone开发之深入浅出 (2) — ARC之@property使用

上一回我们学到了一些ARC的基本概念，这一次我们来看看ARC对@property的使用规则有何影响。

所有者属性

我们先来看看与所有权有关系的属性，关键字间的对应关系。

strong

该属性值对应 __strong 关键字，即该属性所声明的变量将成为对象的持有者。

weak

该属性对应 __weak 关键字，与 __weak 定义的变量一致，该属性所声明的变量将没有对象的所有权，并且当对象被破弃之后，对象将被自动赋值nil。

并且，delegate 和 Outlet 应该用 weak 属性来声明。同时，如上一回介绍的 iOS 5 之前的版本是没有 __weak 关键字的，所以 weak 属性是不能使用的。这种情况我们使用 unsafe_unretained。

unsafe_unretained

等效于__unsafe_unretaind关键字声明的变量；像上面说明的，iOS 5之前的系统用该属性代替 weak 来使用。

copy

与 strong 的区别是声明变量是拷贝对象的持有者。

assign

一般Scalar Varible用该属性声明，比如,int, BOOL。

retain

该属性与 strong 一致；只是可读性更强一些。

读写相关的属性 (readwrite, readonly)

读写相关的属性有 readwrite 和 readonly 两种，如果使用ARC之后，我么需要注意一下 readonly 属性的使用。

比如下面的变量声明。

1

@property (nonatomic, readonly) NSString *name;

一般声明为 readonly 的变量按理说应该不需要持有所有权了，但是在ARC有效的情况下，将出现下面的错误信息 ：

“ARC forbids synthesizing a property of an Objective-C object with unspecified ownership or storage attribute”

如果定义了ARC有效，那么必须要有所有者属性的定义；所以我们的代码改成这样，就OK了

1

@property (nonatomic, strong, readonly) NSString *name;

不过有一点，Scalar Varible的变量缺省都有 assign 的属性定义，所以不需要给他们单独的明示声明了。

iPhone开发之深入浅出 (1) — ARC是什么

新年伊始，万象更新。新一年开始，我们来更加深入了解一下iPhone开发的内部。作为开始，我们先来了解一下ARC。

ARC是什么

ARC是iOS 5推出的新功能，全称叫 ARC(Automatic Reference Counting)。简单地说，就是代码中自动加入了retain/release，原先需要手动添加的用来处理内存管理的引用计数的代码可以自动地由编译器完成了。

该机能在 iOS 5/ Mac OS X 10.7 开始导入，利用 Xcode4.2 可以使用该机能。简单地理解ARC，就是通过指定的语法，让编译器(LLVM 3.0)在编译代码时，自动生成实例的引用计数管理部分代码。有一点，ARC并不是GC，它只是一种代码静态分析（Static Analyzer）工具。

变化点

通过一小段代码，我们看看使用ARC前后的变化点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@interface NonARCObject : NSObject {
    NSString *name;
}
-(id)initWithName:(NSString *)name;
@end

@implementation NonARCObject
-(id)initWithName:(NSString *)newName {
    self = [super init];
    if (self) {
        name = [newName retain];
    }
    return self;
}

-(void)dealloc {
    [name release];
    [Super dealloc];
}
@end

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@interface ARCObject : NSObject {
    NSString *name;
}
-(id)initWithName:(NSString *)name;
@end

@implementation ARCObject
-(id)initWithName:(NSString *)newName {
    self = [super init];
    if (self) {
        name = newName;
    }
    return self;
}
@end

我们之前使用Objective-C中内存管理规则时，往往采用下面的准则

• 生成对象时，使用autorelease
• 对象代入时，先autorelease后再retain
• 对象在函数中返回时，使用return [[object retain] autorelease];

而使用ARC后，我们可以不需要这样做了，甚至连最基础的release都不需要了。

使用ARC的好处

使用ARC有什么好处呢？

• 看到上面的例子，大家就知道了，以后写Objective-C的代码变得简单多了，因为我们不需要担心烦人的内存管理，担心内存泄露了
• 代码的总量变少了，看上去清爽了不少，也节省了劳动力
• 代码高速化，由于使用编译器管理引用计数，减少了低效代码的可能性

不好的地方

• 记住一堆新的ARC规则 — 关键字及特性等需要一定的学习周期
• 一些旧的代码，第三方代码使用的时候比较麻烦；修改代码需要工数，要么修改编译开关

关于第二点，由于 XCode4.2 中缺省ARC就是 ON 的状态，所以编译旧代码的时候往往有"Automatic Reference Counting Issue"的错误信息。

这个时候，可以将项目编译设置中的“Objectice-C Auto Reference Counteting”设为NO。如下所示。

如果只想对某个.m文件不适应ARC，可以只针对该类文件加上 -fno-objc-arc 编译FLAGS，如下图。

ARC基本规则

• retain, release, autorelease, dealloc由编译器自动插入，不能在代码中调用
• dealloc虽然可以被重载，但是不能调用[super dealloc]

由于ARC并不是GC，并需要一些规则让编译器支持代码插入，所以必须清楚清楚了这些规则后，才能写出健壮的代码。

Objective-C对象

ObjectiveC中的对象，有强参照(Strong reference)和弱参照(Weak reference)之分，当需要保持其他对象的时候，需要retain以确保对象引用计数加1。对象的持有者(owner)只要存在，那么该对象的强参照就一直存在。

对象处理的基本规则是

• 只要对象的持有者存在（对象被强参照），那么就可以使用该对象
• 对象失去了持有者后，即被破弃

强参照 (Strong reference)

(s1)

firstName作为”natsu”字符串对象的最初持有者，是该NSString类型对象的Strong reference。

(s2)

这里将firstName代入到aName中，即aName也成为了@”natsu”字符串对象的持有者，对于该对象，aName也是Strong reference。

(s3)

这里，改变firstName的内容。生成新的字符串对象”maki”。这时候firstName成为”maki”的持有者，而@”natsu”的持有者只有aName。每个字符串对象都有各自的持有者，所以它们都在内存中都存在。

(s4)

追加新的变量otherName, 它将成为@”maki”对象的另一个持有者。即NSString类型对象的Strong reference。

(s5)

将otherName代入到aName，这时，aName将成为@”maki”字符串对象的持有者。而对象@”natsu”已经没有持有者了，该对象将被破弃。

弱参照 (Weak reference)

接下来我们来看看弱参照 (Weak reference) 的使用方式。

(w1)

与强参照方式同样，firstName作为字符串对象@”natsu”的持有者存在。即是该NSString类型对象的Strong reference。

(w2)

使用关键字__weak，声明弱参照weakName变量，将firstName代入。这时weakName虽然参照@”natsu”，但仍是Weak reference。即weakName虽然能看到@”natsu”，但不是其持有者。

(w3)

firstName指向了新的对象@”maki”，成为其持有者，而对象@”natsu”因为没有了持有者，即被破弃。同时weakName变量将被自动代入nil。

引用关键字

ARC中关于对象的引用参照，主要有下面几关键字。使用strong, weak, autoreleasing限定的变量会被隐式初始化为nil。

__strong

变量声明缺省都带有__strong关键字，如果变量什么关键字都不写，那么缺省就是强参照。

__weak

上面已经看到了，这是弱参照的关键字。该概念是新特性，从 iOS 5/ Mac OS X 10.7 开始导入。由于该类型不影响对象的生命周期，所以如果对象之前就没有持有者，那么会出现刚创建就被破弃的问题，比如下面的代码。

1
2

NSString __weak *string = [[NSString alloc] initWithFormat:@"First Name: %@", [self firstName]];
NSLog(@"string: %@", string); //此时 string为空

如果编译设定OS版本 Deployment Target 设定为这比这低的版本，那么编译时将报错(The current deployment target does not support automated __weak references)，这个时候，我们可以使用下面的__unsafe_unretained。

弱参照还有一个特征，即当参数对象失去所有者之后，变量会被自动付上nil (Zeroing)。

__unsafe_unretained

该关键字与__weak一样，也是弱参照，与__weak的区别只是是否执行nil赋值(Zeroing)。但是这样，需要注意变量所指的对象已经被破弃了，地址还还存在，但内存中对象已经没有了。如果还是访问该对象，将引起「BAD_ACCESS」错误。

__autoreleasing

该关键字使对像延迟释放。比如你想传一个未初始化的对像引用到一个方法当中，在此方法中实例化此对像，那么这种情况可以使用__autoreleasing。他被经常用于函数有值参数返回时的处理，比如下面的例子。

1
2
3
4
5
6
7
8
9
10
11

- (void) generateErrorInVariable:(__autoreleasing NSError **)paramError {
    ....
    *paramError = [[NSError alloc] initWithDomain:@"MyApp" code:1 userInfo:errorDictionary];
}

....
{
    NSError *error = nil;
    [self generateErrorInVariable:&error];
    NSLog(@"Error = %@", error);
}

又如函数的返回值是在函数中申请的，那么希望释放是在调用端时，往往有下面的代码。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

-(NSString *)stringTest
{
    NSString *retStr = [NSString stringWithString:@"test"];

    return [[retStr retain] autorelease];
}

// 使用ARC

-(NSString *)stringTest
{
    __autoreleasing NSString *retStr = [NSString alloc] initWithString:@"test"];

    return retStr;
}

即当方法的参数是id*，且希望方法返回时对象被autoreleased，那么使用该关键字。

总结

今天，我们看到了基本的ARC使用规则

• 代码中不能使用retain, release, retain, autorelease
• 不重载dealloc（如果是释放对象内存以外的处理，是可以重载该函数的，但是不能调用[super dealloc]）
• 不能使用NSAllocateObject, NSDeallocateObject
• 不能在C结构体中使用对象指针
• id与void *间的如果cast时需要用特定的方法（__bridge关键字）
• 不能使用NSAutoReleasePool、而需要@autoreleasepool块
• 不能使用“new”开始的属性名称 （如果使用会有下面的编译错误”Property’s synthesized getter follows Cocoa naming convention for returning ‘owned’ objects”）

今后，我们将更加深入ARC，学习其更多的特性。

iPhone开发技巧之发布篇（6）— 不需Developper认证的真机调试方法

以前，iPhone开发入门（10）--- 设备上运行程序中介绍了正式注册iPhone/iOS Developer Program后在设备运行程序的方法；在iPhone开发入门（3）—Linux上构筑iPhone OS3.1.2开发环境 和 iPhone开发进阶（4） --- 使用Makefile自动编译iPhone程序 也简单介绍了在越狱机器上运行程序的方法。

今天给大家介绍另一种不需要注册iPhone/iOS Developer Program，也可以简单地在设备中运行程序的方法.

制作证明书

首先通过Keychain制作一个新的证明书 Keychain Access -> Certificate Assistant -> Create a Certification

证明书的名称任意(需要记住，下面会用到)，固有类型选择self-signed root，证明书类型选择Code Signing，并选择“let me override defaults”。

程序设置

程序的Code Signing都设置为「Don’t Code Sign」

编辑SDKSettings.plist文件

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/SDKSettings.plist

将 CODE_SIGNING_REQUIRED 设置为 NO。

设置之后编译程序 for iOS Device。

署名

在控制台用codesign给应用程序署名

1

codesign –fs “Fake Code Sign” ./Application.app/Application

验证

制作好Application.app之后，通过iPhoneExplorer，iFile等上传到iPhone的/Applications目录下。并添加执行属性。

OK, 可以运行一下我们的程序看看了。

敏捷开发实践（2） — 敏捷软件开发者的习惯

敏捷开发的最小单位就是参与敏捷开发的个人。将这些敏捷开发者聚集起来，就形成了敏捷开发团队。

正如上回介绍的，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，它以最大可能地发挥团队的作用为目的。根据需要，随时改善，以降低软件开发中的风险。

敏捷开发者的态度

敏捷开发者首先需要有忠实，勤恳的态度，在此之上要有持续改善和迅速达成目标的紧迫感。如何让开发者养成敏捷的心态，如何磨练开发者敏捷的意志，让开发者了解敏捷的习惯很重要。

习惯来自于经验，习惯需要用实践来养成。我们来看看作为敏捷软件开发者必备的4种技能 ：

• 编故事（Creating Stories）

  这里不是让你去写一部小说，而是让开发者站在用户的视点，用用户能理解的词汇描述软件系统的机能，行为。只有理解了用户真正的需求，我们才能写出真正需要的软件。

• 制定计划（Planning）

  敏捷开发并不是没有计划就投入编码。指定计划也是很重要的，但是与以往的开发计划不同，敏捷的计划是随着开发的实际情况改变而随时制定并改善的。所以说敏捷开发的计划的作成、修改的频度很高，需要尽可能高效地完成每次制定的计划。

• 测试驱动开发（Test-Driven Development）

  它的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。然后循环进行添加其他功能，直到完成全部功能的开发。

• 重构（Refactoring）

  没有最好，只有更好。软件开发也不例外，任何时候我们都可以对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。

敏捷开发者的习惯

了解了开发者应该具有的态度，我们就可以从自己开始掌握敏捷开发者的习惯。然后在团队中展开，最终形成敏捷的团队。

构成敏捷习惯的要素

• 敏捷的心态
• 敏捷的实践
• 持续改善

重视各种反馈

通过实践中的反馈，我们可以得到过程中的经验，并对今后的开发产生有益的作用。但是并不是一味的重视实践就好了，需要知道何时从实践和反馈中学习。

为了按阶段，周期性的完成实践及反馈的过程，差生了迭代的概念。

迭代开发

迭代开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如2周）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。

迭代的一个很重要思想就是将作业按时间单位来划分，管理。在一定的周期内完成开发的作业。不同的团队可以按照机能划分，并行开展，如下图 ：

比如，一个项目的作业期间是3个月，按2周为单位来开展迭代开发，那么迭代的总数就是6个。并且该期限是严守的，一旦规定好了一般是不能更改的。

回顾改善

每个迭代结束之后，都需要回顾上个迭代中的内容，考虑是否有改善和坚持的地方，以提高接下来迭代中的开发效率。

该回顾需要定期的地实施，并在30分钟到1个小时内完成。一般情况下，在白板上使用KPT方法来总结课题。

• Keep : 好的，需要今后坚持的
• Problem : 问题点，需要注意并改善的
• Try : 下次开始尝试改善的

进行KPT的步骤

• 检查上次的Try课题
• 回忆本次迭代中遇到的课题
• 按Keep，Problem，Try的形式总结
• Closing，总结，给白板拍照

iPhone开发技巧之环境篇（11）— 让Xcode对应多个版本的iOS SDK

每次Xcode升级，以前的iOS SDK都会被覆盖掉；这是许多人碰到并头疼的问题—-如果想用旧版本的SDK编译就没有办法了。

这里就介绍一下Xcode与多个SDK版本并存的方法。针对Xcode的安装顺序总结了两种方法 ：

安装新版Xcode时备份旧版SDK

这是最简单的方法 —- 每当安装新版的Xcode时，备份之前旧的SDK，安装Xcode之后，回复到指定目录下即可。

备份SDK路径

1
2
3
4
5

iOS 设备用
$ /Developer/Platforms/iPhoneOS.platform/Developer/SDKs

iPhone 模拟器用
$ /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs

简单起见，在安装新版Xcode之前，可以把这两个目录下的需要备份的SDK版本move到其他目录下，安装完Xcode之后再move回来即可。

在Xcode内安装旧版的SDK

已经安装好的Xcode上，想安装旧版的SDK也是可以的，只是需要一些准备。下面从安装新版Xcode开始，再到之后安装旧版SDK做一个简要说明。

首先我们删除之前已安装的Xcode

1

$ sudo /Developer/Library/uninstall-devtools --mode=all

然后，安装从Apple Developer上下载的最新Xcode dmg安装包。完成Xcode的安装。

接下来，从iPhone Software Development: Old versions of iPhone SDK上下载你所需要的旧版SDK版本；

打开下载的旧版dmg文件的Packages目录后，会看到许多的pkg文件。

接下来，根据你的需要，选择具体的iPhoneSDK$(ver).pkg文件，并双击安装。这里注意一点 —- 你选择的SDK版本最好是dmg文件中正式附带的版本；在某个dmg会附带当前最新的版本，和之前版本的pkg文件。如果是选择之前pkg文件的话，有可能缺省的安装路径是不一样的。
比如xcode_3.2.4_and_ios_sdk_4.1.dmg，就选择iPhoneSDK4_1.pkg来安装，不要选择比它小的版本号。

安装的时候，需要需要选择正确的安装路径

选择[Installation Type]的[Change Install Location...]

然后选择[Developer]目录。

确认好后，点击[Continue]。

安装完后，我们可以确认一下下面的路径是否有你需要的SDK。

/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS$(ver).sdk

同样的，你可以安装iPhoneSimulatorSDK$(ver).pkg

虽然说Xcode可以支持多种版本的SDK并存，但是一般情况下按照下面的原则去编译你的程序应该是是最安全的。

用最新的Base SDK编译，Deployment Target尽量选择最低的。

由于编译SDK版本不同而引起的编译/运行期错误处理

由于SDK版本变化，或多或少会有一些莫名的编译错误出现；有的时候是链接出错，譬如找出到-lcrt，有的时候是压根编译时就找不到头文件。

譬如下面找不到-lcrt的问题

这个时候，我们可以试试更改编译选项中Mac OS X的Deployment Target。

如果还是不能解决，可以试试更改编译器（比如GCC 4.2 或者是 LLVM GCC 4.2）。

还有一种问题的原因可能是原先SDK中的Framework与新版中的SDK不匹配，引起编译失败

这个时候，需要重新选择新版本中的Framework到工程文件中。

如果是旧的iOS环境中没有包含的必要的Framework，也会出现类似于下面的动态链接错误

（即在高版本的OS中才有的新增功能，想在低版本的OS中依然能够运行）

1
2
3

dyld: Library not loaded: /System/Library/Frameworks/iAd.framework/iAd
  Referenced from: /var/mobile/Applications/71E4CD8F-4E9E-4FC1-A7B9-6AE975E9C2B0/Test.app/Test
  Reason: image not found

这时，就需要与新版SDK的Framework建立Weak Link。

如下图所示，在「Target」＞「执行文件」点击左边的三角，并选择「链接库文件」。只要将需要Weak Link的库的Required变为 Weak 即可。

最后，针对对新库中调用的部分，我们还需要在代码中加入对版本判断和控制的逻辑。（如果不这样做，我们的程序在低版本OS的设备中必定崩溃）

1. iOS版本确认

1
2
3
4
5
6
7
8

- (void)viewDidLoad {
    [super viewDidLoad];

    if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 4.0) {
        bannerView = [[ADBannerView alloc] init];
        bannerView.delegate = self;
        [self.view addSubview:bannerView];
    }

2. 新类是否存在

1
2
3
4
5
6

Class clazz = NSClassFromString(@"ADBannerView");
if (clazz) {
    bannerView = [[ADBannerView alloc] init];
    bannerView.delegate = self;
    [self.view addSubview:bannerView];
}

3. 新接口是否存在

1
2
3
4
5

if (UIGraphicsBeginImageContextWithOptions != NULL) {
    bannerView = [[ADBannerView alloc] init];
    bannerView.delegate = self;
    [self.view addSubview:bannerView];
}

iPhone开发技巧之发布篇（5）— 在程序中添加广告

iPhone/iPad的程序，即使是Free的版本，也可以通过广告给我们带来收入。前提是你的程序足够吸引人，有足够的下载量。

这里，我将介绍一下程序中集成广告的方法。主要有两种广告iAd和AdMob。（还有其他多种可被植入的广告SDK，这里就不都一一介绍了）

iAd

从iOS 4开始，Apple增加了叫做 iAd 的架构，通过它我们可以在程序中提供Apple的广告服务。Apple会支付给开发者60%的广告收入。

iAd Framework中有例程，我们可以下载学习。这里，把简单的步骤说明一下 ：

追加iAD Framework

首先，在Xcode的［Frameworks］中添加［iAd.framework］。

创建ADBannerView

广告的显示是在一个叫做ADBannerView的窗口中的。通过控制这个窗口可以控制广告的显示/隐藏。ADBannerView和一般的UIView没有什么两样，将其作为某个画面的subView，然后通过「frame」控制其显示的位置，大小。一般情况下，缺省iPhone上的话，竖屏是：横320pt, 竖50pt；横屏是：横480pt, 竖32pt。

下面的程序显示了ADBannerView的初始化过程，以父窗口的viewDidLoad中实现为例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

- (void)viewDidLoad {

……【省略】……

    // 初始化ADBannerView
    ADBannerView *adView = [[[ADBannerView alloc] initWithFrame:CGRectZero] autorelease];
    adView.currentContentSizeIdentifier = ADBannerContentSizeIdentifierPortrait;
    // 登陆ADBannerView的delegate，这里我们设定其父窗口自己
    adView.delegate = self;
    // 在父窗口下方表示
    adView.frame = CGRectOffset(adView.frame, 0, self.view.frame.size.height - self.adView.frame.size.height);
    // 添加到父窗口中
    [self.view addSubview:adView];
}

接下来，我们来实现ADBannerView的delegate。这里可以实现在父窗口的UIViewController子类中，也可以单独写一个ViewController。这里面实现了ADBannerView广告的读取，错误处理，全画面表示等delegate的处理设定。

下面实现在父窗口的ViewController中。

1
2
3
4
5
6
7

#import <UIKit/UIKit.h>
#import <iAd/iAd.h>

@interface XXXViewController : UIViewController<UITextFieldDelegate, ADBannerViewDelegate> {

……【省略】……
}

如上所示，这里增加了「ADBannerViewDelegate」protocol的实现。接下来看看都有哪些delegate接口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

// 广告读取过程中出现错误
- (void)bannerView:(ADBannerView *)banner didFailToReceiveAdWithError:(NSError * )error{
    // 切换ADBannerView表示状态，显示→隐藏
    // adView.frame = CGRectOffset(adView.frame, 0, self.view.frame.size.height);
}

// 成功读取广告
- (void)bannerViewDidLoadAd:(ADBannerView *)banner{
    // 切换ADBannerView表示状态，隐藏→显示
    // adView.frame = CGRectOffset(adView.frame, 0, self.view.frame.size.height - adView.frame.size.height);
}

// 用户点击广告是响应，返回值BOOL指定广告是否打开
// 参数willLeaveApplication是指是否用其他的程序打开该广告
// 一般在该函数内让当前View停止，以及准备全画面表示广告
- (BOOL)bannerViewActionShouldBegin:(ADBannerView *)banner willLeaveApplication:(BOOL)willLeave {
    NSLog(@"bannerViewActionShouldBegin:willLeaveApplication: is called.");
}

// 全画面的广告表示完了后，调用该接口
// 该接口被调用之后，当前程序一般会作为后台程序运行
// 该接口中需要回复之前被中断的处理（如果有的话）
- (void)bannerViewActionDidFinish:(ADBannerView *)banner {
    NSLog(@"bannerViewActionDidFinish: is called.");
}

以上都实现之后，我们来看看iAd广告的效果。

AdMob

AdMob是另一家移动电话广告市场，现在已被Google收购。借助AdMob, 谷歌计划将其网络搜索主导地位从电脑平台扩展向手机平台。

正因为AdMob现在是Google的了，所以在Android上得到广泛的应用，不过在iPhone上也是同样可以使用的。下面就介绍一下使用方法。

其实步骤很简单：在AdMob上注册用户→登陆你的程序→得到程序固有的Publisher ID→下载并在程序中组入相应代码。

登陆

首先注册用户

注册并登陆之后，需要登记你准备添加广告的程序（这里，即使程序还没有开发完毕也没有关系）。点击下图marketplace→添加site/Application

选择iPhone/iPad程序，如果是Android的话就选择Android应用程序。

接下来填写程序的详细信息。

其中关于程序的URL的填写，如果程序已经发布，那么填写App Store上的URL，否则随便先填一个，以后可以修改。

接下来就可以得到程序的Publisher ID，其使用方法会在下面介绍。

同时，我们可以下载最新的SDK。（其实也可以通过这里下载）

下载并解压之后，会得到如下图的几个文件。其中README.txt有环境说明，文档及例程的下载URL。

注意点

接下来我们看看程序中怎么使用该SDK。首先我们看看例程中有哪些需要注意的。

MY BANNER_UNIT_ID的设定

例程中有下面这样的定义（BannerExampleViewController.m）。

1
2
3

#if !defined(MY_BANNER_UNIT_ID)
  #error "You must define MY_BANNER_UNIT_ID as your AdMob Publisher ID"
#endif

这里就需要上面介绍的注册时得到的程序专有的Publisher ID。没有它，编译的时候将报错。类似下面的样子，我们设定一下。

1
2
3
4
5

#define MY_BANNER_UNIT_ID   @"xxxxxxxxxxxxxxx"

#if !defined(MY_BANNER_UNIT_ID)
  #error "You must define MY_BANNER_UNIT_ID as your AdMob Publisher ID"
#endif

另外，还有一个测试时用的属性

测试的时候将 GADRequest::testing 属性置为 YES。如下For Testing的设置。

1
2
3
4
5
6
7
8
9
10
11

  // Let the runtime know which UIViewController to restore after taking
  // the user wherever the ad goes and add it to the view hierarchy.
  bannerView_.rootViewController = self;
  [self.view addSubview:bannerView_];

  // For Testing
  GADRequest *rq = [GADRequest request];
  rq.testing = YES;

  // Initiate a generic request to load it with an ad.
  [bannerView_ loadRequest:rq];

显示的广告如下图。

不过，该设定只对模拟器有效，在实际设备上运行时，仍然显示真实的广告。如下图。

例程

接下来，通过一个例程说明一下AdMob广告的添加过程。

1. Xcode 4中创建一个「Tab Bar Application」新程序「AdMobTabBar」

2. 将 AdMob SDK 放到该工程中。

3. 添加 AdMob 所必须的 Framework（ AudioToolbox, MediaPlayer, MessageUI, SystemConfiguration。）

4. 创建GADBannerView

与iAD中的ADBannerView类似，AdMob也有一个GADBannerView，用来显示广告。其创建过程如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

    // Create a view of the standard size at the bottom of the screen.
    bannerView_ = [[GADBannerView alloc]
                            initWithFrame:CGRectMake(0.0,
                                            self.view.frame.size.height -
                                            TABBAR_HEIGHT,
                                            GAD_SIZE_320x50.width,
                                            GAD_SIZE_320x50.height)];

    // delegate の設定
    bannerView_.delegate = self;

    // Specify the ad's "unit identifier." This is your AdMob Publisher ID.
    bannerView_.adUnitID = MY_BANNER_UNIT_ID;

    // Let the runtime know which UIViewController to restore after taking
    // the user wherever the ad goes and add it to the view hierarchy.
    bannerView_.rootViewController = self;
    [self.view addSubview:bannerView_];

    // For Testing
    GADRequest *rq = [GADRequest request];
    rq.testing = YES;

    // Initiate a generic request to load it with an ad.
    [bannerView_ loadRequest:rq];

同样，也有一个叫做GADBannerViewDelegate的delegate。可以实现在父窗口的UIViewController子类中，也可以单独写一个ViewController。

1
2
3
4
5
6
7
8
9
10

#import <UIKit/UIKit.h>

#import "GADBannerView.h"

@interface FirstViewController : UIViewController <GADBannerViewDelegate> {
    GADBannerView *bannerView_;

}

@end

或者

1
2
3
4
5
6
7

#import "GADBannerView.h"
#import "GADBannerViewDelegate.h"

@interface MyBannerView : GADBannerView <GADBannerViewDelegate> {
}

@end

这里的delegate接口与ADBannerViewDelegate其实很类似。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

// Admob成功取得
- (void)adViewDidReceiveAd:(GADBannerView *)adMobView {
    NSLog(@"Admob:adViewDidReceiveAd");

    // 动画表示
    adMobAd.frame = CGRectMake(0.0,
             self.view.frame.size.height,
             adMobView.frame.size.width,
             adMobView.frame.size.height);
    [UIView beginAnimations:@"AdMobBannerMoveOnScreen" context:NULL];
    adMobAd.frame = CGRectMake(0.0,
             self.view.frame.size.height - adMobView.frame.size.height,
             adMobView.frame.size.width,
             adMobView.frame.size.height);
    [UIView commitAnimations];
}

// Admob取得失败
- (void)adView:(GADBannerView *)adMobView didFailToReceiveAdWithError:(GADRequestError *)error {
    NSLog(@"Admob:didFailToReceiveAdWithError:%@", [error localizedDescription]);
}

// AdMob广告被打开时
- (void)adViewWillPresentScreen:(GADBannerView *)adView {
}

// 从AdMob的广告跳到其他程序时
-(void) applicationDidEnterBackground:(UIApplication*)application {
}

// 从其他被打开的程序返回到AdMob广告显示
-(void) applicationWillEnterForeground:(UIApplication*)application {
}

// AdMob广告显示被关闭时
- (void)adViewWillDismissScreen:(GADBannerView *)adView {
}

整体的代码如下所示 。这里GADBannerView的delegate实现在父窗口的ViewController中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

#import "FirstViewController.h"

#define MY_BANNER_UNIT_ID   @"xxxxxxxxxxxxxxx"
#define ANIMATION_DURATION  0.5f
#define TABBAR_HEIGHT       49.0f

@implementation FirstViewController

// Implement viewDidLoad to do additional setup after loading the view, typically from a nib.
- (void)viewDidLoad
{
    [super viewDidLoad];

    // Create a view of the standard size at the bottom of the screen.
    bannerView_ = [[GADBannerView alloc]
                            initWithFrame:CGRectMake(0.0,
                                            self.view.frame.size.height -
                                            TABBAR_HEIGHT,
                                            GAD_SIZE_320x50.width,
                                            GAD_SIZE_320x50.height)];

    // delegate の設定
    bannerView_.delegate = self;

    // Specify the ad's "unit identifier." This is your AdMob Publisher ID.
    bannerView_.adUnitID = MY_BANNER_UNIT_ID;

    // Let the runtime know which UIViewController to restore after taking
    // the user wherever the ad goes and add it to the view hierarchy.
    bannerView_.rootViewController = self;
    [self.view addSubview:bannerView_];

    // For Testing
    GADRequest *rq = [GADRequest request];
    rq.testing = YES;

    // Initiate a generic request to load it with an ad.
    [bannerView_ loadRequest:rq];
}

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
    // Return YES for supported orientations
    return (interfaceOrientation == UIInterfaceOrientationPortrait);
}

- (void)didReceiveMemoryWarning
{
    // Releases the view if it doesn't have a superview.
    [super didReceiveMemoryWarning];

    // Release any cached data, images, etc. that aren't in use.
}

- (void)viewDidUnload
{
    [super viewDidUnload];

    // Release any retained subviews of the main view.
    // e.g. self.myOutlet = nil;
}

- (void)dealloc
{
    bannerView_.delegate = nil;
    [bannerView_ release];

    [super dealloc];
}

- (void)adViewDidReceiveAd:(GADBannerView *)view {
    [UIView animateWithDuration:ANIMATION_DURATION
                     animations:^{
                         bannerView_.center = CGPointMake(bannerView_.center.x, bannerView_.center.y-TABBAR_HEIGHT);
                     }];
}

@end

最终效果如下。

使用Xcode调试程序的时候，是否觉得有时候运行速度太慢。用Xcodebuild编译好程序之后，Xcode作为IDE纯粹是为了debug，使用iPhone模拟器而用的。其实iPhone模拟器只是Xcode自带的一个工具，不需要Xcode也可以启动的。这里，我们来看看一个叫做iphonesim的东东，通过控制台来模拟调试我们的iPhone程序。有了它就可以解决Xcode过于庞大，运行速度慢的问题。

首先，我们从github上下载了程序源码，通过Xcode编译。这之后iphonesim接生成了，可以通过命令行来使用它。

比如我调试一个Test.app的程序

1
2
3
4
5
6

 $ pwd
 /Users/Tester/Downloads/iphonesim/build/Debug
 $ ./iphonesim launch ~/Desktop/Fac/Test/build/Debug-iphonesimulator/Test.app
 [DEBUG] App Spec: 〜
 [DEBUG] SDK Root: 〜
 [DEBUG] Session started

OK, 从控制台我们启动了iPhone模拟器，这并没有Xcode的参与。这之后可以使用iphonesim+gdb的组合来调试我们的程序了。

结合之前iPhone开发技巧之环境篇（1）--- 使用Emacs开发iPhone应用程序中介绍的那样，我们就可以实现Xcodebuild+iphonesim+gdb的完美组合，不需要启动又大又重的Xcode。

通过控制台调用模拟器的方法，我们可以很轻松地实现自动化的程序单体测试，产品发布前的结合测试...

敏捷开发实践（1） — 走进敏捷软件开发

敏捷开发是什么

敏捷软件开发是一个概念意义上的框架，用来取代软件工程项目的概念；它强调在项目的整个生命周期中，拥抱并促进由于软件进化式的发展所带来的变化。

简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发中涵盖多种开发元素：迭代开发，增量交付，测试驱动，结对编程，Usecase驱动，持续集成，重构等。我们知道软件开发项目中式样变更，需求变更是影响开发进度、成败的重要因素，而敏捷开发元素的利用可以有效地规避这些风险、变化。学会如何识别变化的大势，并在可能的时候，促使变化向好的方向发展。这是软件项目进化的趋势。

最后我们看看敏捷开发宣言

• 个体与交互 重于 过程和工具
• 可用的软件 重于 完备的文档
• 客户协作 重于 合同谈判
• 响应变化 重于 遵循计划

同时，遵循以下准则

• 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
• 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
• 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
• 项目过程中，业务人员与开发人员必须在一起工作。
• 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
• 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
• 可用的软件是衡量进度的主要指标。
• 敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
• 对技术的精益求精以及对设计的不断完善将提升敏捷性。
• 要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
• 最佳的架构、需求和设计出自于自组织的团队。
• 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

为什么要使用敏捷开发

对于有一定经验的软件开发人员，是否有过疲惫应对式样变更，需求变更而导致返工的经历。

变化的原因无非是

• 项目开始阶段对需求并不明确，就急于开发设计
• 产品已不能按照项目启动时定义的要求发布
  • 最终出来的产品往往和最初设计，构思的完全不同；变更之前定义的要求/需求将是很正常的事情
  • 大家都不关心产品的制作过程，最初的成果物往往都是废品；然后是在废品上的修修补补
    • 软件开发以外的部门并不认真对待软件开发，一味地要求结果，要求性能
    • 软件确实是可以重新编写的，但是已经用掉的工数是不会取回的
• 如果不试着先做做，是不知道是否能实现
  • 新的硬件是否能按照式样中那样描述的工作，达到理想的性能指标
  • 团队成员是否都熟悉开发工具，达到熟悉程度为止的培训要花相应的时间
  • 软件架构是否稳定，需要早期验证设计的合理性

综上，如果按照我们习惯的瀑布流式的开发方式，是否能应对这些变化的因素呢？我们来看一下瀑布式开发的典型V字型模型。

一开始，我们先有完整的用户需求，定义，接下来做需求分析，概要设计，详细设计；然后到编码，单元测试，集成测试，系统测试，验收。看似很理想的过程，可是在实践当中常常出现这种这样的问题。

首先我们的用户也许并不了解自己需要什么，所以常常到了编码阶段，甚至是测试阶段，才提出各种各样的修改；对于用户很轻松的事情，可对于我们开发者来说简直就是地狱。另外，产品开发都是希望尽快完成开发任务，尽早投放市场。可是开发的风险是不可避免的，一般软件开发都很难按时按质完成。

降低风险是敏捷开发中很重要的一环。机能分割，迭代式开发等敏捷元素的利用，有效地降低了开发中存在的风险。一方面随着迭代式开发，可以随时验证架构设计的稳妥性，另一方面可以应对即时的需求变更。

敏捷开发的现状与将来

敏捷开发概念从2004年初开始广为流行。近几年，敏捷软件开发在软件工业界有了良好的发展势头并逐渐被推广开来。一些著名的公司如 Google, Microsoft 和 Yahoo 和众多的中小公司都已经开始采用敏捷开发。

敏捷方法给这些企业也已带来了巨大的收益。据业内资深人士和长期从事敏捷咨询的服务公司透露，采用敏捷开发的团队一般会提高3-10倍的效率，软件的质量也有了更加可靠的保证。同时，敏捷开发的应用也给团队内的每个成员提供了良好的发展机会。他们的技术和合作水平都能得到响应的提高。

欧美软件企业中，有近半企业已采用敏捷方法进行开发。大多数尚未应用敏捷的企业，也都对其有所了解，而且很多在计划实施。中国的外企，外包公司和许多知名企业也都开始采用了敏捷方法。

敏捷开发不仅适用于少人数的团队协作，在大规模开发，离岸开发中也发挥着重要的作用。虽然它不是软件开发领域中的“银弹”，但是理解了其精髓，在降低产品发布的风险，构建协作团队等方面都是有帮助的。

同时，敏捷总是在不断发展演变，因此，没有一个人能保证目前的敏捷方法都是正确的。每个采用敏捷开发的团队都可以通过发现并形成自己的想法和最佳实践，对敏捷开发做出自己的贡献。