引き続き注意する必要があるプライマリ メモリ関連の問題は、リテイン サイクルです。これは、あるオブジェクトが別のオブジェクトへの強力なポインターを持っているが、ターゲット オブジェクトが元のオブジェクトへの強力なポインターを持っている場合に発生します。これらのオブジェクトへの他のすべての参照が削除された場合でも、それらは互いに保持され、解放されません。これは、チェーンの最後のオブジェクトが以前のオブジェクトを参照している可能性があるオブジェクトのチェーンによって、間接的に発生することもあります。
__unsafe_unretainedおよび__weak所有権修飾子が存在するのはこのためです。前者はそれが指すオブジェクトを保持しませんが、そのオブジェクトが消えて不良メモリを指す可能性を残しますが、後者はオブジェクトを保持せず、ターゲットが割り当て解除されると自動的に nil に設定されます。2 つのうち、__weakそれをサポートするプラットフォームでは一般に好まれます。
これらの修飾子は、デリゲートなど、オブジェクトがデリゲートを保持したくない場合に使用し、サイクルが発生する可能性があります。
メモリ関連のもう 1 つの重要な問題は、Core Foundation オブジェクトの処理と、 などmalloc()の型を使用して割り当てられたメモリchar*です。ARC はこれらの型を管理せず、Objective-C オブジェクトのみを管理するため、自分で処理する必要があります。Core Foundation 型は、対応する Objective-C オブジェクトにブリッジする必要がある場合があり、その逆も同様であるため、特に注意が必要です。これは、CF 型と Objective-C の間を橋渡しするときに、制御を ARC から前後に転送する必要があることを意味します。このブリッジングに関連するいくつかのキーワードが追加されました。Mike Ash は、彼の長い ARC の記事で、さまざまなブリッジングのケースについて優れた説明をしています。
これに加えて、頻度は低いものの潜在的に問題のあるケースが他にもいくつかあり、公開された仕様で詳しく説明されています。
オブジェクトへの強力なポインタがある限りオブジェクトを保持するという新しい動作の多くは、Mac のガベージ コレクションに非常に似ています。ただし、技術的な基盤は大きく異なります。ガベージ コレクター プロセスを定期的に実行してポイントされなくなったオブジェクトをクリーンアップするのではなく、このスタイルのメモリ管理は、Objective-C で従う必要がある厳密な保持/解放ルールに依存しています。
ARC は、何年にもわたって行わなければならなかった繰り返しのメモリ管理タスクをコンパイラにオフロードするだけなので、二度と心配する必要はありません。このようにすると、ガベージ コレクション プラットフォームで発生する停止の問題やノコギリのメモリ プロファイルは発生しません。私はガベージ コレクションを行った Mac アプリケーションでこれらの両方を経験しており、ARC の下でそれらがどのように動作するかを知りたいと思っています。
ガベージ コレクションと ARC の詳細については、Objective-C メーリング リストでの Chris Lattner による非常に興味深い回答を参照してください。彼は、Objective-C 2.0 ガベージ コレクションに対する ARC の多くの利点を挙げています。彼が説明するGCの問題のいくつかに遭遇しました。