Sự khác biệt giữa viewDidLoad và viewDidAppear


Câu trả lời:


147

viewDidLoadđược gọi chính xác một lần, khi bộ điều khiển khung nhìn được tải lần đầu tiên vào bộ nhớ. Đây là nơi bạn muốn khởi tạo bất kỳ biến phiên bản nào và xây dựng bất kỳ chế độ xem nào tồn tại trong toàn bộ vòng đời của bộ điều khiển chế độ xem này. Tuy nhiên, tầm nhìn thường chưa được nhìn thấy vào thời điểm này.

viewDidAppearđược gọi khi dạng xem thực sự hiển thị và có thể được gọi nhiều lần trong vòng đời của Bộ điều khiển dạng xem (ví dụ: khi Bộ điều khiển dạng xem phương thức bị loại bỏ và dạng xem lại hiển thị). Đây là nơi bạn muốn thực hiện bất kỳ hành động bố cục nào hoặc thực hiện bất kỳ bản vẽ nào trong giao diện người dùng - ví dụ: trình bày bộ điều khiển chế độ xem phương thức. Tuy nhiên, bất cứ điều gì bạn làm ở đây đều có thể lặp lại. Tốt nhất không nên giữ lại mọi thứ ở đây, nếu không bạn sẽ bị rò rỉ bộ nhớ nếu bạn không giải phóng chúng khi chế độ xem biến mất.

Xem: https://developer.apple.com/documentation/uikit/uiviewcontroller


15
Bạn và WrightsCS hoàn toàn đúng. Nhưng, không phải để tách tóc, mà trong khi viewDidLoadnói chung chỉ được gọi một lần và chỉ một lần, có một tình huống có thể được gọi lại. Cụ thể, nếu bạn từng nhận được một didReceiveMemoryWarning, các chế độ xem không hiển thị của bạn có thể được giải phóng (mặc dù các bộ điều khiển chế độ xem không bị ảnh hưởng) và khi bạn quay lại, viewDidLoadcó thể được gọi lại cho chúng.
Rob

1
Tôi không chắc liệu mình có đồng ý với nhận xét về ivars view controller luôn và tự động được phát hành cho bạn hay không (bản thân controller không được phát hành). Tôi nghi ngờ rằng cả hai chúng tôi đều có thể dễ dàng tạo một viewDidLoad sẽ bị rò rỉ nếu nó được gọi lại sau một didReceiveMemoryWarning. Nhưng tôi đồng ý rằng nếu bạn áp dụng các thông lệ tốt khi viết bài của mình viewDidLoad, bạn sẽ ổn. Điểm duy nhất của tôi là việc sử dụng ivars một cách cẩu thả và quản lý bộ nhớ thủ công chắc chắn có thể dẫn đến rò rỉ viewDidLoad. Mọi người nên nhạy cảm với didReceiveMemoryWarningkịch bản và chương trình phù hợp.
Rob

2
Không phải để tin vào quan điểm, nhưng chưa đầy 24 giờ sau cuộc trao đổi này, trong khi trả lời một câu hỏi khác , tôi đã tìm thấy một ví dụ về chính xác loại viewDidLoadmã sẽ bị rò rỉ didReceiveMemoryWarning. Thở dài.
Rob

1
Câu trả lời này mâu thuẫn trực tiếp với câu trả lời kia: stackoverflow.com/a/3411636/269753 Tôi đã quan sát thấy phương thức viewDidLoad của mình được gọi nhiều lần, ngay cả khi hoàn toàn không nhận được cảnh báo bộ nhớ. Có ai muốn làm rõ không?
Ricardo Sanchez-Saez

2
Tôi không thấy rằng có một sự mâu thuẫn. Câu hỏi đó là về mối quan hệ giữa viewDidLoad và viewDidUnload, không phải viewDidAppear.
davidgoli

21

Nói một cách đơn giản, bạn sẽ muốn tạo bất kỳ điều khiển hoặc mảng nào trong viewDidLoadđó, cũng như tại viewDidAppearnơi bạn muốn làm mới các điều khiển hoặc mảng đó.

viewDidLoadđược gọi một lần khi bộ điều khiển được tạo và viewDidAppearđược gọi mỗi khi chế độ xem, tốt, DID xuất hiện. Vì vậy, giả sử bạn có một chế độ xem phương thức mà bạn trình bày, khi chế độ xem đó bị loại bỏ, viewDidAppearsẽ được gọi, và viewDidLoadsẽ không được gọi.


3
Đoạn đầu tiên là một mẹo hay. Nhưng đoạn thứ hai không chính xác. viewDidLoadcó thể được gọi nhiều hơn một lần . Nếu chế độ xem của bạn trong khi không được hiển thị (trong một chồng các chế độ xem khác) được dỡ bỏ bởi các phiên bản iOS cũ hơn trong tình trạng bộ nhớ thấp, thì bộ điều khiển chế độ xem sẽ tự động tải lại chế độ xem khi cần hiển thị lại trên màn hình. Trong các phiên bản iOS mới hơn, bạn có thể chọn giúp giảm mức sử dụng bộ nhớ bằng cách thực hiện những gì iOS trước đó đã làm cho bạn: Tải chế độ xem ngoài màn hình khi có didReceiveMemoryWarningthông báo, trong trường hợp đó, chế độ viewDidLoadnày sẽ được gọi lại.
Basil Bourque vào

@WrightsCS bạn có tài liệu apple chính thức nào nói vậy không? "viewDidLoad được gọi một lần khi bộ điều khiển được tạo" Bởi vì tôi nhớ trong quá khứ viewDidLoad có thể được gọi nhiều lần trong các tình huống bộ nhớ thấp. Cảm ơn rất nhiều.
Ricardo

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.