私はいくつかのビデオ処理を行う iPhone アプリに取り組んでいます。ARC に準拠していないクラス ( dealloc 、release stuff ) に含める必要がありました。だから私は手動で行って、アークに準拠させました。後で、ARCプロジェクトで非ARCにすることができるクラスのコンパイラフラグを発見しました-fno-objc-arc。
私の質問は、これらのクラスにコンパイラ フラグを付けた場合、これの影響は何ですか? パフォーマンスヒット？それは良い考えですか？私のアプリ iOS 5.0 以降。これを行うことの長所と短所について話しているリソースは見つかりませんでした。
あなたが尋ねる：
これらのクラスにコンパイラフラグを付けた場合、これによる影響は何ですか？
心配する必要があると私が信じる唯一のことは、非ARCライブラリがメモリ管理に関連するCocoaの命名規則に従っていることを確認することです（たとえば、名前が、、、、またはで始まる場合は+1でオブジェクトを返すだけですretainCount）。そうしないと、ARCは結果のオブジェクトを適切に管理できません。よく書かれたクラスのほとんどはこのパターンに準拠しているため、フラグを使用しても完全に問題ないはずですが、問題のクラスに完全に依存します。allocnewcopymutableCopyfno-objc-arc
【あります】パフォーマンスヒット？
実用的なパフォーマンスの問題はありません。
[それは]いい考えですか？
すべてが同じであれば、私は通常、コードをARCに変換するのが好きです。私が変換を控えるかもしれないいくつかの状況：
これは活発に開発されているライブラリであり、私が自分の個人的なARCフォークを作成すると、ライブラリの将来の改訂に負けることになります。
ライブラリは非常に複雑であるか、ARCに簡単に変換できない構造を持っています。
結論として、ARCに変換できれば、変換します。通常、このプロセスでは、ライブラリに満足していること、リークがないことなどを確認するために必要なテストを行います。そのため、実行するのは生産的な（煩わしい場合）プロセスです。私たち全員がプロジェクトに含めるコードに責任があり、ARC変換とテストプロセスの自然な副産物であるデューデリジェンスを経ずにコードを統合するべきではないと思います。
ARCに変換する場合は、変換を元の作成者に戻すことを提案します（たとえば、GitHubの「プルリクエスト」または作成者が利用できるメカニズムを介して）。これにより、コードベースに統合できます。
一見すると、ARC を使用しても使用しなくてもパフォーマンスの問題はありません。ARC は基本的に通常の参照カウントreleaseです。呼び出しを挿入するのはプログラマーではなく、コンパイラーです。