还有一个半相关的话题(还有更多的回复空间!):

有哪些Xcode的小技巧和技巧是你希望2年前就知道的?

避免生成

Since you typically(1) don't have direct control over their lifetime, autoreleased objects can persist for a comparatively long time and unnecessarily increase the memory footprint of your application. Whilst on the desktop this may be of little consequence, on more constrained platforms this can be a significant issue. On all platforms, therefore, and especially on more constrained platforms, it is considered best practice to avoid using methods that would lead to autoreleased objects and instead you are encouraged to use the alloc/init pattern.

因此，而不是:

aVariable = [AClass convenienceMethod];

在可能的情况下，你应该使用:

aVariable = [[AClass alloc] init];
// do things with aVariable
[aVariable release];

当您编写自己的方法返回新创建的对象时，您可以利用Cocoa的命名约定，通过在方法名前加上“new”来标记接收方必须释放该对象。

因此，与其:

- (MyClass *)convenienceMethod {
    MyClass *instance = [[[self alloc] init] autorelease];
    // configure instance
    return instance;
}

你可以这样写:

- (MyClass *)newInstance {
    MyClass *instance = [[self alloc] init];
    // configure instance
    return instance;
}

因为方法名以"new"开头，你的API的使用者知道他们负责释放接收到的对象(例如，看NSObjectController的newObject方法)。

你可以通过使用你自己的本地自动释放池来控制。有关这方面的更多信息，请参见自动释放池。

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

更新:除非你正在使用ARC

变量和属性

1/保持头文件整洁，隐藏实现 不要在头文件中包含实例变量。作为属性放入类延续中的私有变量。公共变量在头文件中声明为公共属性。 如果它应该是只读的，将其声明为readonly，并在类延续中将其重写为readwrite。 基本上我根本不用变量，只用属性。

2/给你的属性一个非默认变量名，例如:

@synthesize property = property_;

原因1:在分配属性时，您将捕获由于忘记“self.”而引起的错误。 原因2:从我的实验中，仪器中的泄漏分析仪在检测默认名称的泄漏属性时存在问题。

3/不要在属性上直接使用retain或release(或仅在非常特殊的情况下)。在dealloc中，给它们分配一个nil。保留属性意味着自己处理保留/释放。例如，您永远不知道setter是否没有添加或删除观察器。您应该只在它的setter和getter中直接使用变量。

的观点

1/如果可以的话，将每个视图定义放入xib中(例外通常是动态内容和层设置)。它节省时间(比写代码简单)，易于更改，并保持代码整洁。

2/不要试图通过减少视图数量来优化视图。不要在代码中创建UIImageView而不是xib，因为你想在其中添加子视图。使用UIImageView作为背景。视图框架可以毫无问题地处理数百个视图。

3/ iboutlet不需要总是被保留(或强大)。注意，大多数iboutlet都是视图层次结构的一部分，因此隐式保留。

4/释放viewDidUnload中的所有iboutlet

5/从dealloc方法调用viewDidUnload。它不是隐式调用的。

内存

1/创建对象时自动释放对象。许多错误是由于将释放调用移动到一个if-else分支或在返回语句之后引起的。释放而不是自动释放应该只在特殊情况下使用——例如，当你在等待一个运行循环时，你不想让你的对象过早被自动释放。

2/即使你在使用自动引用计数，你也必须完全理解保留-释放方法是如何工作的。手动使用保留-释放并不比ARC更复杂，在这两种情况下，您都必须考虑泄漏和保留周期。 考虑在大型项目或复杂的对象层次结构上手动使用保留释放。

评论

1/让你的代码自动文档化。 每个变量名和方法名都应该说明它在做什么。如果代码编写正确(这方面需要大量实践)，则不需要任何代码注释(与文档注释不同)。算法可能很复杂，但代码应该总是简单的。

2/有时候，你需要别人的评论。通常用来描述一种不明显的代码行为或黑客行为。如果您觉得必须写注释，首先尝试重写代码，使其更简单，不需要注释。

缩进

