viewDidAppear trong iOS — nó là gì, khi nào được gọi và ví dụ

viewDidAppear là gì

viewDidAppear là một phương thức của UIViewController mà UIKit gọi sau khi View được thêm vào hệ phân cấp cửa sổ và hoạt ảnh chuyển tiếp đã hoàn thành đầy đủ. Tại thời điểm này, màn hình ở trạng thái cuối cùng: nó hiện thị, có thể tương tác và tất cả hoạt ảnh UIKit đã dừng. Nhà phát triển ghi đè phương thức này để thực hiện các hành động yêu cầu màn hình phải được đảm bảo hiện ra trước mắt người dùng.

Không giống viewWillAppear, nơi màn hình chỉ chuẩn bị hiển thị, viewDidAppear báo hiệu rằng người dùng đã nhìn thấy giao diện. Đây là một sự khác biệt quan trọng: bắt đầu hoạt ảnh trong viewWillAppear có thể gây rụng khung hình vì UIKit vẫn đang xử lý chuyển tiếp. Trong viewDidAppear, quá trình chuyển tiếp đã hoàn tất và tài nguyên của bộ điều khiển có thể được sử dụng để kết xuất nội dung mới.

Phương thức chấp nhận tham số animated kiểu Bool, tương tự viewWillAppear. Nếu là true, việc xuất hiện màn hình đi kèm với hoạt ảnh. Tham số này có thể được sử dụng để điều chỉnh hành vi giao diện: ví dụ, bỏ qua hoạt ảnh vào khi quay lại không có hoạt ảnh.

Khi nào viewDidAppear được gọi

viewDidAppear được gọi trong mọi tình huống mà màn hình đã hoàn thành quá trình xuất hiện. Hãy xem xét các trường hợp chính từ góc nhìn của nhà phát triển iOS.

Khi quá trình chuyển hướng điều hướng hoàn tất

Sau khi UINavigationController kết thúc hoạt ảnh push hoặc pop, viewDidAppear được gọi trên bộ điều khiển đích. Đối với màn hình đầu tiên trong ngăn xếp, nó chạy sau hoạt ảnh mở đầu. Đây là kịch bản chính và là điều mà các nhà phát triển nhắm đến khi đặt logic trong viewDidAppear.

Sau khi đóng modal

Khi người dùng đóng bộ điều khiển được trình bày dưới dạng modal và quay lại màn hình trước, UIKit gọi viewDidAppear trên bộ điều khiển đang quay lại. Tham số animated sẽ tương ứng với việc dismiss có được thực hiện với hoạt ảnh hay không. Thời điểm này rất quan trọng để cập nhật giao diện sau khi nhận dữ liệu từ màn hình con.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    logScreenView()
    startOnboardingAnimation()
}

Khi chuyển tab TabBar

UITabBarController gọi viewDidAppear trên bộ điều khiển của tab được chọn sau khi hoạt ảnh chuyển đổi hoàn tất. Điều này khác với viewWillAppear, được kích hoạt khi bắt đầu chuyển đổi. Nếu một tab có hoạt ảnh chào mừng hoặc bạn cần theo dõi thời gian hoạt động, viewDidAppear là nơi thích hợp.

Khi quay lại từ nền

Khi ứng dụng quay lại từ nền về phía trước, bộ điều khiển hiển thị có thể có viewWillAppear và viewDidAppear được gọi nếu vòng đời của View tạm thời bị đình chỉ. Tuy nhiên, để theo dõi đáng tin cậy việc quay lại từ nền, hãy sử dụng UIApplication.willEnterForegroundNotification riêng rẽ.

Các tác vụ thực tế trong viewDidAppear

viewDidAppear xử lý các tác vụ yêu cầu màn hình hiển thị để thực hiện chính xác. Hãy xem xét các kịch bản sử dụng chính trong các dự án thực tế.

Gửi sự kiện phân tích

