0

私のアプリケーションのセカンダリスレッドの実行ループは以下のとおりです。ネストされた制御ループがあります。

  • 外側のループは、アプリケーションの実行中実行されます
  • 1つのビューが開いている間、内側のループが実行され、ビューが開いていない間、スレッドは待機します。
  • 内側のループを通過する時間は短く、ほんの一瞬です。

私のコードは、自動リリースされたオブジェクトをリリースされていないプールに故意に残しませんが、OSが何をしているのかわかりません。

メインスレッドでは、cocoaは実行ループを通過するたびに自動解放プールをラップします。
この二次スレッドでは、最も近いものは内側のループを通過することだと思います。

内部自動解放プールは、内部ループを通過する各パスをラップします。

中央のプールは内部ループをラップアラウンドするため、このレベルで作成および自動解放されたオブジェクトは、アプリケーションが終了するまで保持されません。

外側のプールはランループ全体をラップします。

これらすべてのプールの作成と解放がコードの速度にどのような影響を与えているかをどのように判断できますか。
3つのプールすべてが必要か、過剰かを判断するにはどうすればよいですか？




コードと説明：

- (void)processLoop
{

    NSAutoreleasePool * outerPool = [[NSAutoreleasePool alloc] init];
    [processCondition lock];

    //outer loop    
    //this loop runs until my application exits
    while (![[NSThread currentThread] isCancelled])    
    {
        NSAutoreleasePool *middlePool = [[NSAutoreleasePool alloc];
        if(processGo)
        {
            //inner loop
            //this loop runs typically for a few seconds
            while (processGo && ![[NSThread currentThread] isCancelled]) 
            {
                NSAutoreleasePool *innerPool = [[NSAutoreleasePool alloc]; init];
                //within inner loop
                //this takes a fraction of a second
                [self doSomething];
                [innerPool release];
            }
            [self tidyThingsUp];

        }
        else
        {
            [processCondition wait];
        } 
        [middlePool release];
    }
    [processCondition unlock];
    [outerPool release];
}

の組み合わせ：

  • 内側のwhileループ
  • NSCondition * processCondition
  • processGoとの間YESで切り替えるNO

スレッドをキャンセルせずに、内側のwhileループを停止および開始できます。

if (processGo == YES)


実行は内部のwhileループに入ります。

メインスレッドが設定されたとき

processGo = NO

実行は内側のwhileループを離れ
、外側のループの次のパスで整理され、実行がヒットします

[processCondition wait]

待って

メインスレッドがリセットされた場合

processGo == YES

と呼び出し

[processCondition wait]

実行は内部ループに再び入ります

4

2 に答える 2

5

これらのメソッドのいくつかが何をするかを知らなければ、あまりにも決定的な答えを出すことはできませんが、自動解放プールを適用する際の大きな懸念は、各プールが処理するオブジェクトの数と関係があります。

NSObject の 100 万個のインスタンスの作成と破棄に対する追加の自動解放プールの効果を調べた興味深いブログ投稿があります。投稿の要点は、「自動解放プールは安価です」と述べています。プログラムは、1 プールあたりのオブジェクト数が 10 オブジェクト/1 プールの比率になるまで、より効率的になり続けています。（その後、すべてのオブジェクトのプールを作成することに急速に近づいているため、急増します。これは明らかにばかげています。）

最善の方法は、各リリース プールが処理するオブジェクトの数を大まかに把握することです。たとえば、内側のプールがパスごとに 100 個のオブジェクトを処理し、100 個のパスがある場合、そのプールを取り除くと、1 万個のオブジェクトが中央のプールに追加されます。これは悪いことです。一方、内部プールが 10 回のパスごとに 1 つのオブジェクトを処理する場合は、先に進んでそれを取り除きます。

決定できない場合は、内側のループのみ、または中央のプールの範囲内で実行されるコードのみのパフォーマンスを測定する方法を見つけられるかどうかを確認し、必要に応じて自動解放プールを追加/削除します。そして覚えておいてください: 自動解放プールは安価です。

于 2009-07-20T04:55:44.707 に答える
1

3 つのプールすべてが必要か、それとも過剰かを判断するにはどうすればよいですか?

いくつかのプールにコメントを付けて、アプリケーション メモリで何が起こるかを確認することができます。

これらすべてのプールの作成と解放がコードの速度にどのような影響を与えているかを判断するにはどうすればよいですか?

ゲームのメインループ内で自動解放プールを作成して解放していますが、完全に正常に動作します。しゃっくりなし、ほとんど時間がかかりません。

于 2009-07-20T05:00:23.060 に答える