1/不要增加太多缩进。 大多数方法代码应该在方法级别上缩进。嵌套块(if, for等)降低了可读性。如果您有三个嵌套块，您应该尝试将内部块放入一个单独的方法中。四个或更多嵌套的块永远不应该使用。 如果大部分方法代码都在If中，则对If条件求反，例如:

if (self) {
   //... long initialization code ...
}

return self;

if (!self) {
   return nil;
}

//... long initialization code ...

return self;

了解C代码，主要是C结构

注意Obj-C只是C语言之上的一个轻量级OOP层。你应该了解C语言的基本代码结构(枚举、结构体、数组、指针等)是如何工作的。 例子:

view.frame = CGRectMake(view.frame.origin.x, view.frame.origin.y, view.frame.size.width, view.frame.size.height + 20);

等于:

CGRect frame = view.frame;
frame.size.height += 20;
view.frame = frame;

还有更多

维护自己的编码标准文档，并经常更新它。试着从错误中学习。理解错误产生的原因，并尝试使用编码标准来避免它。

我们的编码标准目前大约有20页，混合了Java编码标准，谷歌Obj-C/ c++标准和我们自己的添加。记录你的代码，在正确的地方使用标准的缩进，空格和空行等等。

其中一些已经被提到过，但以下是我能想到的:

Follow KVO naming rules. Even if you don't use KVO now, in my experience often times it's still beneficial in the future. And if you are using KVO or bindings, you need to know things are going work the way they are supposed to. This covers not just accessor methods and instance variables, but to-many relationships, validation, auto-notifying dependent keys, and so on. Put private methods in a category. Not just the interface, but the implementation as well. It's good to have some distance conceptually between private and non-private methods. I include everything in my .m file. Put background thread methods in a category. Same as above. I've found it's good to keep a clear conceptual barrier when you're thinking about what's on the main thread and what's not. Use #pragma mark [section]. Usually I group by my own methods, each subclass's overrides, and any information or formal protocols. This makes it a lot easier to jump to exactly what I'm looking for. On the same topic, group similar methods (like a table view's delegate methods) together, don't just stick them anywhere. Prefix private methods & ivars with _. I like the way it looks, and I'm less likely to use an ivar when I mean a property by accident. Don't use mutator methods / properties in init & dealloc. I've never had anything bad happen because of it, but I can see the logic if you change the method to do something that depends on the state of your object. Put IBOutlets in properties. I actually just read this one here, but I'm going to start doing it. Regardless of any memory benefits, it seems better stylistically (at least to me). Avoid writing code you don't absolutely need. This really covers a lot of things, like making ivars when a #define will do, or caching an array instead of sorting it each time the data is needed. There's a lot I could say about this, but the bottom line is don't write code until you need it, or the profiler tells you to. It makes things a lot easier to maintain in the long run. Finish what you start. Having a lot of half-finished, buggy code is the fastest way to kill a project dead. If you need a stub method that's fine, just indicate it by putting NSLog( @"stub" ) inside, or however you want to keep track of things.

如果您使用的是Leopard (Mac OS X 10.5)或更高版本，则可以使用Instruments应用程序来查找和跟踪内存泄漏。在Xcode中构建程序后，选择使用性能工具> Leaks运行>。

即使你的应用程序没有显示任何泄漏，你可能把对象保存得太久了。在Instruments中，您可以为此使用ObjectAlloc工具。在Instruments文档中选择ObjectAlloc乐器，并通过选择View > detail(它旁边应该有一个复选标记)来显示乐器的详细信息(如果还没有显示的话)。在ObjectAlloc详细信息中的“分配生命周期”下，确保选择“已创建和仍然存在”旁边的单选按钮。

现在，每当您停止记录应用程序时，选择ObjectAlloc工具将在“# Net”列中显示对应用程序中每个仍然活动的对象的引用数。确保不仅要查看自己的类，还要查看NIB文件的顶级对象的类。例如，如果你在屏幕上没有窗口，而你看到一个仍然存在的NSWindow的引用，你可能没有在你的代码中释放它。