Nhiệm vụ phổ biến nhất của viewDidAppear là theo dõi lượt xem màn hình. Các hệ thống phân tích như Firebase Analytics, Amplitude hoặc Mixpanel chỉ nên nhận sự kiện sau khi màn hình thực sự được hiển thị cho người dùng. Gửi sự kiện trong viewWillAppear có thể làm giảm thời gian xem và tạo ra các kích hoạt giả.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    Analytics.logEvent(
        name: "screen_view",
        parameters: [
            "screen_name": "ProfileScreen",
            "screen_class": String(describing: self)
        ]
    )
}

Khởi chạy hoạt ảnh đầu vào

Các hoạt ảnh sẽ bắt đầu sau khi màn hình xuất hiện — sự xuất hiện theo tầng của các phần tử, hiệu ứng thị sai, hướng dẫn — được khởi chạy trong viewDidAppear. Tại thời điểm này, bối cảnh đồ họa đã sẵn sàng đầy đủ và hoạt ảnh sẽ mượt mà, không bị rụng khung hình khi bắt đầu. Điều này đặc biệt quan trọng đối với các hoạt ảnh sử dụng UIViewPropertyAnimator.

Bắt đầu tải bất đồng bộ

Các thao tác bất đồng bộ nặng — tải hình ảnh độ phân giải cao, phân tích JSON lớn, khởi tạo video — tốt hơn nên bắt đầu trong viewDidAppear thay vì viewDidLoad hoặc viewWillAppear. Khi phương thức được gọi, người dùng đã nhìn thấy giao diện, vì vậy bạn có thể hiển thị khung xương hoặc trình tải mà không làm chậm sự xuất hiện của màn hình.

Bắt đầu bộ đếm giờ và khoảng thời gian

Nếu màn hình có các phần tử yêu cầu cập nhật định kỳ — bộ đếm ngược, chỉ báo tiến trình, hoạt ảnh tiến trình — chúng được bắt đầu trong viewDidAppear và dừng lại trong viewDidDisappear. Điều này ngăn bộ đếm giờ chạy khi màn hình không hiển thị, tiết kiệm pin và tài nguyên CPU.

Bắt đầu phát nội dung

Nội dung đa phương tiện — video, âm thanh, hoạt ảnh Lottie — được bắt đầu trong viewDidAppear, không phải trước đó. Nếu bạn bắt đầu phát trong viewWillAppear, người dùng sẽ bỏ lỡ những giây đầu tiên khi màn hình vẫn đang xuất hiện. Trong viewDidAppear, bạn có thể khởi chạy AVPlayer hoặc hoạt ảnh Lottie với sự tự tin rằng người dùng đang xem nội dung ngay từ khung hình đầu tiên. Điều này đặc biệt quan trọng đối với màn hình hướng dẫn và màn hình khởi động nơi thời gian chính xác rất quan trọng.

Hoạt ảnh và hiệu suất

Thời điểm thích hợp để bắt đầu hoạt ảnh ảnh hưởng trực tiếp đến nhận thức về sự mượt mà của giao diện. Sự khác biệt giữa việc bắt đầu trong viewWillAppear và viewDidAppear có thể không đáng kể đối với các hoạt ảnh đơn giản, nhưng trở nên quan trọng đối với các cảnh phức tạp.

Khi UIKit thực hiện chuyển tiếp push giữa các màn hình, nó chụp ảnh màn hình, tạo hoạt ảnh cho chúng và đồng thời gọi viewWillAppear trên bộ điều khiển mới. Nếu bạn bắt đầu hoạt ảnh nặng tại thời điểm này — hiệu ứng thị sai, làm mờ, biến đổi — UIKit có thể làm rụng khung hình của hoạt ảnh chuyển tiếp, tạo ra hiệu ứng giật cục. viewDidAppear đảm bảo rằng hoạt ảnh chuyển tiếp đã hoàn tất, cho bạn toàn quyền kiểm soát việc kết xuất.

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)

    UIView.animate(
        withDuration: 0.6,
        delay: 0.3,
        usingSpringWithDamping: 0.8,
        initialSpringVelocity: 0.5
    ) {
        self.cardView.alpha = 1.0
        self.cardView.transform = .identity
    }
}

Sử dụng độ trễ và giảm chấn để tạo sự xuất hiện theo tầng tự nhiên của các phần tử. Cách tiếp cận này cải thiện nhận thức về giao diện và tăng thời gian ở lại — người dùng dành nhiều thời gian hơn để khám phá nội dung, điều này tác động tích cực đến các chỉ số hành vi.

