ARCにするか、ARCしないか？長所と短所は何ですか？[閉まっている]

私が現在取り組んでいるプロジェクトのコードの大部分はiOS 5.0より前に記述されているため、まだARCを使用していません。

私はただ疑問に思っていましたが、手動で保持/解放しないことの便利さ（そして結果としておそらくより信頼性の高いコードですか？）は、ARCを使用することの「コスト」を上回りますか？ARCについてどのような経験がありますか。それをお勧めしますか？

そう：

• ARCはプロジェクトにどのくらいのメリットをもたらしますか？
• ARCにはJavaのガベージコレクションのようなコストがありますか？
• ARCを使用していますか。使用している場合、それをどのように見つけましたか？

欠点はありません。これを使って。今日それをしてください。古いコードよりも高速です。古いコードよりも安全です。古いコードより簡単です。ガベージコレクションではありません。GCランタイムのオーバーヘッドはありません。コンパイラーは、保持する必要があるすべての場所に保持と解放を挿入します。しかし、それはあなたよりも賢く、実際に必要でないものを最適化できます（ループを展開したり、一時変数、インライン関数などを削除したりできるのと同じように）。

さて、ここで小さな欠点について説明します。

• 長期にわたるObjC開発者の場合、ARCコードが表示されると、約1週間はけいれんします。あなたはこれをすぐに乗り越えるでしょう。

• Core Foundationコードへのブリッジングには、いくつかの（非常に）複雑な問題があります。をidとして扱うものを処理する場合、少し複雑になりvoid*ます。C配列のようなものidは、正しく実行するためにもう少し考える必要があります。ObjCの派手な処理va_argsも問題を引き起こす可能性があります。ObjCポインターの数学に関連するほとんどのことはトリッキーです。いずれにしても、これはあまり必要ありません。

• あなたは置くことができませんidでstruct。これはかなりまれですが、データのパックに使用されることもあります。

• 正しいKVC命名に従っていない場合、ARCコードと非ARCコードを混在させると、メモリの問題が発生します。ARCは、KVCネーミングを使用してメモリ管理に関する決定を行います。それがすべてARCコードである場合、両側で同じ「間違った」処理を行うため、問題ではありません。ただし、ARCと非ARCが混在している場合は、不一致があります。

• ARCは、ObjC例外のスロー中にメモリをリークします。ObjC例外は、プログラムの終了に非常に近い時間である必要があります。大量のObjC例外をキャッチしている場合は、それらを誤って使用しています。これはを使用し-fobjc-arc-exceptionsて修正できますが、以下で説明するペナルティが発生します。

• ARCは、ObjC ++コードでのObjCまたはC ++例外のスロー中にメモリをリークしませんが、これは時間とスペースの両方のパフォーマンスを犠牲にします。これは、ObjC ++の使用を最小限に抑えるための長い理由リストのもう1つです。

• ARCは、iPhoneOS 3またはMac OS X 10.5以前ではまったく機能しません。（これにより、多くのプロジェクトでARCを使用できなくなります。）

• __weakポインタはiOS 4またはMac OS X 10.6では正しく機能しません。これは残念ですが、かなり簡単に回避できます。__weakポインターは素晴らしいですが、ARCの最大のセールスポイントではありません。

95％以上のコードについては、ARCは優れており、それを回避する理由はまったくありません（OSバージョンの制限を処理できる場合）。ARC以外のコードの場合、-fno-objc-arcファイルごとに渡すことができます。残念ながら、Xcodeを使用すると、実際に行うよりもはるかに困難になります。これを簡略化するには、おそらく非ARCコードを別のxcodeprojに移動する必要があります。

結論として、できる限り早くARCに切り替えてください。

編集

「ARCを使用することは、Cocoaのメモリ管理ルールを知ることの代わりにはならない」というコメントを2度目にしました。これはほとんどの場合真実ですが、その理由とそうでない理由を理解することが重要です。まず、すべてのコードがARCを使用していて、3つの魔法の言葉に違反している場合いたるところに問題はありません。と言って衝撃的ですが、そこに行きます。ARCは、保持するつもりでなかったいくつかのことを保持する可能性がありますが、それらも解放するため、重要ではありません。今日、Cocoaで新しいクラスを教えているとしたら、実際のメモリ管理規則に費やす時間は5分以内であり、KVCの命名については、メモリ管理の命名規則についてのみ言及するでしょう。ARCがあれば、メモリ管理のルールをまったく学ばなくても、まともな初心者プログラマになることができると思います。

