IBOutlets nên mạnh hay yếu theo ARC?

Tôi đang phát triển dành riêng cho iOS 5 bằng ARC. Có nên IBOutlets để UIViews (và các lớp con) có stronghay weak?

Sau đây là

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

Sẽ thoát khỏi tất cả những điều này:

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

Có bất kỳ vấn đề làm điều này? Các mẫu đang sử dụng strongnhư là các thuộc tính được tạo tự động được tạo khi kết nối trực tiếp với tiêu đề từ trình chỉnh sửa 'Trình tạo giao diện', nhưng tại sao? Các UIViewControllerđã có một strongtham chiếu đến nó viewmà vẫn giữ được subviews của nó.

Dòng khuyến cáo thực hành tốt nhất từ Apple là cho IBOutlets là mạnh trừ yếu là đặc biệt cần thiết để tránh một giữ lại chu kỳ. Như Johannes đã đề cập ở trên, điều này đã được nhận xét trong phiên "Triển khai thiết kế giao diện người dùng trong Trình tạo giao diện" từ WWDC 2015, nơi một Kỹ sư của Apple cho biết:

Và tùy chọn cuối cùng tôi muốn chỉ ra là loại lưu trữ, có thể mạnh hoặc yếu. Nói chung, bạn nên làm cho ổ cắm của mình mạnh mẽ, đặc biệt nếu bạn đang kết nối một ổ cắm với một khung nhìn phụ hoặc với một ràng buộc không phải lúc nào cũng được giữ lại bởi hệ thống phân cấp chế độ xem. Lần duy nhất bạn thực sự cần làm cho một ổ cắm yếu là nếu bạn có chế độ xem tùy chỉnh tham chiếu thứ gì đó sao lưu phân cấp chế độ xem và nói chung không được khuyến nghị.

Tôi đã hỏi về điều này trên Twitter với một kỹ sư trong nhóm IB và anh ấy xác nhận rằng mạnh mẽ phải là mặc định và các tài liệu dành cho nhà phát triển đang được cập nhật.

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

CẢNH BÁO, TRẢ LỜI NGOÀI TRỜI : câu trả lời này không cập nhật theo WWDC 2015, để có câu trả lời đúng, hãy tham khảo câu trả lời được chấp nhận (Daniel Hall) ở trên. Câu trả lời này sẽ ở lại để ghi lại.

Tóm tắt từ thư viện nhà phát triển :

Từ góc độ thực tế, trong các cửa hàng iOS và OS X nên được xác định là thuộc tính khai báo. Các cửa hàng nói chung nên yếu, ngoại trừ những người từ Chủ sở hữu tệp đến các đối tượng cấp cao nhất trong tệp nib (hoặc, trong iOS, cảnh phân cảnh) phải mạnh mẽ. Do đó, các cửa hàng mà bạn tạo sẽ thường yếu, bởi vì:

• Các cửa hàng mà bạn tạo, ví dụ, các khung nhìn của khung nhìn của trình điều khiển khung nhìn hoặc cửa sổ của trình điều khiển cửa sổ, là các tham chiếu tùy ý giữa các đối tượng không ngụ ý quyền sở hữu.

• Các ổ cắm mạnh thường được chỉ định bởi các lớp khung (ví dụ: ổ cắm khung nhìn của UIViewContoder hoặc ổ cắm cửa sổ của NSWindowControll).

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

Mặc dù tài liệu khuyến nghị sử dụng weaktrên các thuộc tính cho các cuộc phỏng vấn, vì iOS 6 có vẻ vẫn ổn để sử dụng strong(vòng loại quyền sở hữu mặc định) thay vào đó. Điều đó gây ra bởi sự thay đổi trong UIViewControllerquan điểm đó sẽ không được tải nữa.