Lỗi thường gặp trong viewDidAppear

Sử dụng không đúng viewDidAppear có thể dẫn đến các vấn đề về hiệu suất, hành vi hoạt ảnh không mong đợi và theo dõi quá mức. Hãy xem xét các lỗi phổ biến.

Lỗi đầu tiên là nhiều lần gọi. viewDidAppear có thể được gọi nhiều lần trong một số tình huống: chuyển tab, quay lại từ nền, chuyển tiếp modal. Nếu phương thức thực hiện một thao tác nặng mà không kiểm tra cờ, nó sẽ bị trùng lặp. Sử dụng cờ hasAppeared hoặc dispatchOnce cho các hành động một lần.

Lỗi thứ hai là bắt đầu yêu cầu mạng mà không hủy khi ẩn. Nếu người dùng rời màn hình trước khi yêu cầu hoàn tất, kết quả có thể được áp dụng cho một View đã bị ẩn. Sử dụng URLSessionTask có thể hủy và hủy chúng trong viewDidDisappear.

Lỗi thứ ba là theo dõi trong viewWillAppear thay vì viewDidAppear. Một số nhà phát triển gửi sự kiện phân tích trong viewWillAppear, nhưng điều này tạo ra các kích hoạt giả nếu màn hình không xuất hiện (ví dụ, do cử chỉ pop bị hủy). viewDidAppear là chỉ báo đáng tin cậy duy nhất rằng người dùng thực sự đã nhìn thấy màn hình.

Lỗi thứ tư là quên super. Việc gọi super.viewDidAppear là cần thiết để UINavigationController, UITabBarController và UISplitViewController hoạt động chính xác. Nếu không có nó, các cơ chế điều hướng và cập nhật giao diện tiêu chuẩn có thể bị hỏng.

Lỗi thứ năm là thay đổi hướng hoặc kích thước màn hình mà không xem xét viewDidLayoutSubviews. Nếu hoạt ảnh của bạn trong viewDidAppear phụ thuộc vào kích thước cuối cùng của View, hãy nhớ rằng viewDidLayoutSubviews có thể đã được gọi nhiều lần trước viewDidAppear. Ở lần xuất hiện màn hình đầu tiên, bố cục hoàn tất trước khi viewDidAppear được gọi, nhưng ở các lần thay đổi kích thước sau đó — ví dụ, khi xoay thiết bị — viewDidAppear có thể không được gọi và hoạt ảnh của bạn sẽ không bắt đầu. Trong những trường hợp này, hãy sử dụng viewDidLayoutSubviews với kiểm tra cờ firstLayout.

Việc triển khai đúng yêu cầu giữ tham chiếu đến đối tượng hoạt ảnh và hủy nó một cách rõ ràng khi rời màn hình. Lỗi thứ sáu là bắt đầu các hoạt ảnh vô hạn mà không có cờ dừng. Nếu bạn bắt đầu một hoạt ảnh lặp lại trong viewDidAppear (ví dụ, chỉ báo nhấp nháy hoặc trình tải quay) nhưng không dừng nó trong viewDidDisappear, hoạt ảnh sẽ tiêu tốn tài nguyên GPU ngay cả khi màn hình đã bị ẩn. Luôn giữ tham chiếu đến hoạt ảnh đang hoạt động và gọi removeAllAnimations hoặc setCompletion trong phương thức vòng đời tương ứng.

Lỗi thứ bảy là bỏ qua viewDidDisappear để dừng các hoạt động. Nếu bạn đã bắt đầu lắng nghe GPS, gia tốc kế hoặc con quay hồi chuyển trong viewDidAppear, hãy đảm bảo dừng nó trong viewDidDisappear. Nếu không, các cảm biến sẽ tiếp tục hoạt động ở nền, làm hao pin, ngay cả khi người dùng đã chuyển sang màn hình khác từ lâu. Sử dụng các lời gọi bắt đầu và dừng theo cặp trong các phương thức vòng đời tương ứng — điều này đảm bảo quản lý tài nguyên thiết bị chính xác.