#import <UIKit/UIKit.h>
int main(int argc, char *argv[]) {
NSLog(@"new event...");
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
この場合、main（）関数をすべてのイベントで呼び出す必要がありますか？しかし、私はそれを試して、 "新しいイベント..."ログメッセージはちょうどアプリの開始時に来る。だから私はメインスレッドに別の自動解放プールがなければならないと思います。はmain.m実際に場所です、メイン実行ループの自動解放プールはすべてのイベントによって作成されますか？
すべてのココアまたはCocoaTouchクラスでは、メモリをリークさせないためにオートリリースプールが必要です。したがって、既存の自動解放プールは、UIApplicationMain（）のコンテキストでインスタンス化される（おそらく）自動リリースされたオブジェクトをカバーするためにUIApplicationMain（）を呼び出す必要があります。この外側の自動解放プールは、UIApplicationMainの返却後に、アプリケーションが終了する直前に排水されているのがわかります。内部（autoreleaseプールはネストすることができ、自動解放されたオブジェクトは最新の/最も深いプールに追加されることを覚えておいてください）autoreleaseプールは、アプリケーションの実行ループの各繰り返しの始めに作成され、繰り返しの終わりに解放されます。したがって、実行ループの各反復は「独自の」自動解放プールになります。イベントを処理すると、多くの自動リリースされたメモリ（iPhoneでは悪いアイデアだが、OS Xではかなり一般的）が生成される場合は、その処理中にリリースされるイベント処理コードに独自の内部自動解放プールを作成することができますイベント。
いいえ、これはアプリケーションの最も外側の関数で、通常のCスタイルのmain（）です。
すべてのイベント処理を含む、iPhoneアプリケーションがUIApplicationMainで実行されます。
一番外側の 'main（）'自動解放プールのポイントは何ですか？すべてのアプリケーションメモリは、終了時にOSによって再利用されるためですか？そして、なぜAppleがUIApplicationMain（）の実装の中にトップレベルの自動解放プールを含んでいないのか不思議です。 –
ありがとうございます。 UIApplicationMain（）のメイン実行ループの横にあるものがあるかもしれません。 – Thanks
+ initializeメソッドは、最初のメッセージを受信する前にクラスに送信されます。 UIApplicationMain（またはユーザが提供する置換）の作者が、自動解放プールをインスタンス化するのに非常に注意しない限り、Cocoa由来クラスへの他の呼び出しはメモリリークを引き起こす可能性があります。最も安全な計画は、Cocoaに依存するコードを呼び出す前に、自動解放プールを用意することです。 UIApplicationMainはもちろん、独自の自動解放プールを作成することもできます。 –