iphone - ARCを使用することの長所と短所は何ですか？

Question

iOSプロジェクトで新しい自動参照カウント（ARC）メモリ管理スタイルを使用することの長所と短所は何ですか？

iOS 5.0 SDKで開発するときにARCを使用しないことを選択できますか？

新しいプロジェクトにARCまたは手動参照カウント（MRC）をお勧めしますか？

ARCを使用するアプリケーションはiOS5.0より古いバージョンのOSで実行できますか？

Answer 1

iOSプロジェクトで新しい自動参照カウント（ARC）メモリ管理スタイルを使用することの長所と短所は何ですか？

ARCプログラムの実行は、適切に記述されたMRCとほぼ同じです。つまり、操作の順序とパフォーマンスの両方が非常に近いため、動作の違いは検出できないことがよくあります。

手動参照カウント（MRC）を使用してOS XまたはiOSアプリを実装する方法をすでに知っている場合、ARCは実際には機能を追加しません。ソースから参照カウント操作を削除するだけです。

MRCを学びたくない場合は、最初にARCを試してみてください。多くの人がMRCの一般的な慣行に苦労したり、無視しようとしたりします（例：静的アナライザーに多数のobjc開発者を紹介しました）。これらの問題を回避したい場合は、ARCで理解を延期することができます。MRC、ARC、GCのいずれであっても、参照カウントとオブジェクトの存続期間および関係を理解せずに、重要なobjcプログラムを作成することはできません。ARCとGCは、ソースから実装を削除するだけで、ほとんどの場合、正しいことを行います。ARCとGCを使用する場合でも、いくつかのガイダンスを提供する必要があります。

私はこれを測定していませんが、 ARCソースのコンパイルにはより多くの時間とリソースがかかることを言及する価値があるかもしれません。

開発中のプログラムの参照カウントの使用量がかなり少ない場合（たとえば、自動リリースの一般的な量）、ARCに切り替えると、プログラムの実行時間とピークメモリ使用量が大幅に向上する可能性があります。

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をお勧めします。

Answer 2

オン/オフを切り替えると、CLANG_ENABLE_OBJC_ARC = NO 記述するコードが少なくなり、メモリ管理が容易になるという利点があります。欠点は、メモリ管理について学んだことをすべてスクラッチしなければならないことです:)私はそれをオフにすることを好みます。

Answer 3

Lion と xcode 4.3 を使用しています。私も同じ問題を抱えていました。

それを修正するために、「Build Settings->Objective-C Automatic Reference Co」を「いいえ」にしました。

「はい」に設定されていることを確認するには、「ビルド設定」ツールバーのすぐ下にあるツールバーの「すべて」および「レベル」オプションも有効にする必要がありました。

これらのオプションが有効になると、プロジェクトでそのオプションが「はい」に設定されていることがわかりました。デフォルト設定は「いいえ」であり、「レベル」オプションを有効にするまで表示されていたため、それを理解するのに少し時間がかかりました.

Answer 4

「Edit->Refactor->Convert to Objective C Arc」で ARC を有効にできます。これにより、コードが完全にリファクタリングされます (すべてのメモリ管理呼び出しなどが削除されます)。逆の操作はないので、再考する場合は、ソース管理下にあることを確認してください。この郵便受け特定のファイルに対して無効にする方法を示します。適切なメモリ管理に費やされたすべての努力が無駄になり、天井に飛びつくのをやめなければならないという事実を除けば、それに目を向けないという議論はあまりないと思います。対応する release/autorelease のない init、new、copy が表示されるたびに (これには慣れるまでに時間がかかります)。おそらく、状況によっては、手動のメモリ管理により、パフォーマンス/メモリフットプリントが非常に顕著に改善されると主張することもできます。そうであれば、私も興味があります。