自動参照カウント：パート1

こんにちは同僚。



iOS向けの外国の開発者のブログや記事を長い間読んでいます。 先日、 マイク・アッシュという開発者からの自動参照カウントに関する好奇心、盛でかなり詳細な記事に出会いました。

この記事は非常に大きいため、私が作成した翻訳をいくつかの部分に分割するリスクがあります。 私は2つの部分で維持したいと考えています。





Appleがこの革新を発表して以来、読者は自動参照カウント（ARC）メカニズムについて書くことを私に勧めてきました。 時が来ました。 本日は、Appleの新しいメモリ管理システムについて説明します。それがどのように機能するのか、それを自分で機能させる方法です。



コンセプト



Clang Static Analyzerは、コード内のメモリ管理エラーを見つけるのに非常に便利なツールです。 あなたと私が似ている場合、アナライザーの出力を見て、「アナライザーがエラーを検出した場合、なぜ私ではなく修正すべきではないか」と考えます。



要するに-これはARCの本質です。 メモリ管理ルールはコンパイラに組み込まれています。 しかし、開発者がエラーを見つけるのを助けるためにそれらを使用する代わりに、ARCメカニズムは単に必要な呼び出しを挿入します。 そしてそれだけです。



ARCメカニズムは、ガベージコレクターと手動メモリ管理の間のどこかにあります。 ガベージコレクターと同様に、ARCは開発者がretain / release / autorelease呼び出しを記述する必要をなくします 。 ただし、ガベージコレクタとは異なり、ARCはループを保持するためにいかなる方法でも反応しません。 相互に強いリンクを持つ2つのオブジェクトは、誰も参照していない場合でも、ARCによって処理されることはありません。 ARCはほとんどのメモリ管理タスクからプログラマを解放しますが、開発者はオブジェクトへの厳密な循環参照を回避または手動で破棄する必要があります。



実装の詳細に関しては、ARCとAppleのGC実装の​​もう1つの重要な違いは、ARCは改善されていないということです。 AppleのGCを使用する場合、アプリケーション全体がGC環境で実行されるかどうかのいずれかです。 つまり、使用するAppleフレームワークやサードパーティライブラリを含む、アプリケーション内のすべてのObjective-Cコードは、使用するためにGCと互換性がある必要があります。 ARCが同じアプリケーション内で手動のメモリ管理とともに「非ARC」コードと平和的に共存することは注目に値します。 これにより、GCが導入されたときに遭遇した大きな互換性と信頼性の問題なしに、プロジェクトを部分的に変換できます。



Xcode



ARCは、Xcode 4.2ベータ版から、Clang（別名「Apple LLVMコンパイラ」）を使用したコンパイルを選択した場合にのみ利用できます。 使用するには、「Objective-C Automatic Reference Counting」というわかりやすい名前の設定に注意するだけで十分です。

既に既存のコードベースで作業している場合、この設定を変更すると、膨大な数のエラーが発生する可能性があります。 ARCは、あなたの場所のメモリを管理するだけでなく、自分でメモリを管理することも禁止しています。 ARCを使用すると、 retain / release / autoreleaseメッセージをオブジェクトに送信することはまったく受け入れられません。 Cocoaはそのようなメッセージでいっぱいであるという事実に基づいて、必然的に大量のエラーが発生します。

幸いなことに、Xcodeは既存のコードを変換するツールを提供します。 これを行うには、[ 編集]-> [リファクタリング...]-> [Objective-C ARCに変換...]を選択します。Xcodeを使用すると、コードを段階的に変換できます。 何をすべきかを指定する必要がある非常にボトルネックを除くと、このプロセスはほとんど自動的に行われます。



基本機能



Cocoaのメモリ管理ルールは非常に簡単です。 要するに：

1. alloc、new、copy 、 retainをオブジェクトに送信する場合、 releaseまたはautoreleaseを使用してこれを補正する必要があります。

2.条項1で説明した方法とは異なる方法でオブジェクトを受け取り、オブジェクトを十分に長い時間「生きた」状態にする必要がある場合は、 retainまたはcopyを使用する必要があります 。 当然、これは後で補償する必要があります。



