私は現在ObjectiveCを学んでおり、これまでのところ、すべてのプロジェクトで自動参照カウントを使用しています。しかし、何人かの同僚と話をした後、そしていくつかのフォーラムをオンラインで見た後、私は自動参照カウントをオフにしてメモリを手動で管理する傾向に気づきました。
ARCが十分にうまくいくのか、それともたまにボールを落とすのか、私は疑問に思っていました。手動でメモリを割り当て/割り当て解除する方が効率的ですか？ARCをオフにする人もいますか？それは彼らが慣れているからですか？
ARCを引き続き使用する必要がありますか？そうでない場合は、将来、ARCが十分に使用できるようになるポイントを知っている人はいますか？
簡単な答え：ARCを使用してください。
長い答え：真剣に、ARCを使用してください。
ARCを使用しない理由はありません。できます。手動のメモリ管理よりも優れています。これを使って。それでも、メモリ管理とは何か、参照カウントがどのように機能するかを知っておく必要があります。ARCはその動作をまったく変更せず、Objective-Cを使用するときに標準となった規則に準拠するために必要な＆呼び出しをretain追加releaseするだけです。autorelease
ARCは、ほとんどの人間よりもはるかに優れたメモリ処理を行います。特定の場合にのみ、ARCの使用をオフにした方がよい場合がありますが、私たち開発者の多くがこれも必要になるとは思えません。
ARCが発表されたとき、私はそれを避けたくなりました。その理由は、私はJavaでの作業に多くの時間を費やし、自動メモリ管理によってプログラマーがオブジェクト関係の論理構造を忘れさせ、「スパゲッティコード」に相当するOOPを作成するように誘導できることを確認しました。
これまでのところ、私がARCで見たものは、その恐れをサポートしていません。weakと指定のためにstrong、人々はまだオブジェクトのライフサイクルを考慮する必要がありますが、入力は少なくなります。ここで、ARC環境でメモリ管理の問題を抱えている人々からの質問に答えるとき、それは非ARCでも問題となるコードが原因です。
今はマイナス面は見られません。
ほとんどの場合、メモリ管理を手動で処理するよりもARCを使用する方が効果的です。古いiOSバージョンとの互換性が必要ない場合は、ARCを使用してください。そうすれば、あなたよりもうまく機能します。ARCをサポートしていない古いフレームワークがある場合でも、このファイルに対してのみARCを非アクティブ化できます。
このブログは約1年前のものですが、良い方法で説明しています：http: //longweekendmobile.com/2011/09/07/objc-automatic-reference-counting-in-xcode-explained/
あなたの同僚は間違っているか、おそらく、次のシャッフルが発生したときに彼らの専門知識が管理時に失われる可能性があることを恐れて、ARCに変換することを望んでいません。
ARCと64ビットランタイムを使用すると、コードが真剣にクリーンアップされます。ARCプロジェクトで使用する回線は約30％少なくなっています。長期的には、プロジェクトの数週間ではなくても数日を節約できます。個人的には、どのARCプロジェクトでも自動リリースされたCALayerを追跡する必要はありません。
さらに、コンパイラーはライフタイム修飾子を使用してオブジェクトの存続期間に注釈を付けるため、通常、コンパイラーは通常よりも優れた機能を果たします。高度にネストされたコードでは、最後に考えたいのはリリースの最適化です。
ARCは、より優れたプログラマーになるためのガイドを提供しますが、そうでない場合は、以前よりも優れた道を進んでいます。たとえば、リリース/保持コードにより、人々は何年にもわたって合成されたセッターの悪用を回避することができました（つまり、より優れているという理由だけでプロパティを作成するself.property = property）[_property release], _property = [newProperty retain]。self.propertyを介したセッターへの明示的な呼び出しを見るのにうんざりしています。ARCは保持と解放をあなたから遠ざけるので、プロパティセッターを悪用するやむを得ない理由はありません。あなたのコードはより明白になり、臭いが少なくなり始めます。
お役に立てれば！