2012-06-20 30 views
9

Vì vậy, tôi đã có một dự án hỗ trợ iOS 4, vì vậy tất cả IBOutlets của tôi là __unsafe_unretained thậm chí IBOutlets nằm trong nib nhưng bên ngoài giao diện chính của trình điều khiển (Chế độ xem riêng trong cùng một ngòi) và tất cả đều hoạt động tốt.Sự khác biệt giữa yếu và không an toàn_unretained

Vì vậy, đã đến lúc và bây giờ là khách hàng muốn chỉ hỗ trợ iOS 5 nên nhóm chúng tôi đã thay đổi tất cả các __unsafe_unretained IBOutlets cho __weak IBOutlets nhưng bây giờ IBOutlets mà không phải là bên trong giao diện chính được thiết lập để nil (trừ viewdidload) để chúng tôi không thể thêm chúng sau này. Nếu tôi nghĩ về nó, nó có ý nghĩa bởi vì nếu không có quan điểm (xem chính) là giữ lại những IBOutlets họ nên được deallocated và zeroed (Tôi không biết nếu đó là từ chính xác), vì vậy giải pháp là để loại bỏ các __weak từ những IBOutlets

Nhưng những gì không có ý nghĩa đối với tôi là tại sao các hành vi khác nhau giữa unsafe_unretainedweak, trong đầu tôi những unsafe_unretained người nên được deallocated và khi ứng dụng cố gắng truy cập chúng, họ phải chỉ tham chiếu không hợp lệ và sau đó ứng dụng sẽ bị lỗi.

Tôi nghĩ rằng không an toàn__unretained là giống như yếu nhưng không có zeroing.

Tôi có thiếu gì đó ở đây không?

Cảm ơn.

+4

Bạn là chính xác. unsafe_unretained không có tham chiếu. – Francesco

Trả lời

5

Tôi nghĩ rằng không an toàn__không có gì giống như yếu nhưng không có số không.

Đó là, có.

Khi Cocoa tải ngòi bút, nó tạo tất cả các đối tượng được tự động phát hành, vì vậy chúng vẫn ở đó khi viewDidLoad được gọi. Tuy nhiên, hồ bơi autorelease có một vòng đời kết thúc khi điều khiển quay trở lại vòng lặp chạy. Tại thời điểm này tất cả các đối tượng không thuộc sở hữu của bất cứ điều gì sẽ biến mất vì vậy bất kỳ cửa hàng yếu sẽ được zeroed tại thời điểm đó.

Đối với hầu hết các cửa hàng, đây không phải là vấn đề bởi vì các đối tượng trong NIB đã thường được sở hữu bởi một cái gì đó. Vì vậy, ví dụ: một nút trong chế độ xem được sở hữu bởi chế độ xem gốc. Do đó, có các cửa hàng mạnh trỏ đến nút đó do đó quá mức hoặc tồi tệ hơn có thể dẫn đến chu trình giữ lại.

Đối tượng cấp cao nhất rõ ràng không có chế độ xem gốc để sở hữu chúng để chúng cần được sở hữu bởi một thứ khác, ví dụ: bộ điều khiển hoặc "Chủ sở hữu tệp". Nếu bạn đang tìm kiếm các công cụ biến mất, bạn cần tạo một IBOutlet mạnh cho nó trong chủ sở hữu của File.

Để biết thêm chi tiết, hãy xem Apple's docs.

+1

Điều đó tạo ra rất nhiều ý nghĩa, và tôi hoàn toàn nhận thức được điều đó, nhưng câu hỏi của tôi là tại sao khi tôi sử dụng unsafe_unretained những IBOutlets không bao giờ được deallocated và tôi có thể sử dụng chúng bất cứ khi nào (trong thời gian) tôi muốn? – Ecarrion

+0

@ Theo ý kiến ​​của tôi, nó là có cho đến khi thời gian mà bộ nhớ đoạn không ghi đè/ghi đè. Và khi ứng dụng bị ghi đè sẽ bị truy cập kém. – MANN

0

Bạn đúng, ứng dụng sẽ gặp sự cố khi cố gắng truy cập các đối tượng được phân bổ thông qua tài liệu tham khảo __unsafe_unretained cũ của bạn.

Lý do không có khả năng là do các đối tượng đang được tham chiếu bởi một số phần khác của ứng dụng của bạn có tham chiếu mạnh mẽ.

Hãy thử chạy với zombie được bật, điều đó sẽ gây ra sự cố ngay lập tức khi hủy kết nối các con trỏ cũ.

1

Đối với những người tìm kiếm trong tương lai gặp phải câu hỏi này, tôi nghĩ câu hỏi tương tự của CRD là Stackoverflow answer có thể giải thích.Mặc dù đối tượng đã được deallocated, bộ nhớ được tham chiếu bởi con trỏ không an toàn (không chứa dữ liệu đối tượng thực tế) không nhất thiết là zeroed, vì vậy mọi thứ có thể hoạt động đúng cho đến khi bộ nhớ đó thực sự được tái sử dụng/sửa đổi/zeroed.

Các vấn đề liên quan