ObjCブロックの循環参照の問題を解決する

ObjCのブロックと、Habrを含むそれらとの正しい作業について多くのことが書かれています。 循環参照を回避するために、ブロック内で自己を適切に処理する方法の質問は、インタビューで定期的に尋ねられます。 ReactiveCocoaなどのフレームワークを使用すると、コード内のブロック数が大幅に増加しますが、ミスをしてメモリ内のオブジェクトを失う可能性が高くなります。 最後にこの問題を解決する試みについて、拡張機能とブロックを使用したc99のメタプログラミング+カットの下に@を含むヒップスターマクロ。



問題とそれを進化的に解決する方法を検討してください。

self.block = ^{ [self f1]; [self f2]; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードには明らかに問題があります。 self.blockをゼロ化しないと、ブロックはselfを参照するため、オブジェクトを削除することはできません。 LANG_WARN_OBJC_IMPLICIT_RETAIN_SELFが有効になっている場合、コンパイラーは警告を発行します。

改善1：

 __weak __typeof(self)weakSelf = self; self.block = ^{ [weakSelf m1]; [weakSelf m2]; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

循環参照の問題は解決されましたが、別の問題が発生します。 ブロックが呼び出された時点で、weakSelfオブジェクトが存在するか、すでに存在していません。 オブジェクトが存在しなくなった場合、weakSelf == nil、m1、m2は呼び出されません。すべてが正常であるように見えます。 ただし、m1を呼び出した時点でオブジェクトはまだ存在しているのに、m2を呼び出した時点でオブジェクトが存在しなくなることがあります。 この場合、m1が呼び出されますが、m2は呼び出されません。この動作は予期しないものであり、正しくない場合があります。 これは、マルチスレッドアプリケーションの競合状態の場合、またはm1がオブジェクトへの参照の数を減らした場合（たとえば、コレクションからオブジェクトを削除した場合）に発生する可能性があります。 CLANG_WARN_OBJC_REPEATED_USE_OF_WEAKおよびCLANG_WARN_OBJC_RECEIVER_WEAKが有効になっている場合、コンパイラはこの場合に警告を生成します。

改善2：

 __weak typeof(self)weakSelf = self; self.block = ^{ __strong typeof(self)strongSelf = weakSelf; [strongSelf m1]; [strongSelf m2]; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ブロック内のメソッド呼び出しの一貫性に関する問題は解決されました。 しかし、新しいものが明らかになりました：

 __weak typeof(self)weakSelf = self; self.block = ^{ __strong typeof(self)strongSelf = weakSelf; [strongSelf m1]; [strongSelf m2]; NSAssert(foo == bar, @"Cool assert!") };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

NSAssertやRACObserveなどのマクロは暗黙的にselfを使用し、ループバックの問題が発生します。

改善3：

 __weak typeof(self)weakSelf = self; self.block = ^{ __strong typeof(self)self = weakSelf; [self m1]; [self m2]; NSAssert(foo == bar, @"Cool assert!") };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、selfを使用したマクロの問題は解決されましたが、GCC_WARN_SHADOWが有効になっている場合、コンパイラーは警告を生成します。

改善4：

libextobjcライブラリには、コンパイラの警告を削除し、コードを少し簡略化するマクロ@weakifyおよび@stongifyがあります。

 @weakify(self); // self      __weak self.block = ^{ @strongify(self); // self      __strong [self m1]; [self m2]; NSAssert(foo == bar, @"Cool assert!") };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはほぼ最適なソリューションですが、それでもいくつかの欠点がないわけではありません。@ weakifyと@strongifyを適切な場所に配置することを忘れないでください。 @weakifyの後にselfを使用しても安全ですが、コンパイラは警告を発行する場合があります。

同時に、強いリンクによって誤ってブロック内の自己をキャプチャする可能性がまだあります。

 @weakify(self); // self      __weak self.block = ^{ @strongify(self); // self      __strong [self m]; NSLog(@"Ivar value form object: %@", _ivar); //    self      _ivar NSAssert(foo == bar, @"Cool assert!") };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを回避するには、プロパティ（self.ivar）を介したアクセスのみを使用するか、オーバーライドされたselfを明示的に使用する必要があります。

 @weakify(self); // self      __weak self.block = ^{ @strongify(self); // self      __strong [self m]; NSLog(@"Ivar value form object: %@", self->_ivar); //     self    _ivar NSAssert(foo == bar, @"Cool assert!") };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

selfはnilである可能性があり、self-> _ ivarの明示的な間接参照はクラッシュを引き起こすことに注意してください。



これらすべての問題を考えると、アイデアは、自己ではなく、ブロック自体を次のように変更するマクロを書くことから生まれました。

• @weakifyの場合のように、ブロックのスコープ外のselfは変更すべきではありません
• NSAssertや他のマクロでの驚きを避けるために、selfブロック内はselfと呼ばれるべきです
• ブロックが呼び出されるまで、selfが指すオブジェクトは弱いリンクによって保存され、ブロックが呼び出されると、強い参照によって保存されます
• 可能であれば、マクロは、_ivarを介して暗黙的に自分をキャプチャするブロックを見つけるのに役立ちます。
• すべての型チェックは、マクロなしで動作するはずです
• このマクロを使用するときにコードの変更を最小限に抑える
• 実行時のオーバーヘッドは最小限に抑える必要があります

マクロはPythonのデコレータ関数のように動作し、入力としてブロックを受け入れ、パラメーターと戻り値で互換性のある新しいラッパーブロックにラップする必要があります。 たとえば、ブロックを考えます：

 self.block = ^(NSObject *obj) { NSLog(@"%@ %@", [self description], obj); return 0; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

改善1のコードと同様に、selfが弱いリンクとしてキャプチャされるようにブロックの修正を始めましょう。 これを行うには、このローカルリンクが宣言される新しいスコープが必要です。 作成直後に呼び出される匿名ブロックは、そのようなスコープとして適しています。

 self.block = ^{ __weak typeof(self) weakSelf = self; return ^(NSObject *obj) { NSLog(@"%@ %@", [weakSelf description], obj); return 0; }; }();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイラは、外部の名前のないブロックの戻り値の型を自動的に推測します;すべてが型安全です。



ここで、内部ブロックの本体内での呼び出し時に、selfが強いリンクになるように、何らかの方法でそれを作成する必要があります。 これを行うには、ブロックを2つの部分に分割する必要があります。^（NSObject * obj）型の宣言と、実際には{...}の本体自体です。 ブロックの本体をパラメーターなしのブロックに変換し、その呼び出しを型宣言を使用して作成された別のブロックに配置します。これにより、自己が強力なリンクになります。

 self.block = ^{ __weak typeof(self) weakSelf = self; return ^(NSObject *obj) { __strong typeof(self)self = weakSelf; return ^ (void) { NSLog(@"%@, %@", [self description], obj); return 0; }(); }; }();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

主なトリックは、元のブロックを同等のブロックに置き換えることですが、これは暗黙的にselfではなくweakSelfをキャプチャし、呼び出し時にstrongSelfに変換します。

 return ^(NSObject *obj) { __weak typeof(self)self = weakSelf; return ^ (void) { NSLog(@"%@, %@", [self description], obj); return 0; }(); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

本質的にと同じ

 ^(NSObject *obj) { NSLog(@"%@ %@", [self description], obj); return 0; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、1つのブロックではなく、3つのブロックが作成されます。 一番外側のブロックは作成後すぐに呼び出されるため、 コードブロック評価またはステートメント式拡張機能を使用して削除できます。

 self.block = ({ __weak typeof(self) weakSelf = self; ^(NSObject *obj) { __strong typeof(self)self = weakSelf; return ^ (void) { NSLog(@"%@, %@", [self description], obj); return 0; }(); }; });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このトリックが使いやすいように、ボイラープレート全体をマクロでラップすることが残っています。 一般的なコードのみを残すと、次のようになります。

  ({ __weak typeof(self) weakSelf = self; /*   */ { __strong typeof(self)self = weakSelf; return ^ (void) { /*   */ } (); }; })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初のアイデアは、次のように呼び出される、タイプとボディの2つのパラメーターを持つマクロを作成することでした。

 self.block = weakself(^(NSObject *obj), { NSLog(@"%@ %@", [self description], obj); return 0; });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、残念ながら、前処理中にマクロは1行に展開されるため、ブロックの本体の任意の行にブレークポイントを設定することはできません。 したがって、私はこれをしなければなりませんでした：

 self.block = weakself(^(NSObject *obj)) { NSLog(@"%@ %@", [self description], obj); return 0; } weakselfend ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このオプションは、改善4の@ weakify / @strongifyと同等です。 マクロコード：

 #define weakself(ARGS) \ ({ __weak typeof(self) _private_weakSelf = self; \ ARGS { \ __strong typeof(_private_weakSelf) self __attribute__((unused)) = _private_weakSelf; \ return ^ (void) { #define weakselfend } (); }; })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マクロを作成するときの目標の1つは、ivarにアクセスするときに自己の暗黙的なキャプチャから身を守ることでした。 残念ながら、コンパイル時にこれを行う方法は思いつきませんでした。 唯一のオプションは、ブロックを作成するときにバージョンをデバッグするassert / logです（チェックを機能させるためにブロックを作成するだけで、呼び出す必要はありません）。 ここで、キャプチャしたブロックとオブジェクトに対するメモリ管理の仕組みを思い出してください。 ブロックには3つのタイプがあります。

• NSGlobalBlock-ソースコードファイルのトップレベルで作成されたブロックは、メモリ管理の観点からは基本的に関数と同じです。スコープ内の変数はこのためにエキサイティングではなく、興味がありません。
• NSStackBlockは、作成された他のすべてのブロックの初期型です。これらはスタック上に作成されます。キャプチャするオブジェクトの参照カウントは増加しません。そのようなブロックの有効期間は、レキシカルスコープの変数の有効期間以下です。
• NSMallocBlockは、copy / Block_copyの明示的な呼び出しによって、またはコンパイラーによって暗黙的にヒープに移植されたNSStackBlockです。 コンパイラーが暗黙的にBlock_copyを挿入するケースの1つは、関数/ブロックの結果としてのブロックの戻りです。 NSStackBlockをNSMallocBlockに変換する時点で、ブロックがスコープ内でキャプチャしたオブジェクトの参照カウントが増加します。

したがって、ブロックがselfへの強力なリンクをキャプチャしているかどうかを確認するには、ブロックがヒープに転送される前と後に、参照カウンターをselfと比較する必要があります。 カウンターが増加した場合、ブロックは強力なリンクによって自己をキャプチャしています。 selfへの参照のカウンターはヒープへのブロック転送中に他のスレッドから変更される可能性があるため、このチェックは100％のケースでは信頼できませんが、通常のプログラムではこの状況は起こりそうになく、デバッグアセンブリに非常に適しています。



先にretainCountメソッドを使用してオブジェクトから参照カウントを取得することもできますが、ARCでは使用できなくなりましたが、CFGetRetainCountは引き続きフリーブリッジで機能します。 正しい場所にselfパラメータを指定してこの関数の呼び出しを挿入し、結果を比較するだけです。

 self.block = {( __weak typeof(self) weakSelf = self; //      self    ^(NSObject *obj) { __strong typeof(self)self = weakSelf; return ^ (void) { NSLog(@"%@, %@", [self description], obj); return 0; }(); }; }) //     .         statement expression
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

問題は、ステートメント式の結果がその最後の行であることです。 この動作は、宣言の直後に呼び出される匿名ブロックに似ています。 ステートメント式の最後の行はブロックの宣言であるため、このブロックが有効なままであるために、コンパイラはそれをヒープに転送します。 ステートメント式内のローカル変数にselfのCFGetRetainCountの呼び出しを保存できることがわかり、ステートメント式の最後の行の後にCFGetRetainCountの2回目の呼び出しを行う必要があります。 C ++の場合、スタック上にオブジェクトを作成できます。オブジェクトデストラクタでは、必要なすべての処理を実行できます。デストラクタはステートメント式の最後の行の後に呼び出されるためです。 幸い、clangはgcc-extensionをサポートしています。これにより、変数がスコープを離れた瞬間に呼び出されるスタック上の変数に対してクリーンアップ関数（デストラクタのアナログ）を設定できます。 libextobjcの@onExitマクロは、この拡張機能を通して機能します。



参照カウンターの検証を実装するには、追加の構造が必要です。

 struct RefCountCheckerData { CFTypeRef weakSelf; NSUInteger refCountBefore; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、クリーンアップとして請求される機能。

 static inline void vbr_CheckRefCountForWeakSelf(struct RefCountCheckerData *data) { const NSInteger refCountAfter = CFGetRetainCount(data->weakSelf); const NSInteger countOfSelfRefInBlock = refCountAfter - data->refCountBefore; if (countOfSelfRefInBlock > 0) { raise(SIGPIPE); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スタック上に構造を作成し、クリーンアップ関数を設定し、weakSelfへのポインターとその参照の数を初期化します。 Cleanup関数は、変数_private_refCountCheckerDataがスコープから出たときに呼び出され、この時点でブロックは既にヒープ内にあります。

 self.block = {( __weak typeof(self) weakSelf = self; __attribute__((cleanup(vbr_CheckRefCountForWeakSelf), unused)) struct RefCountCheckerData _private_refCountCheckerData = { .weakSelf = (__bridge CFTypeRef)self, .refCountBefore = CFGetRetainCount((__bridge CFTypeRef)self), }; ^(NSObject *obj) { __strong typeof(self)self = weakSelf; return ^ (void) { NSLog(@"%@, %@", [self description], obj); return 0; }(); }; });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このバージョンのマクロでは、self.block = ^ {NSLog（@ "％d"、_ivarInteger）;などのように、selfを介さずにivarにアクセスしようとすると、デバッガのブレークポイントが機能します。 };



マクロの最終バージョンを提示する前に、最新のヒップな外観にする必要があります。 ObjCは、言語キーワードのように、@で始まるマクロを作成するのが流行しています。たとえば、@ strongify、@ onExitです。 ただし、プリプロセッサでは、マクロ名の一部として@を使用できません。 extobjcは、マクロautoreleasepool {}またはtry {} catch （...）{}の先頭で挿入を使用します。このため、@記号はtryまたはautoreleasepoolのいずれかに固定されます。 マクロが展開された後、不必要な空のautoreleasepoolまたはtry catchがコードに表示されますが、誰もそれを気にしません。 ただし、weakselfの結果は式であり、式には最初に@autoreleasepool try {} catch （...）{}を含めることができないため、このアプローチはweakselfマクロでは機能しません。

 self.block = @weakself(^(NSObject *obj)) { NSLog(@"%@ %@", [self description], obj); return 0; } @weakselfend ;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Cの複雑な式に関しては、三項演算子が最初に思い浮かびます。 それを適用する方法を理解することは残っています。 このようなことを書くために私が最初に思いついたのは：self.block = @ 1？ / *ここにブロックコード* /：nil;



これを行うには、1を追加しますか？ 最初に弱者であり、nil; weakselfendの終わりに。 しかし、self.block = 1？ / *ここにブロックコード* /：nil; まったく正しい表現なので、@ weakselfとweakselfが機能します。



オプションself.block = @ []？ / *ここにブロックコード* /：nil; @なしで@weakselfを使用することはできませんが、逆アセンブラをチェックした後、オプティマイザが空の配列の作成をスローしないことが判明しました。これは実行時の余分なオーバーヘッドです。



最後に、ObjCで文字列リテラル連結機能を使用するというアイデアが生まれました。

 const char *s0 = "ABC" "DEF"; //   C- "ABCDEF" NSString *s1 = @"ABC" @"DEF"; //   ObjC- @"ABCDEF" NSString *s2 = @"ABC" "DEF"; //    ObjC- @"ABCDEF" NSString *s3 = "ABC" @"DEF"; //    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、マクロの最終バージョン：

 #define weakself(ARGS) \ "weakself should be called as @weakself" @"" ? \ ({ __weak typeof(self) _private_weakSelf = self; \ ARGS { \ __strong typeof(_private_weakSelf) self __attribute__((unused)) = _private_weakSelf; \ return ^ (void) { #define weakselfnotnil(ARGS) \ "weakself should be called as @weakself" @"" ? \ ({ __weak typeof(self) _private_weakSelf = self; \ ARGS { \ __strong typeof(_private_weakSelf) self __attribute__((unused)) = _private_weakSelf; \ return ^ (void) { if (self) #define weakselfend \ try {} @finally {} } (); }; \ }) : nil
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

@weakselfnotnilは、ブロックが呼び出されるまでにselfがすでに削除されている場合、ブロックが呼び出されないという点で異なります。 ブロックに戻り値がない場合にのみ適しています。そうでない場合、自己が既に削除されている場合に何を返すかが明確ではありません。 明示的な自己逆参照を通じて主にivarを安全に使用するために作成されました。

 self.block = @weakselfnotnil(^) { NSLog(@"%d", self->_ivar); } @weakselfend;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

性能

ここでは、パフォーマンスについてあまり心配する必要はおそらくないでしょう。オーバーヘッドはそれほど多くないはずです。 マクロの先頭に@を追加するトリックは、オプティマイザーによって完全にスローされます。 追加のユニットを呼び出すオーバーヘッドにより、事態はより興味深いものになります。 オーバーヘッドの状況を確認するには、libextobjcのマクロとweakselfを使用した2つのケースを検討します。

 - (void)m1 { @weakify(self); self.block = ^(NSObject * obj) { @strongify(self); NSLog(@"%@", [self description]); return 0; }; } - (void)m2 { self.block = @weakself(^(NSObject * obj)) { NSLog(@"%@", [self description]); return 0; } @weakselfend; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

weakselfは@ weakify / strongifyよりも効果的であり、内部の追加ブロックは完全にインラインであり、_block_invokeはどちらの場合も同じように見えます。 しかし、_Unwind_SjLj_Unregisterに見られるように、extobjcがマクロの先頭で@を「食べる」方法は、無駄なランタイム例外処理コードを追加します。



残念ながら、clangではalways_inline属性をブロックに追加することはまだ許可されていません。

Xcodeの完全なソースコードとオートコンプリートはこちらです。