IBOutletsはARCの下で強いべきか弱いべきか？

ARCを使用してiOS 5専用に開発しています。万一IBOutlet秒UIView秒（およびサブクラス）は可能strongかweak？

以下：

@property (nonatomic, weak) IBOutlet UIButton *button;

これをすべて取り除くでしょう：

- (void)viewDidUnload
{
    // ...
    self.button = nil;
    // ...
}

これを行うには問題がありますか？テンプレートはstrong、 'Interface Builder'エディターからヘッダーに直接接続するときに作成される自動生成プロパティと同じように使用していますが、なぜですか？はUIViewControllerすでにそのサブビューを保持strongするへの参照を持ってviewいます。

Appleが現在推奨しているベストプラクティスは、保持サイクルを回避するために特に弱いものが必要でない限り、IBOutletを強くすることです。ヨハネスが前述したように、これはWWDC 2015の「Interface BuilderでのUI設計の実装」セッションでAppleエンジニアが述べたようにコメントされました：

そして、私が指摘したい最後のオプションは、ストレージのタイプです。これは、強くても弱くてもかまいません。一般的に、コンセントをサブビューまたはビュー階層によって常に保持されるとは限らない制約に接続する場合は特に、コンセントを強くする必要があります。本当にアウトレットを弱くする必要があるのは、ビュー階層のバックアップを参照するカスタムビューがある場合だけで、一般的には推奨されません。

TwitterでIBチームのエンジニアにこれについて尋ねたところ、彼はstrongがデフォルトであり、開発者ドキュメントが更新されていることを確認しました。

https://twitter.com/_danielhall/status/620716996326350848 https://twitter.com/_danielhall/status/620717252216623104

警告、古い回答：この回答はWWDC 2015に従って最新ではありません。正しい回答については、上記の承認された回答（Daniel Hall）を参照してください。この回答は記録に残ります。

開発者ライブラリから要約：

実用的な観点から、iOSおよびOS Xでは、アウトレットを宣言されたプロパティとして定義する必要があります。アウトレットは一般に弱いはずです。ただし、ファイルのオーナーからnibファイル（またはiOSではストーリーボードシーン）の最上位のオブジェクトまで、アウトレットは強いはずです。したがって、作成するアウトレットは通常、デフォルトでは弱くなります。

• たとえば、ビューコントローラーのビューやウィンドウコントローラーのウィンドウのサブビューに作成するアウトレットは、所有権を意味しないオブジェクト間の任意の参照です。

• 強力なアウトレットは、フレームワーククラス（UIViewControllerのビューアウトレット、NSWindowControllerのウィンドウアウトレットなど）によって頻繁に指定されます。

  @property (weak) IBOutlet MyView *viewContainerSubview;
  @property (strong) IBOutlet MyOtherClass *topLevelObject;

ドキュメントでweakはサブビューのonプロパティを使用することを推奨していますが、iOS 6以降では、strong代わりに（デフォルトの所有権修飾子）を使用するのが良いようです。これはUIViewController、ビューがアンロードされなくなったことの変更が原因です。

• iOS 6より前のバージョンでは、コントローラーのビューのサブビューへの強力なリンクを保持している場合、ビューコントローラーのメインビューがアンロードされると、ビューコントローラーがある限り、それらはサブビューに保持されます。
• iOS 6以降、ビューはアンロードされなくなりましたが、一度ロードされた後、コントローラーが存在する限り保持されます。そのため、強力なプロパティは重要ではありません。また、強参照グラフを下向きにするため、強参照サイクルを作成しません。

とは言っても、私は使用の間に引き裂かれています

@property (nonatomic, weak) IBOutlet UIButton *button;

そして

@property (nonatomic) IBOutlet UIButton *button;

iOS 6以降：

• を使用するweakと、コントローラーがボタンの所有権を必要としないことが明確に示されます。

• ただしweak、iOS 6ではビューのアンロードなしで省略しても害はなく、短くなります。これも速いと指摘する人もいますが、weak IBOutletsのせいで遅いアプリにはまだ出会っていません。

• 使用しweakないことはエラーとして認識される場合があります。

結論：iOS 6以降、ビューのアンロードを使用しない限り、これで問題が発生することはありません。パーティーの時間。;）

何の問題もありません。ARC以前assignでは、スーパービューによって既に保持されているため、常にIBOutletsを作成してきました。それらを作成する場合weak、指摘するように、viewDidUnloadでそれらをnilする必要はありません。

