3

開発中のアプリをテストしているときに、この問題に遭遇しました。これについて説明したいと思います。サーバーからメッセージを受信する必要があり、メッセージをビューに中継する必要があるクラスがあります。これは私がそれを行う方法です：

- (void) onMessage:(DFTopicMessage *) message {    
    [[NSNotificationCenter defaultCenter] 
     postNotificationName:@"serverMessage" 
     object:message];
}

クラスはメッセージに対して他に何もしません。Instruments -> Leaks でプロファイリングすると、このコード行は潜在的なリークとしてフラグが立てられます。私が理解している問題は、メッセージが割り当てられ、使用され、決して解放されないということです。最初の奇妙なことは、プロジェクトで ARC を使用しているため、OS が変数を自動的に解放することを期待していることですが、明らかにそうではありません (では、なぜ変数を解放しないのでしょうか?)。どうにかして、このリークを回避する方法を考え始めました。次のように、単純に message を nil に設定します。

- (void) onMessage:(DFTopicMessage *) message {    
    [[NSNotificationCenter defaultCenter] 
     postNotificationName:@"serverMessage" 
     object:message];
      message = nil;
}

漏れは防げません。メッセージを ivar にして、次のようなアクセサーを使用することで解決策を見つけました。

@interface myClass()
@property(nonatomic) DFTopicMessage *message;
@end

@implementation myClass {
@synthetize message;
    ....
   - (void) onMessage:(DFTopicMessage *) msg {
        [self setMessage:msg];

        [[NSNotificationCenter defaultCenter] 
        postNotificationName:@"serverMessage" 
        object:[self message]];

    }
}

以下の方法でプロファイリングすると、Instruments -> Leak はこれを潜在的なリークとしてフラグ付けしなくなります。私の質問は次のとおりです: これは、ARC を使用するときに var を強制的に解放する唯一の解決策ですか?

前もって感謝します！

4

1 に答える 1

0

プロジェクトを分析すると、このメソッドにもリークの可能性があるとフラグが立てられますか?(そうではないのではないかと思います)。

Instruments が検出しているリークがこのメッセージ オブジェクトであると確信していますか? そうである場合、ARC が有効になっているため、これはリークしていないはずなので、誤検知である必要があるように見えます。

于 2012-09-04T10:27:46.090 に答える