それら（ルール）は、プロセスの自動化に大きく貢献します。 あなたが書く場合：

Foo *foo = [[Foo alloc] init]; [foo something]; return;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイラーは、不均衡なallocを検出し、以下に変換します。

  Foo *foo = [[Foo alloc] init]; [foo something]; [foo release]; return;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、コンパイラはリリースメッセージをオブジェクトに送信するためのコードを挿入しません。 代わりに、特別なランタイム関数への呼び出しを挿入します。

  Foo *foo = [[Foo alloc] init]; [foo something]; objc_release(foo); return;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、いくつかの最適化を適用できます。 - リリースが再定義されていない場合、ほとんどの場合、 objc_releaseはObjective-Cメッセージメカニズムをバイパスでき、速度がわずかに向上します。



このような自動化は、コードをより安全にするのに役立ちます。 多くのCocoa開発者は、「非常に長い間」という用語を条項2から解釈しています。これは、インスタンス変数または同様の場所に格納されているオブジェクトを意味します。 通常、ローカルの一時オブジェクトに保持と解放を適用しません。

  Foo *foo = [self foo]; [foo bar]; [foo baz]; [foo quux];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、次の構成は非常に危険です。

  Foo *foo = [self foo]; [foo bar]; [foo baz]; [self setFoo: newFoo]; [foo quux]; // crash
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、値が返されるまでretain / autoreleaseが送信される-fooのゲッターを持つことで修正できます。 これは有効なオプションですが、メモリを積極的に使用する多くの一時オブジェクトを生成できます。 ただし、ARCはここに余分な呼び出しを偏執的に挿入します。

  Foo *foo = objc_retainAutoreleasedReturnValue([self foo]); [foo bar]; [foo baz]; [self setFoo: newFoo]; [foo quux]; // fine objc_release(foo);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、単純なゲッターを作成した場合でも、ARCはそれを可能な限り安全にします。

  - (Foo *)foo { return objc_retainAutoreleaseReturnValue(_foo); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、これは一時オブジェクトの過剰な数の問題を完全には解決しません！ 前と同じように、ゲッターではretain / autoreleaseの組み合わせを使用し、呼び出しコードではretain / releaseの組み合わせを使用します。 これは間違いなく無効です！



しかし、測定せずに心配しないでください。 前述のように、ARC（最適化のため）は、メッセージを送信するだけでなく、特別な呼び出しを使用します。 retainとreleaseを加速することに加えて、これらの呼び出しは一般的にいくつかの操作を排除します。



objc_retainAutoreleaseReturnValueの実行中、スタックを監視し、呼び出し元の戻りアドレスを記憶します。 これにより、彼は完了後に何が起こるかを正確に知ることができます。 コンパイルの最適化をオンにして、 objc_retainAutoreleaseReturnValueを呼び出すことが、 末尾呼び出しの最適化の理由になる場合があります。



Rantimeは、この返信アドレスのクレイジーなチェックを使用して、不必要な作業を回避します。 これにより、 自動解放の送信が不要になり、保持メッセージを破棄するように呼び出し元に通知するフラグが設定されます。 全体の構造は、ゲッターで単一のリテインを使用し、呼び出しコードで単一のリリースを使用します。これは、より安全で効率的なアプローチです。



注：この最適化は、ARCメカニズムを使用しないコードと完全に互換性があります。

ゲッターがARCを使用しないイベントでは、上記のフラグは設定されず、呼び出し側は保持/解放メッセージの完全な組み合わせを使用できます。

ゲッターがARCを使用するが、呼び出し元は使用しないイベントでは、ゲッターは特別なランタイム関数をすぐに呼び出すコードに戻らないことを認識しているため、 保持/自動解放メッセージの完全な組み合わせを使用できます。

一部のパフォーマンスは失われますが、コードは完全に正しいままです。



さらに、ARCエンジンは、すべてのクラスの-deallocメソッドを自動的に作成または入力して、すべてのインスタンス変数を解放します。 同時に、 -deallocを手動で記述する可能性はまだありますが（これは外部リソースを管理するクラスに必要です）、将来的にはクラスインスタンス変数を手動で解放する必要はありません。 ARCは最後に[super dealloc]呼び出しも挿入するので、心配する必要がありません。



言われたことを説明します。

以前は、次の構成を使用できました。

  - (void)dealloc { [ivar1 release]; [ivar2 release]; free(buffer); [super dealloc]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、あなたは書くだけです：

  - (void)dealloc { free(buffer); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-deallocメソッドがインスタンス変数を解放しただけの場合、この構成（ARCを使用）は同じことを行います。



ループと弱いリンク



ARCでは、開発者が循環リンクを手動で処理する必要があります。この問題を解決する最善の方法は、弱いリンクを使用することです。



ARCはヌルの弱いリンクを使用します。 このようなリンクは、参照先のオブジェクトを「ライブ」に保つだけでなく、参照先のオブジェクトが破棄されると自動的にnilになります。 弱いリンクをゼロにすることで、デッドポインターの問題、関連するクラッシュ、およびアプリケーションの予期しない動作がなくなります。

ヌル可能な弱いリンクを作成するには、宣言時に__weakプレフィックスを追加するだけです。

たとえば、このタイプのインスタンス変数の作成は次のとおりです。

  @interface Foo : NSObject { __weak Bar *_weakBar; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ローカル変数は同じ方法で作成されます：

  __weak Foo *_weakFoo = [object foo];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

後で通常の変数として使用できますが、必要に応じて値は自動的にnilになります。

  [_weakBar doSomethingIfStillAlive];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、 __ weak変数はほとんどすべての時点でnilになる可能性があることに注意してください 。

メモリ管理は基本的にマルチスレッドプロセスであり、疎結合オブジェクトは1つのスレッドで破棄され、別のスレッドがそのオブジェクトにアクセスできます。

説明します。

次のコードは正しくありません：

  if(_weakBar) [self mustNotBeNil: _weakBar];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

代わりに、ローカルの強力なリンクを使用して、次を確認します。

  Bar *bar = _weakBar; if(bar) [self mustNotBeNil: bar];
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、 バーは強い参照であるため、オブジェクトが使用されている間ずっとオブジェクト（および非nil変数）が有効になります。



ARCでの弱いリンクの無効化の実装には、Objective-Cの参照アカウンティングシステムと弱いリンクの無効化システムの間の緊密な調整が必要です。 つまり、 retainおよびreleaseをオーバーライドするクラスは、null許容弱参照のオブジェクトにはなれません。 異常ではありますが、一部のCocoaクラスはこれに苦しんでいます（ NSWindowなど ）。



幸いなことに、同様の間違いを犯した場合、プログラムは、次のように、クラッシュしたときにメッセージを発行することにより、すぐにそれを知らせます。

  objc[2478]: cannot form weak reference to instance (0x10360f000) of class NSWindow
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様のクラスへの弱い参照が本当に必要な場合は、 __ weakの代わりに__unsafe_unretainedを使用できます。 これにより、リセットされない弱いリンクが作成されます。 ただし、ポインターが指しているオブジェクトが破棄された後は、このポインターを使用していないことを確認する必要があります（手動でリセットすることをお勧めします）。

注意してください：null不可の弱いリンクを使用すると、火で遊ぶことができます。



ARCを使用してMac OS X 10.6およびiOS 4のアプリケーションを作成する可能性にもかかわらず、これらのOSではヌル可能なウィークリンクは使用できません（翻訳者のメモ：ARC解析のコンテキストでこの文章の意味を完全に誤解しました。非ゼロの弱参照でなければなりません）。

すべての弱いリンクは__unsafe_unretainedで処理する必要があります。



ヌル可能の弱いリンクは非常に危険であるため、この制限により、これらのシステムでARCを使用する魅力が大幅に低下します。

---

テキストがかなり大きくなったので、ここで翻訳の最初の部分を終了します。 私はそれを可能な限りロシア語に翻訳しようとしましたが、読まれた資料の99％が英語である場合は特に簡単ではありません。

彼らが言うように、お楽しみに。