1つの注意点：ARCプロジェクトでiOS 4.xをサポートできますが、サポートする場合は使用できませんweak。そのため、それらを作成する必要assignがあります。この場合、参照を無効にしviewDidUnloadて、ぶら下がりポインタ。これが私が経験したぶら下がりポインタのバグの例です：

UIViewControllerには、郵便番号用のUITextFieldがあります。CLLocationManagerを使用して、ユーザーの位置を逆ジオコーディングし、郵便番号を設定します。デリゲートコールバックは次のとおりです。

-(void)locationManager:(CLLocationManager *)manager
   didUpdateToLocation:(CLLocation *)newLocation
          fromLocation:(CLLocation *)oldLocation {
    Class geocoderClass = NSClassFromString(@"CLGeocoder");
    if (geocoderClass && IsEmpty(self.zip.text)) {
        id geocoder = [[geocoderClass alloc] init];
        [geocoder reverseGeocodeLocation:newLocation completionHandler:^(NSArray *placemarks, NSError *error) {
            if (self.zip && IsEmpty(self.zip.text)) {
                self.zip.text = [[placemarks objectAtIndex:0] postalCode];
            }
        }];    
    }
    [self.locationManager stopUpdatingLocation];
}

このビューを適切なタイミングで閉じ、viewDidUnloadでself.zipをnilにしないと、デリゲートコールバックがself.zip.textに不正なアクセス例外をスローする可能性があることがわかりました。

IBOutletパフォーマンス上の理由から、強いはずです。ストーリーボードリファレンス、Strong IBOutlet、iOS 9のScene Dockを参照してください

この段落で説明したように、ビューコントローラーのビューのサブビューへのアウトレットは弱い可能性があります。これらのサブビューは、nibファイルの最上位オブジェクトによってすでに所有されているためです。ただし、アウトレットがウィークポインターとして定義され、ポインターが設定されている場合、ARCはランタイム関数を呼び出します。

id objc_storeWeak(id *object, id value);

これは、オブジェクト値をキーとして使用して、ポインター（オブジェクト）をテーブルに追加します。このテーブルは、ウィークテーブルと呼ばれます。ARCはこのテーブルを使用して、アプリケーションのすべてのウィークポインターを格納します。オブジェクト値が割り当て解除されると、ARCはウィークテーブルを反復処理し、ウィークリファレンスをnilに設定します。または、ARCは以下を呼び出すことができます。

void objc_destroyWeak(id * object)

次に、オブジェクトが登録解除され、objc_destroyWeakが再度呼び出します。

objc_storeWeak(id *object, nil)

弱い参照に関連するこの簿記は、強い参照のリリースに比べて2〜3倍長くかかることがあります。したがって、弱い参照は、アウトレットを強いと定義するだけで回避できるランタイムのオーバーヘッドをもたらします。

Xcode 7の時点で、 strong

WWDC 2015セッション407 Interface BuilderでのUIデザインの実装を見ると、それが示唆されています（http://asciiwwdc.com/2015/sessions/407からのトランスクリプト）

そして、私が指摘したい最後のオプションは、ストレージのタイプです。これは、強くても弱くてもかまいません。

一般に、特にコンセントをサブビューまたはビュー階層によって常に保持されるわけではない制約に接続する場合は、コンセントを強くする必要があります。

本当にアウトレットを弱くする必要があるのは、ビュー階層のバックアップを参照するカスタムビューがある場合だけで、一般的には推奨されません。

だから私は強いを選択するつもりであり、私は私の接続を生成する接続をクリックします。

iOS開発では、NIBロードはMac開発とは少し異なります。

Mac開発では通常、IBOutletは弱い参照です。NSViewControllerのサブクラスがある場合、最上位のビューのみが保持され、コントローラーの割り当てを解除すると、そのすべてのサブビューとアウトレットが自動的に解放されます。

UiViewControllerはキー値コーディングを使用して、強い参照を使用してアウトレットを設定します。したがって、UIViewControllerの割り当てを解除すると、トップビューは自動的に割り当て解除されますが、deallocメソッドですべてのアウトレットの割り当ても解除する必要があります。

Big Nerd Ranchのこの投稿では、このトピックについて説明し、IBOutletで強参照を使用するのが適切でない理由を説明しています（この場合、Appleが推奨している場合でも）。

ここで私が指摘したいことの1つは、アップルのエンジニアが自分たちのWWDC 2015のビデオでここに述べたにもかかわらず、