• Trước iOS 6, nếu bạn giữ các liên kết mạnh đến các chế độ xem của chế độ xem xung quanh, nếu chế độ xem chính của bộ điều khiển chế độ xem không được tải, thì các chế độ xem đó sẽ giữ các chế độ xem miễn là xung quanh bộ điều khiển xem.
• Kể từ iOS 6, các lượt xem không được tải nữa, nhưng được tải một lần và sau đó bám xung quanh miễn là bộ điều khiển của chúng ở đó. Vì vậy, tài sản mạnh mẽ sẽ không quan trọng. Họ cũng sẽ không tạo chu kỳ tham chiếu mạnh, vì họ chỉ ra biểu đồ tham chiếu mạnh.

Điều đó nói rằng, tôi đang bị rách giữa việc sử dụng

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

và

@property (nonatomic) IBOutlet UIButton *button;

trong iOS 6 và sau:

• Sử dụng weakrõ ràng rằng bộ điều khiển không muốn sở hữu nút.

• Nhưng bỏ qua weakkhông làm tổn thương trong iOS 6 mà không xem tải xuống và ngắn hơn. Một số có thể chỉ ra rằng nó cũng nhanh hơn, nhưng tôi chưa gặp phải một ứng dụng quá chậm vì weak IBOutlets.

• Không sử dụng weakcó thể được coi là một lỗi.

Điểm mấu chốt: Vì iOS 6, chúng tôi không thể hiểu sai điều này nữa miễn là chúng tôi không sử dụng chế độ xem tải. Đến giờ tiệc tùng. ;)

Tôi không thấy bất kỳ vấn đề với điều đó. Pre-ARC, tôi đã luôn tạo ra IBOutlets của mình assign, vì chúng đã được các giám sát viên của họ giữ lại. Nếu bạn tạo chúng weak, bạn không cần phải loại bỏ chúng trong viewDidUnload, như bạn chỉ ra.

Một cảnh báo: Bạn có thể hỗ trợ iOS 4.x trong một dự án ARC, nhưng nếu có, bạn không thể sử dụng weak, vì vậy bạn phải tạo ra chúng assign, trong trường hợp đó bạn vẫn muốn bỏ qua tham chiếu viewDidUnloadđể tránh một con trỏ lơ lửng. Đây là một ví dụ về lỗi con trỏ lơ lửng tôi đã gặp phải:

Một UIViewControll có UITextField cho mã zip. Nó sử dụng CLLocationManager để đảo ngược mã địa lý vị trí của người dùng và đặt mã zip. Đây là cuộc gọi lại của đại biểu:

-(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];
}

Tôi thấy rằng nếu tôi loại bỏ chế độ xem này vào đúng thời điểm và không thực hiện self.zip viewDidUnload, thì cuộc gọi lại của đại biểu có thể ném ngoại lệ truy cập xấu vào self.zip.text.

IBOutletnên mạnh mẽ, vì lý do hiệu suất. Xem Tham khảo bảng phân cảnh, IBOutlet mạnh, Dock cảnh trong iOS 9

Như đã giải thích trong đoạn này, các lối ra cho các cuộc phỏng vấn của khung nhìn của trình điều khiển khung nhìn có thể yếu, bởi vì các cuộc phỏng vấn này đã được sở hữu bởi đối tượng cấp cao nhất của tệp nib. Tuy nhiên, khi một Outlet được định nghĩa là một con trỏ yếu và con trỏ được đặt, ARC gọi hàm thời gian chạy:

id objc_storeWeak(id *object, id value);

Điều này thêm con trỏ (đối tượng) vào một bảng bằng cách sử dụng giá trị đối tượng làm khóa. Bảng này được gọi là bảng yếu. ARC sử dụng bảng này để lưu trữ tất cả các con trỏ yếu của ứng dụng của bạn. Bây giờ, khi giá trị đối tượng được giải phóng, ARC sẽ lặp lại trên bảng yếu và đặt tham chiếu yếu thành nil. Ngoài ra, ARC có thể gọi:

void objc_destroyWeak(id * object)

Sau đó, đối tượng không được đăng ký và objc_destroyWeak gọi lại:

objc_storeWeak(id *object, nil)

