ARCを使用することの長所と短所は何ですか？
IOSプロジェクトで新しい自動参照カウント（ARC）メモリ管理スタイルを使用することの長所と短所は何ですか？
IOS 5.0 SDKで開発するときにARCを使用しないことを選択できますか？
新しいプロジェクトにARCまたは手動参照カウント（MRC）をお勧めしますか？
ARCを使用するアプリケーションはiOS5.0より古いバージョンのOSで実行できますか？
IOSプロジェクトで新しい自動参照カウント（ARC）メモリ管理スタイルを使用することの長所と短所は何ですか？
ARCプログラムの実行は、適切に記述されたMRCとほぼ同じです。つまり、操作の順序とパフォーマンスの両方が非常に近いため、動作の違いは検出できないことがよくあります。
手動参照カウント（MRC）を使用してOS XまたはiOSアプリを実装する方法を既に知っている場合、ARCは実際には機能を追加しません。ソースから参照カウント操作を削除するだけです。
MRCを学びたくない場合は、最初にARCを試してみることをお勧めします。多くの人がMRCの一般的な慣行に苦労したり、無視しようとしたりします（例：静的アナライザーに多数のobjc開発者を紹介しました）。これらの問題を回避したい場合は、ARCを使用して理解を延期することができます。 MRC、ARC、GCのいずれであっても、参照カウントとオブジェクトの有効期間および関係を理解せずに、重要なobjcプログラムを作成することはできません。 ARCとGCは、単にソースから実装を削除し、正しいことを行いますほとんどの場合。 ARCとGCを使用する場合でも、いくつかのガイダンスを提供する必要があります。
私はこれを測定していませんが、コンパイルARCソースにはより多くの時間とリソースがかかることを言及する価値があるかもしれません。
開発中のプログラムの参照カウントの使用がかなり緩い場合（たとえば、自動リリースの一般的な量）、ARCcouldに切り替えると、プログラムの実行時間とピークメモリが大幅に向上します。使用法。
IOS 5.0 SDKで開発するときにARCを使用しないことを選択できますか？
はい、CLANG_ENABLE_OBJC_ARCを使用しています。 ARCはバイナリ互換であり、実際に発生するのは、コンパイラが、現在の翻訳に表示される宣言に基づいて、適切な参照カウント操作を自動的に導入するために最善を尽くすことです（ 翻訳の理由については、ここで私の回答を参照してください）可視性が重要です ）。したがって、プロジェクト内の一部のソースで有効または無効にしたり、他のソースで有効にしたりすることもできます。
ただし、混合モード（一部のMRCおよび一部のARCソース）は非常に複雑であり、微妙に、特にコンパイラによって複製される可能性のあるwrt実装（たとえば、インライン関数の本体が正しくない可能性があります）。このような混合モードの問題を特定するのは非常に困難です。 ObjC++プログラムとソースは特にこの点で難しいでしょう。さらに、動作は最適化設定に基づいて異なる場合があります（一例として）。デバッグビルドで完全に機能するプログラムは、リリース時にリークまたはゾンビを引き起こす可能性があります。
新しいプロジェクトにARCまたは手動参照カウント（MRC）をお勧めしますか？
個人的には、しばらくはMRCを使い続けます。 ARCが実際の使用法でテストされたとしても、複雑なシナリオで現れる多くの問題が残っている可能性があり、最初に知ってデバッグすることは避けたいと思うでしょう。 OS Xのガベージコレクションは、待ちたくなる理由の一例です。一例として、オブジェクトが破棄されるとスイッチが変更される可能性があります。オブジェクトはより早く破棄され、自動解放プールに配置されない場合があります。また、ivarがリリースされる順序が変更される可能性があり、いくつかの副作用が発生する可能性があります。
また、現時点でこの機能をテストするために1週間を失いたくない大規模なコードベースもあります。最後に、下位互換性は私にとって依然として重要です。
ARCを使用するアプリケーションはiOS5.0より古いバージョンのOSで実行できますか？
MRCを使用して開発する場合、下位互換性があります。 ARCを使用して開発する場合、必ずしも互換性があるとは限りません。実際、少し余分な作業をしなければコンパイルすらできないかもしれません。ランタイムの要件は、一部の以前のバージョンで利用できます。 この質問も参照 。下位互換性が必要な場合、一部のOSバージョンではARCはオプションになりません。
最後に、選択をGCまたはARCに限定する場合は、ARCをお勧めします。
CLANG_ENABLE_OBJC_ARC = NOを使用してオフ/オンにする利点は、記述するコードが少なくて済み、メモリ管理が簡単になることです。不利な点は、メモリ管理について学んだことをすべてスクラッチしなければならないことです:)私はそれをオフにすることを好みます。
私はLionとxcode4.3を使用しています。私も同じ問題を抱えていました。
これを修正するために、「ビルド設定-> Objective-C自動参照Co」を「いいえ」に変更しました。
「はい」に設定されていることを確認するには、「ビルド設定」ツールバーのすぐ下にあるツールバーの「すべて」および「レベル」オプションも有効にする必要がありました。
これらのオプションを有効にすると、プロジェクトでそのオプションが「はい」に設定されていることがわかりました。デフォルト設定が「いいえ」であることがわかるのに少し時間がかかりました。これは、「レベル」オプションを有効にするまで表示されていたものです。
「編集->リファクタリング-> Objective C Arcに変換」でARCをオンにできます。これにより、コードが完全にリファクタリングされます（すべてのメモリ管理呼び出しなどが削除されます）。逆の操作はありません。考え直している場合は、ソース管理下にあることを確認してください。 この投稿 特定のファイルに対して無効にする方法を示します。良いメモリ管理に費やされたこのすべての努力が無駄になり、天井にジャンプするのをやめなければならないのを見るのは痛いという事実を除けば、それに目を向けないことについてはあまり議論がないと思いますinit、new、copyが表示されるたびに、対応するリリース/自動リリースがありません（それに慣れるまでに時間がかかります）。おそらく、状況によっては、手動のメモリ管理によってパフォーマンス/メモリフットプリントが大幅に改善されると主張することもできます。そうであれば、私も興味があります。