2009-07-13 12 views
4

私はInstrument LeakでiPhoneアプリケーションを実行し、NSDateFormatterを使ってNSDateの束を解析すると、私のメモリは約1MBになり、解析後にこれらのNSDateをdeallocする必要があります彼らが新しいものでないならば)。Instruments(Leaks)とNSDateFormatter

malloc(私の重いスタックトレースの下)はNSDateの一部になる可能性があると思っていましたが、解析中の中間ステップでのみ使用されるメモリである可能性も考えました。誰がそれを知っていますか、それを知る方法はありますか?

NSDate deallocにブレークポイントを設定して、そのメモリが実際に再利用されているかどうかを確認する方法はありますか?

はここに私の日付フォーマッタは、これらの日付を解析するため、次のようになります。メモリは最大バンプ、そこにとどまるとき

df = [[NSDateFormatter alloc] init]; 
[df setDateFormat:@"EEE, d MMM yyyy H:m:s z"]; 

ここでは最も重いスタックトレースです:

0 libSystem.B.dylib 208.80 Kb  malloc 
    1 libicucore.A.dylib 868.19 Kb  icu::ZoneMeta::getSingleCountry(icu::UnicodeString const&, icu::UnicodeString&) 
    2 libicucore.A.dylib 868.66 Kb  icu::ZoneMeta::getSingleCountry(icu::UnicodeString const&, icu::UnicodeString&) 
    3 libicucore.A.dylib 868.67 Kb  icu::ZoneMeta::getSingleCountry(icu::UnicodeString const&, icu::UnicodeString&) 
    4 libicucore.A.dylib 868.67 Kb  icu::DateFormatSymbols::initZoneStringFormat() 
    5 libicucore.A.dylib 868.67 Kb  icu::DateFormatSymbols::getZoneStringFormat() const 
    6 libicucore.A.dylib 868.67 Kb  icu::SimpleDateFormat::subParse(icu::UnicodeString const&, int&, unsigned short, int, signed char, signed char, signed char*, icu::Calendar&) const 
    7 libicucore.A.dylib 868.67 Kb  icu::SimpleDateFormat::parse(icu::UnicodeString const&, icu::Calendar&, icu::ParsePosition&) const 
    8 libicucore.A.dylib 868.67 Kb  icu::DateFormat::parse(icu::UnicodeString const&, icu::ParsePosition&) const 
    9 libicucore.A.dylib 868.67 Kb  udat_parse 
    10 CoreFoundation 868.67 Kb  CFDateFormatterGetAbsoluteTimeFromString 
    11 CoreFoundation 868.67 Kb  CFDateFormatterCreateDateFromString 
    12 Foundation 868.67 Kb  -[NSDateFormatter getObjectValue:forString:range:error:] 
    13 Foundation 868.75 Kb  -[NSDateFormatter getObjectValue:forString:errorDescription:] 
    14 Foundation 868.75 Kb  -[NSDateFormatter dateFromString:] 

ありがとう!

答えて

0

NSDateFormattersを破棄してどういう意味ですか?あなたは彼らと一緒にやったときに解放しますか?

df = [[NSDateFormatter alloc] init]; // allocates memory 

あなたのコードは、メモリを割り当てていますが、あなたは彼らと一緒に行われたときに

[df release]; 

を呼び出す必要があります。オブジェクトを割り当てる(またはコピーする)と、その参照カウントは1だけインクリメントされます。オブジェクトを解放すると(releaseメッセージが送信されます)、参照カウントは1つ下がります。参照カウントが0になると、オブジェクトの割り当てが解除されます。

メッセージをreleaseに送信しないと、メモリに残り、メモリリークが発生します。

+0

で読み取ることができます。上記のスタックトレースからわかるように、私は[NSDateFormatter dateFromString]を使用してNSDateオブジェクトを作成していますが、これはmallocコールで終了します。これはInstrumentsからのHeaviestスタックトレースに表示されます(BTWはHeavyest私が投稿したスタックトレース)。 – Cal

+0

dateFromStringは自動解放されたオブジェクトを返します。多くの自動リリースされたNSDateを作成している場合は、次の偶数ループまでぶら下がり、そこで清掃されます。これは、オートレリースされたオブジェクトが処理プールの最後でクリーニングされるプールに終わるためです。日付を大量に作成していると、メモリ使用量が急上昇している可能性があります。 – stefanB

1

タイムゾーン付きの日付文字列を解析する際に問題が発生する可能性があります。タイムゾーン部分を削除するようにフォーマッタパターンを変更したときに問題が消えたからです。

私はこのことから、それを変更:これに

[df setDateFormat:@"EEE, d MMM yyyy H:m:s z"]; 

[df setDateFormat:@"EEE, d MMM yyyy H:m:s"]; 

しかし、今の問題は、私が判断するために持っている必要がありますので、日付が正しいタイムゾーンを取得しないで自分自身のタイムゾーン。

+0

Cocoa-devメーリングリストにそれに関するスレッドがあります:http://lists.apple.com/archives/Cocoa-dev/2009/Apr/msg01913.html – IlDan

3
[df setDateFormat:@"EEE, d MMM yyyy H:m:s z"]; // Remove the `z` 

868 KBは、恒久的にZオプションが使用されている「dateFromString」への単一の呼び出し後にiPhone OS 2.2.1または3.1.2(来てそれ以上)に割り当てられます。

ソースコードとの完全な記事やログファイルには、私はそれらを捨てる言った時、私はNSDatesに参照のうえた http://thegothicparty.com/dev/article/nsdateformatter-memory-leak/