しかし、あなたはまともな中間プログラマーになることができませんでした。Core Foundationと正しく橋渡しするためにはルールを知る必要があり、すべての中間プログラマーはある時点でCFに対処する必要があります。そして、ARC / MRC混合コードのルールを知る必要があります。また、void*ポインタid（KVOを正しく実行するために引き続き必要）をいじり始めるときのルールを知っておく必要があります。そして、ブロック...まあ、ブロックメモリ管理は奇妙です。

したがって、私のポイントは、基礎となるメモリ管理が依然として重要であるということですが、以前は新しいプログラマのためにルールの説明と再説明にかなりの時間を費やしていたのですが、ARCではより高度なトピックになっています。新しい開発者に、根底にあるへの呼び出しで頭を埋めるのではなく、オブジェクトグラフの観点から考えてもらいたいと思いますobjc_retain()。

私よりも優れた、より技術的な答えが得られますが、ここに行きます：

• ARC！=ガベージコレクション。実行時のペナルティはありません。コンパイル時に行われます。
• ARCも！=コメントで提案したように、すべてを自動的に解放します。ドキュメントを読む
• あなたはどのくらいのマニュアルの参照管理を実現一度それは素晴らしいですし、やって
• これを使って！
• 1つの欠点-古い非アークコードを維持することは、突然非常に退屈になります。

ARCはプロジェクトにどのくらいのメリットをもたらしますか？

利点は、一般的なメモリ管理の誤りからのかなりの程度の保護です。オブジェクトの解放に失敗したことによるリークと、オブジェクトの保持または早期解放に失敗したことによるクラッシュは、大幅に削減する必要があります。参照カウントメモリモデルを理解して、参照を強いか弱いかで分類したり、保持サイクルを回避したりする必要があります。

ガベージコレクションは実際にどのくらい「コスト」をかけますか？

iOSにはガベージコレクションはありません。ARCは、オブジェクトを手動で保持または解放する必要がないという点でGCに似ています。ガベージコレクタがないという点で、GCとは異なります。保持/解放モデルは引き続き適用され、コンパイラがコンパイル時に適切なメモリ管理呼び出しをコードに挿入するだけです。

ARCを使用していますか。使用している場合、それをどのように見つけましたか？

カウントを参照することに慣れていると少し戸惑うかもしれませんが、それは慣れ、コンパイラが本当に正しいことをすることを信頼することを学ぶことの問題です。これは、Objective-C 2.0に付随するプロパティの変更の継続のように感じられます。これは、メモリ管理を簡素化するためのもう1つの大きなステップでした。手動のメモリ管理呼び出しがないと、コードは少し短くなり、読みやすくなります。

ARCの唯一の問題は、それが古いバージョンのiOSではサポートされていないことです。そのため、ARCを採用する前に、それを考慮する必要があります。

ARCは素晴らしいアイデアだと思います。GCと比較して、ケーキを食べて食べることができます。私は、MRCがメモリ管理にかけがえのない「規律」を課し、誰もが持つことで利益を得られると信じがちです。しかし、私が気づくべき本当の問題は、オブジェクト所有権とオブジェクトグラフ（多くの人が指摘したとおり）であり、低レベルの参照カウント自体ではないことにも同意します。

結論として：ARCは、メモリについて気にしない自由なパスではありません。これは、ストレスを引き起こし、エラーが発生しやすい反復作業を回避するためのツールであるため、マシン（この場合はコンパイラ）に委任する方が適切です。

そうは言っても、私は職人のようなもので、まだ移行はしていません。Gitを使い始めたばかりです...

更新：私はゲーム全体を移行し、glライブラリを含めて、今のところ問題はありません（Xcode 4.2の移行アシスタントを除く）。あなたが新しいプロジェクトを始めているなら、それのために行ってください。

私はいくつかの（確かに小規模な）プロジェクトでそれを使用しており、パフォーマンスと信頼性の両方に関して、良い経験しかありません。

マイナーな注意事項の1つは、UIを自分でコーディングしている場合に参照ループを引き起こさないように、弱参照のdo：sとnot：sを学ぶ必要があることです。デザイナーはそれをうまく行う傾向があります。それを使用してGUIを設定すると、自動的に。

私が遭遇した唯一の欠点は、多数のCoreFoundation関数とデータを含むライブラリを使用する場合です。MRC CFStringRefでは、の代わりにを使用することを心配する必要はありませんでしたNSString*。ARCでは、2つがどのように相互作用するかを指定する必要があります（基本的なブリッジ？CoreFoundationオブジェクトを解放してARCに移動する？Cocoaオブジェクトを+1 CoreFoundation保持オブジェクトにする？）また、OS Xでは、64でのみ使用できます。ビットコード（私はそれを回避するヘッダーを持っていますが...）。