https://developer.apple.com/videos/play/wwdc2015/407/

アップルはこの問題について彼らの考えを変え続けています、それはこの質問に対する単一の正しい答えはないことを私たちに伝えます。Appleのエンジニアでさえこの問題について意見が分かれていることを示すために、Appleの最新のサンプルコードを見てください。弱い人が使用している人と使用していない人がいます。

このApple Payの例では、weakを使用してい ます。

このピクチャーインピクチャーの例と同様に、https： //developer.apple.com/library/ios/samplecode/AVFoundationPiPPlayer/Listings/AVFoundationPiPPlayer_PlayerViewController_swift.html#//apple_ref/doc/uid/TP40016166-AVFoundationPiPPlayer_PlayerViewController_swift-DontLinkElementID4

リスターの例と同様に：https : //developer.apple.com/library/ios/samplecode/Lister/Listings/Lister_ListCell_swift.html#//apple_ref/doc/uid/TP40014701-Lister_ListCell_swift-DontLinkElementID_57

コアロケーションの例と同様に：https : //developer.apple.com/library/ios/samplecode/PotLoc/Listings/Potloc_PotlocViewController_swift.html#//apple_ref/doc/uid/TP40016176-Potloc_PotlocViewController_swift-DontLinkElementID_6

ビューコントローラーのプレビューの例と同じように：https : //developer.apple.com/library/ios/samplecode/ViewControllerPreviews/Listings/Projects_PreviewUsingDelegate_PreviewUsingDelegate_DetailViewController_swift.html#//apple_ref/doc/uid/TP40016546-Projects_PreviewUsingDelegate_PreviewUsing_elewiElementElement5Link

HomeKitの例と同様：https ://developer.apple.com/library/ios/samplecode/HomeKitCatalog/Listings/HMCatalog_Homes_Action_Sets_ActionSetViewController_swift.html#//apple_ref/doc/uid/TP40015048-HMCatalog_Homes_Action_Sets_ActionSetViewControllerLinksElement23LinkElementElements

これらはすべてiOS 9用に完全に更新されており、すべて弱いコンセントを使用しています。このことから、Aが問題であることがわかります。この問題は、一部の人が考えているほど単純ではありません。B.アップルは繰り返し考えを変えました、そしてC.あなたは幸せになるものなら何でも使うことができます:)

説明とこの回答の参照を提供してくれたPaul Hudson（www.hackingwithsift.comの作成者）に特に感謝します。

これにより、主題が少し明確になることを願っています！

気を付けて。

WWDC 2015以降、Interface BuilderでのUIデザインの実装に関するセッションがあります。32分前後に彼はあなたが常にあなたの@IBOutlet 力を作りたいと言っていると言います。

注意してIBOutletCollectionください@property (strong, nonatomic)。

長年の間に何かが変わったように見えますが、今ではAppleは一般的にstrongを使用することを推奨しています。WWDCセッションに関する証拠は、セッション407-Interface BuilderでのUIデザインの実装にあり、32：30に始まります。彼の言ったことからの私のメモは（正確ではないにしても、ほとんど彼を引用している）：

• アウトレット接続は、特にビュー階層によって常に保持されているわけではないサブビューまたは制約を接続する場合は特に、強いはずです。

• ビュー階層のバックアップに何らかの参照があるカスタムビューを作成する場合、弱いアウトレット接続が必要になる場合があり、一般的には推奨されません

他のワードでは、カスタムビューの一部がビュー階層の一部のビューで保持サイクルを作成しない限り、常に強いはずです。

編集：

一部は質問をするかもしれません。強力な参照でそれを維持しても、ルートビューコントローラーと所有ビューが参照を保持するため、保持サイクルは作成されませんか？それともなぜ変化が起こったのですか？答えは、nibがxibからどのように作成されるかについて説明するときに、この講演の前半にあると思います。VCとビュー用に作成された個別のペン先があります。これが彼らが推奨事項を変更する理由かもしれないと思います。それでも、Appleからより深い説明を得るのは素晴らしいことです。

最も重要な情報は次のとおりです。xibの要素は自動的にビューのサブビューにあります。サブビューはNSArrayです。NSArrayはその要素を所有しています。などに強いポインタがあります。したがって、ほとんどの場合、別の強力なポインタ（IBOutlet）を作成する必要はありません。

ARCでは、何もする必要はありません。 viewDidUnload