データと UI を更新する 1 つのメソッドを実行するたびに、ヒープの増加を発見しました。Inspector に表示される内容は次のとおり
です。メソッドを実行するたびに、ヒープが約 1MB 増加します。数回の通話の後、アプリがクラッシュします。
コールスタックをたどると、次の静的関数が見つかりました。
コードにメモリ リークが見つかりません。助けてください。(アークはオン)
アップデート：
だから今、私はその静的メソッドで 1つの NSCalendar オブジェクトを使用しています。
そして今、インスペクタは、コードに接続されていない多くのメモリ アドレスを表示します。
それほど多くを作成する必要はありませんNSCalendars- を再利用しautoupdatingCurrentCalendar (ivar に保存するGraphControllerなど)、それを に渡すと、-dateDifferenceFromDate:to:カレンダーの作成を (事実上) なくすことができます。
アップデート
これは放棄されたメモリに役立ちますか、それとも速度を向上させるだけですか?
この提案がどの程度役立つかを確認する最善の方法は、測定することです。スクリーンショットは、ICU タイムゾーン (カレンダーで使用される) の作成が最も重い部分であることを示しています。IDK グラフを描画するときにこれを呼び出す回数 (つまりNSCalendars、作成した回数、または実装がこの API を介して情報を共有/キャッシュするかどうか) ... しかし、あなたが提示した情報は、それが「多く」であると私に信じさせます-そしてそれはですへの呼び出しごとに 1 つのカレンダー-dateDifferenceFromDate:to:。
そうです、（不要な）重複オブジェクトを排除できます-[NSCalendar currentCalendar]シングルトンを返しません（あなたのサンプルはそれを示しています）。
NSDateComponentsまた、カレンダー インスタンスを参照する場合があることに注意してください。
カレンダーの作成には、非常に時間がかかる場合があります (メモリだけでなく)。
また、スレッドセーフでNSCalendarはないことに注意してください。
したがって、プログラムはおそらく不必要に多くの一時ファイルを作成します。ほとんどの (すべてではないにしても) メモリは「すぐに」解放されますが、「計算」することがたくさんある場合は、自動解放プールに大量の預金がある可能性があります (最終的には枯渇します)。これを減らすために内部自動解放プールを作成できますが、1 つのカレンダーを使用すると、速度とメモリを簡単に最適化できます。
多くのシステム API はバックグラウンドでキャッシュされ、驚くほどメモリが増加しますが、これがその 1 つであれば IDK.
このブログ投稿も興味深いかもしれません: http://www.mikeabdullah.net/NSCalendar_currentCalendar.html
しかし、実際には、単一の自動更新カレンダーを使用してから測定するだけです. そうすれば、それが実装にどれだけ役立つかがわかります。