在dealloc中清理。

这是最容易忘记的事情之一——尤其是在以150英里/小时的速度编码时。总是，总是，总是清理dealloc中的属性/成员变量。

我喜欢使用Objc 2属性-新的点表示法-所以这使得清理变得无痛。通常很简单:

- (void)dealloc
{
    self.someAttribute = NULL;
    [super dealloc];
}

这将为您处理发布，并将属性设置为NULL(我认为这是防御性编程——以防dealloc中的另一个方法再次访问成员变量——很少，但也可能发生)。

在10.5中打开GC后，就不再需要这么多了——但是你可能仍然需要清理你创建的其他资源，你可以在finalize方法中做这件事。

黄金法则:如果你分配了，那么你就释放了!

更新:除非你正在使用ARC

我已经开始做的一些事情，我认为不是标准的:

1)随着属性的出现，我不再使用“_”作为“私有”类变量的前缀。毕竟，如果一个变量可以被其他类访问，不应该有一个属性吗?我一直不喜欢“_”前缀，因为它会让代码变得更丑，现在我可以把它去掉了。

2)说到私有的东西，我更喜欢把私有方法定义放在.m文件的类扩展名中，就像这样:

#import "MyClass.h"

@interface MyClass ()
- (void) someMethod;
- (void) someOtherMethod;
@end

@implementation MyClass

为什么要用外人不应该关心的东西把.h文件弄得乱七八糟呢?empty()适用于.m文件中的私有类别，如果您没有实现声明的方法，则会发出编译警告。

3)我已经开始把dealloc放在。m文件的顶部，就在@synthesize指令的下面。你在课堂上想要思考的事情不应该排在最前面吗?在iPhone这样的环境下尤其如此。

3.5)在表格单元格中，为了性能，使每个元素(包括单元格本身)都不透明。这意味着在所有内容中设置适当的背景颜色。

3.6)当使用NSURLConnection时，作为一个规则，你可能很想实现委托方法:

- (NSCachedURLResponse *)connection:(NSURLConnection *)connection
                  willCacheResponse:(NSCachedURLResponse *)cachedResponse
{
      return nil;
}

我发现大多数web调用是非常单一的，这是一个例外，而不是规则，你会希望响应缓存，特别是web服务调用。实现如下所示的方法将禁用响应缓存。

同样有趣的是，Joseph Mattiello的一些关于iPhone的好建议(从iPhone邮件列表中收到的)。还有更多，但这些是我认为最有用的(注意，现在有几个比特已经从原始的轻微编辑，以包括在回复中提供的细节):

4)只有在必要时才使用双精度，比如在使用CoreLocation时。确保常量以“f”结尾，以使gcc将它们存储为浮点数。

float val = someFloat * 2.2f;

当someFloat实际上可能是double类型时，这是非常重要的，你不需要混合模式数学，因为你在存储上失去了'val'的精度。虽然iphone的硬件支持浮点数，但与单精度相比，执行双精度算术可能仍需要更多时间。引用:

iPhone上的Double vs float iPhone/iPad双精度数学

在老式手机上，计算的速度应该是相同的，但你可以在寄存器中使用更多的单精度组件，所以对于许多计算来说，单精度最终会更快。

5)设置你的属性为非原子的。默认情况下，它们是原子的，在合成时，将创建信号量代码以防止多线程问题。99%的人可能不需要担心这个，当设置为nonatomic时，代码就不会那么臃肿，内存效率更高。

6) SQLite can be a very, very fast way to cache large data sets. A map application for instance can cache its tiles into SQLite files. The most expensive part is disk I/O. Avoid many small writes by sending BEGIN; and COMMIT; between large blocks. We use a 2 second timer for instance that resets on each new submit. When it expires, we send COMMIT; , which causes all your writes to go in one large chunk. SQLite stores transaction data to disk and doing this Begin/End wrapping avoids creation of many transaction files, grouping all of the transactions into one file.

此外，如果GUI在主线程上，SQL将阻塞它。如果你有一个很长的查询，最好将查询存储为静态对象，并在单独的线程上运行SQL。确保将修改数据库查询字符串的任何内容包装在@synchronize(){}块中。对于简短的查询，为了更方便，只需将内容留在主线程中。

更多的SQLite优化技巧在这里，虽然文档看起来过时了，但许多要点可能仍然是好的;

http://web.utk.edu/~jplyon/sqlite/SQLite_optimization_FAQ.html

所有这些评论都很棒，但我真的很惊讶没有人提到谷歌的Objective-C风格指南，这是不久前发布的。我认为他们做得很彻底。

不要把Objective-C写成Java/ c# / c++等。

我曾经看到一个编写Java EE web应用程序的团队尝试编写Cocoa桌面应用程序。就好像它是一个Java EE web应用程序。有很多AbstractFooFactory、FooFactory、IFoo和Foo，而他们真正需要的只是一个Foo类，可能还有一个Fooable协议。

确保你不这样做的部分原因是真正理解语言的差异。例如，您不需要上面的抽象工厂和工厂类，因为Objective-C类方法和实例方法一样是动态分派的，并且可以在子类中重写。

功能性更强。

Objective-C是面向对象的语言，但是Cocoa框架是函数式风格的，并且在很多情况下是函数式设计的。

There is separation of mutability. Use immutable classes as primary, and mutable object as secondary. For instance, use NSArray primarily, and use NSMutableArray only when you need. There is pure functions. Not so many, buy many of framework APIs are designed like pure function. Look at functions such as CGRectMake() or CGAffineTransformMake(). Obviously pointer form looks more efficient. However indirect argument with pointers can't offer side-effect-free. Design structures purely as much as possible. Separate even state objects. Use -copy instead of -retain when passing a value to other object. Because shared state can influence mutation to value in other object silently. So can't be side-effect-free. If you have a value from external from object, copy it. So it's also important designing shared state as minimal as possible.

但是也不要害怕使用不纯函数。

There is lazy evaluation. See something like -[UIViewController view] property. The view won't be created when the object is created. It'll be created when caller reading view property at first time. UIImage will not be loaded until it actually being drawn. There are many implementation like this design. This kind of designs are very helpful for resource management, but if you don't know the concept of lazy evaluation, it's not easy to understand behavior of them. There is closure. Use C-blocks as much as possible. This will simplify your life greatly. But read once more about block-memory-management before using it. There is semi-auto GC. NSAutoreleasePool. Use -autorelease primary. Use manual -retain/-release secondary when you really need. (ex: memory optimization, explicit resource deletion)