Việc giữ sách này được liên kết với một tài liệu tham khảo yếu có thể mất 2 lần 3 lần so với việc phát hành một tài liệu tham khảo mạnh. Vì vậy, một tham chiếu yếu giới thiệu một chi phí chung cho thời gian chạy mà bạn có thể tránh bằng cách chỉ cần xác định các cửa hàng là mạnh.

Kể từ Xcode 7, nó gợi ý strong

Nếu bạn xem phiên WWDC 2015 407 Thực hiện Thiết kế giao diện người dùng trong Trình tạo giao diện , nó sẽ gợi ý (bản sao từ http://asciiwwdc.com/2015/simes/407 )

Và tùy chọn cuối cùng tôi muốn chỉ ra là loại lưu trữ, có thể mạnh hoặc yếu.

Nói chung, bạn nên làm cho ổ cắm của mình mạnh mẽ, đặc biệt nếu bạn đang kết nối một ổ cắm với chế độ xem phụ hoặc với một ràng buộc không phải lúc nào cũng được giữ lại bởi hệ thống phân cấp chế độ xem.

Lần duy nhất bạn thực sự cần làm cho một ổ cắm yếu là nếu bạn có chế độ xem tùy chỉnh tham chiếu thứ gì đó sao lưu phân cấp chế độ xem và nói chung không được khuyến nghị.

Vì vậy, tôi sẽ chọn mạnh mẽ và tôi sẽ nhấp vào kết nối sẽ tạo ra ổ cắm của tôi.

Trong phát triển iOS, tải NIB hơi khác một chút so với phát triển Mac.

Trong phát triển Mac, IBOutlet thường là một tham chiếu yếu: nếu bạn có một lớp con NSViewCont kiểm soát, chỉ có chế độ xem cấp cao nhất sẽ được giữ lại và khi bạn xử lý bộ điều khiển, tất cả các lần xem và đầu ra của nó sẽ được giải phóng tự động.

UiViewControll sử dụng Mã hóa giá trị khóa để đặt các cửa hàng sử dụng các tham chiếu mạnh. Vì vậy, khi bạn giải quyết UIViewControll của bạn, chế độ xem trên cùng sẽ tự động được giải phóng, nhưng bạn cũng phải giải phóng tất cả các đầu ra của nó trong phương thức dealloc.

Trong bài đăng này từ Big Nerd Ranch , họ đề cập đến chủ đề này và cũng giải thích tại sao sử dụng tài liệu tham khảo mạnh mẽ trong IBOutlet không phải là một lựa chọn tốt (ngay cả khi được Apple khuyến nghị trong trường hợp này).

Một điều tôi muốn chỉ ra ở đây, và đó là, mặc dù những gì các kỹ sư của Apple đã tuyên bố trong video WWDC 2015 của riêng họ ở đây:

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

Apple liên tục thay đổi suy nghĩ của họ về vấn đề này, điều này cho chúng ta biết rằng không có câu trả lời đúng duy nhất cho câu hỏi này. Để chỉ ra rằng ngay cả các kỹ sư của Apple cũng bị chia rẽ về chủ đề này, hãy xem mã mẫu gần đây nhất của Apple và bạn sẽ thấy một số người sử dụng yếu và một số thì không.

Ví dụ về Apple Pay này sử dụng yếu: https://developer.apple.com/l Library / ios / samplecode / Entporium / Listings / Entporium_ ProducttTableViewContoder_swift.html # / // numplef / doc / uid / TP40016175-Eppor_

Ví dụ như trong ảnh này cũng như ví dụ về hình ảnh trong tranh: https://developer.apple.com/l Library / ios / samplecode / ARFoundationPiPPlayer / Listpl / ORFoundationPiPPlayer / Listings / UFoundationPiPPlayer_PlayerViewContoder_swift.html / //apple_Vf / doc / uid

Ví dụ về Trình liệt kê cũng như: https://developer.apple.com/l Library / ios / samplecode / Lister / Listings / Lister_ListCell_swift.html# // apple_Vf / doc / uid / TP40014701-Lister_ListCell_swift-DontLink

Ví dụ về Vị trí cốt lõi cũng như: https://developer.apple.com/l Library / ios / samplecode / PostLoc / Listings / Potloc_PotlocViewContoder_swift.html # / // bit_Vf / doc / uid / TP40016176-Partloc_Pot

Ví dụ về trình xem trước của trình điều khiển chế độ xem cũng như ví dụ: https://developer.apple.com/l Library / ios / samplecode / viewCont kiểmPreview / Listings / Propls_PreviewUsingDelegate

Ví dụ về HomeKit cũng như: https://developer.apple.com/l Library / ios / samplecode / HomeKitCatalog / Listings

Tất cả những thứ này được cập nhật đầy đủ cho iOS 9 và tất cả đều sử dụng các ổ cắm yếu. Từ đó chúng ta biết rằng A. Vấn đề không đơn giản như một số người đưa ra. B. Apple đã thay đổi suy nghĩ của họ nhiều lần và C. Bạn có thể sử dụng bất cứ điều gì khiến bạn hạnh phúc :)

Đặc biệt cảm ơn Paul Hudson (tác giả của www.hackingwithsift.com), người đã cho tôi làm rõ và tham khảo cho câu trả lời này.

Tôi hy vọng điều này làm rõ chủ đề tốt hơn một chút!

Bảo trọng.

Từ WWDC 2015, có một phiên về Triển khai thiết kế giao diện người dùng trong Trình tạo giao diện . Khoảng 32 phút anh ấy nói rằng bạn luôn muốn làm cho mình @IBOutlet mạnh mẽ .

Hãy nhận thức, IBOutletCollectionnên được @property (strong, nonatomic).

Có vẻ như một cái gì đó đã thay đổi trong những năm qua và bây giờ Apple khuyên bạn nên sử dụng mạnh mẽ nói chung. Bằng chứng về phiên WWDC của họ là trong phiên 407 - Thực hiện Thiết kế giao diện người dùng trong Trình tạo giao diện và bắt đầu lúc 32:30. Ghi chú của tôi từ những gì anh ấy nói là (gần như, nếu không chính xác, trích dẫn anh ấy):

• Các kết nối đầu ra nói chung phải mạnh mẽ đặc biệt nếu chúng ta kết nối một khung nhìn phụ hoặc ràng buộc không phải luôn được giữ lại bởi hệ thống phân cấp chế độ xem

• kết nối ổ cắm yếu có thể cần thiết khi tạo chế độ xem tùy chỉnh có một số tham chiếu đến thứ gì đó được sao lưu trong hệ thống phân cấp chế độ xem và nói chung không nên sử dụng

Ở các phường khác, nó phải luôn luôn mạnh, miễn là một số chế độ xem tùy chỉnh của chúng tôi không tạo ra chu kỳ giữ lại với một số chế độ xem trong phân cấp chế độ xem

BIÊN TẬP :

Một số có thể đặt câu hỏi. Việc giữ nó với một tham chiếu mạnh không tạo ra chu trình giữ lại như trình điều khiển xem gốc và chế độ xem sở hữu giữ tham chiếu đến nó? Hay tại sao điều đó thay đổi xảy ra? Tôi nghĩ rằng câu trả lời là sớm hơn trong cuộc nói chuyện này khi họ mô tả cách các ngòi được tạo ra từ xib. Có một ngòi riêng được tạo cho một VC và cho chế độ xem. Tôi nghĩ rằng đây có thể là lý do tại sao họ thay đổi các khuyến nghị. Tuy nhiên, thật tuyệt khi nhận được lời giải thích sâu hơn từ Apple.

Tôi nghĩ rằng thông tin quan trọng nhất là: Các yếu tố trong xib sẽ tự động trong các lượt xem. Phỏng vấn là NSArray. NSArray sở hữu các yếu tố của nó. vv có con trỏ mạnh mẽ trên chúng. Vì vậy, trong hầu hết các trường hợp, bạn không muốn tạo một con trỏ mạnh khác (IBOutlet)

Và với ARC, bạn không cần phải làm gì trong viewDidUnload