viewDidAppear ใน iOS — คืออะไร เรียกเมื่อไหร่ และตัวอย่างการใช้งาน

viewDidAppear คืออะไร

viewDidAppear เป็นเมธอดของ UIViewController ที่ UIKit เรียกหลังจากที่ View ถูกเพิ่มเข้าไปในลำดับชั้นของหน้าต่างและแอนิเมชันการเปลี่ยนภาพเสร็จสมบูรณ์ ในขณะนี้หน้าจออยู่ในสถานะสุดท้าย: มองเห็นได้ สามารถโต้ตอบได้ แอนิเมชันทั้งหมดของ UIKit หยุดทำงาน นักพัฒนาจะเขียนเมธอดนี้ใหม่เพื่อดำเนินการที่ต้องการให้หน้าจออยู่ต่อหน้าผู้ใช้อย่างแน่นอน

แตกต่างจาก viewWillAppear ที่หน้าจอกำลังเตรียมพร้อมสำหรับการแสดงผล viewDidAppear ส่งสัญญาณว่า ผู้ใช้กำลังมองเห็น อินเทอร์เฟซแล้ว นี่คือความแตกต่างที่สำคัญ: การเริ่มแอนิเมชันใน viewWillAppear อาจทำให้เฟรมหายไป เนื่องจาก UIKit ยังคงประมวลผลการเปลี่ยนภาพ ใน viewDidAppear การเปลี่ยนภาพเสร็จสมบูรณ์แล้ว และทรัพยากรของคอนโทรลเลอร์สามารถใช้สำหรับการเรนเดอร์เนื้อหาใหม่ได้

เมธอดรับพารามิเตอร์ animated ประเภท Bool คล้ายกับ viewWillAppear ถ้าเป็น true — การปรากฏของหน้าจอมาพร้อมกับแอนิเมชัน พารามิเตอร์นี้สามารถใช้เพื่อปรับพฤติกรรมของ UI เช่น การข้ามแอนิเมชันขาเข้าเมื่อกลับมาแบบไม่มีแอนิเมชัน

เมื่อใดที่เรียก viewDidAppear

viewDidAppear ถูกเรียกในทุกสถานการณ์ที่หน้าจอเสร็จสิ้นกระบวนการปรากฏ มาดูกรณีหลักจากมุมมองของนักพัฒนา iOS

เมื่อการเปลี่ยนภาพนำทางเสร็จสิ้น

หลังจากที่ UINavigationController เสร็จสิ้นแอนิเมชัน push หรือ pop คอนโทรลเลอร์เป้าหมายจะเรียก viewDidAppear สำหรับหน้าจอแรกในสแต็ก เมธอดนี้จะทำงานหลังจากแอนิเมชันเริ่มต้นของการเปิด นี่คือ สถานการณ์หลัก และเป็นสิ่งที่นักพัฒนามุ่งเน้นเมื่อวางตรรกะใน viewDidAppear

หลังจาก dismiss หน้าต่าง模态

เมื่อผู้ใช้ปิดคอนโทรลเลอร์ที่แสดงแบบ模态และกลับไปยังคอนโทรลเลอร์ก่อนหน้า UIKit จะเรียก viewDidAppear บนคอนโทรลเลอร์ที่กำลังกลับมา โดยพารามิเตอร์ animated จะสอดคล้องกับว่าการ dismiss เกิดขึ้นพร้อมแอนิเมชันหรือไม่ จุดนี้สำคัญสำหรับการอัปเดต UI หลังจากได้รับข้อมูลจากหน้าจอย่อย

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

เมื่อสลับแท็บ TabBar

UITabBarController เรียก viewDidAppear บนคอนโทรลเลอร์ของแท็บที่เลือกหลังจากเสร็จสิ้นการสลับ ซึ่งแตกต่างจาก viewWillAppear ที่ทำงานเมื่อเริ่มการสลับ หากแท็บมีแอนิเมชันต้อนรับหรือต้องการติดตามเวลาที่ใช้งาน viewDidAppear คือตำแหน่งที่ถูกต้อง

เมื่อปรากฏจากพื้นหลัง

เมื่อแอปพลิเคชันกลับมาจากพื้นหลังสู่เบื้องหน้า คอนโทรลเลอร์ที่มองเห็นอยู่อาจถูกเรียก viewWillAppear และ viewDidAppear หากวงจรชีวิตของ View ถูกหยุดชั่วคราว อย่างไรก็ตาม สำหรับการติดตามการกลับมาจากพื้นหลังอย่างน่าเชื่อถือ ให้ใช้ UIApplication.willEnterForegroundNotification แยกต่างหาก

งานปฏิบัติใน viewDidAppear

viewDidAppear แก้ปัญหางานที่ต้องการให้หน้าจอมองเห็นเพื่อดำเนินการอย่างถูกต้อง มาดูสถานการณ์การใช้งานหลักในโปรเจกต์จริง

การส่งเหตุการณ์วิเคราะห์

งานที่พบบ่อยที่สุดของ viewDidAppear คือ การติดตาม การดูหน้าจอ ระบบวิเคราะห์เช่น Firebase Analytics, Amplitude หรือ Mixpanel ควรได้รับเหตุการณ์หลังจากที่หน้าจอแสดงให้ผู้ใช้เห็นจริงเท่านั้น การส่งเหตุการณ์ใน viewWillAppear อาจทำให้เวลาการดูต่ำเกินจริงและสร้างการแจ้งเตือนเท็จ

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

การเริ่มแอนิเมชันขาเข้า

แอนิเมชันที่ควรเริ่มหลังจากหน้าจอปรากฏ — การปรากฏขององค์ประกอบแบบหน่วงเวลา พารัลแลกซ์ บทช่วยสอน — จะเริ่มใน viewDidAppear ในขณะนี้ บริบทกราฟิก พร้อมอย่างสมบูรณ์ และแอนิเมชันจะราบรื่น ไม่มีการตกเฟรมเมื่อเริ่มต้น โดยเฉพาะอย่างยิ่งสำคัญสำหรับแอนิเมชันที่ใช้ UIViewPropertyAnimator

การเริ่มโหลดแบบอะซิงโครนัส

การดำเนินการแบบอะซิงโครนัสที่หนัก — การโหลดภาพความละเอียดสูง การแยกวิเคราะห์ JSON ขนาดใหญ่ การเริ่มต้นวิดีโอ — ควรเริ่มใน viewDidAppear มากกว่าใน viewDidLoad หรือ viewWillAppear เมื่อถึงเวลาที่เรียกเมธอด ผู้ใช้เห็นอินเทอร์เฟซแล้ว ดังนั้นจึงสามารถแสดงโครงกระดูกหรือตัวโหลดได้โดยไม่ชะลอ การปรากฏของหน้าจอ

การเริ่มจับเวลาและช่วงเวลา

หากบนหน้าจอมีองค์ประกอบที่ต้องการการอัปเดตเป็นระยะ — จับเวลานับถอยหลัง ตัวบ่งชี้การโหลด แอนิเมชันความคืบหน้า — จะเริ่มใน viewDidAppear และหยุดใน viewDidDisappear ซึ่งป้องกัน การทำงานของจับเวลา เมื่อหน้าจอไม่ปรากฏ ช่วยประหยัดแบตเตอรี่และทรัพยากร CPU

การเริ่มเล่นเนื้อหา

เนื้อหามัลติมีเดีย — วิดีโอ เสียง แอนิเมชัน Lottie — เริ่มใน viewDidAppear ไม่ใช่ก่อนหน้านั้น หากเริ่มเล่นใน viewWillAppear ผู้ใช้จะพลาดวินาทีแรกในขณะที่หน้าจอยังปรากฏ ใน viewDidAppear คุณสามารถเริ่ม AVPlayer หรือแอนิเมชัน Lottie ได้อย่างมั่นใจว่าผู้ใช้เห็นเนื้อหาตั้งแต่เฟรมแรก โดยเฉพาะอย่างยิ่งสำคัญสำหรับหน้าจอออนบอร์ดดิ้งและหน้าจอเริ่มต้นที่ต้องการเวลาที่แม่นยำ

แอนิเมชันและประสิทธิภาพ

ช่วงเวลาที่ถูกต้อง ในการเริ่มแอนิเมชันส่งผลโดยตรงต่อการรับรู้ความลื่นไหลของอินเทอร์เฟซ ความแตกต่างระหว่างการเริ่มใน viewWillAppear และ viewDidAppear อาจไม่สังเกตเห็นได้ในแอนิเมชันแบบง่าย แต่มีความสำคัญสำหรับฉากที่ซับซ้อน

เมื่อ UIKit ดำเนินการ push transition ระหว่างหน้าจอ มันจะสร้างภาพหน้าจอ ทำให้แอนิเมชันและเรียก viewWillAppear บนคอนโทรลเลอร์ใหม่พร้อมกัน หากในขณะนั้นเริ่ม แอนิเมชันที่หนัก — พารัลแลกซ์ blur การแปลง — UIKit อาจข้ามเฟรมของแอนิเมชันการเปลี่ยนภาพ ทำให้เกิดอาการกระตุก viewDidAppear รับประกันว่าแอนิเมชันการเปลี่ยนภาพเสร็จสมบูรณ์แล้ว และคุณสามารถควบคุมการเรนเดอร์ได้อย่างเต็มที่

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
    }
}

ใช้ การหน่วงเวลา และการหน่วงเพื่อสร้างการปรากฏขององค์ประกอบแบบเรียงลำดับตามธรรมชาติ วิธีนี้ช่วยปรับปรุงการรับรู้อินเทอร์เฟซและเพิ่มเวลาในการอยู่อาศัย — ผู้ใช้ศึกษาเนื้อหานานขึ้น ซึ่งส่งผลดีต่อเมตริกพฤติกรรม

ข้อผิดพลาดทั่วไปใน viewDidAppear

การใช้ที่ไม่ถูกต้อง ของ viewDidAppear อาจนำไปสู่ปัญหาด้านประสิทธิภาพ พฤติกรรมที่ไม่คาดคิดของแอนิเมชัน และการติดตามที่มากเกินไป มาดูข้อผิดพลาดที่พบบ่อย

ข้อผิดพลาดแรก — การเรียกซ้ำหลายครั้ง viewDidAppear อาจถูกเรียกหลายครั้งในสถานการณ์บางอย่าง: การสลับแท็บ การกลับมาจากพื้นหลัง การเปลี่ยนภาพแบบ模态 หากในเมธอดมีการดำเนินการที่หนักโดยไม่มีการตรวจสอบแฟล็ก มันจะถูกทำซ้ำ ใช้ แฟล็ก hasAppeared หรือ dispatchOnce สำหรับการดำเนินการครั้งเดียว

ข้อผิดพลาดที่สอง — การเริ่มคำขอเครือข่ายโดยไม่ยกเลิกเมื่อซ่อน หากผู้ใช้ออกจากหน้าจอก่อนที่คำขอจะเสร็จสมบูรณ์ ผลลัพธ์อาจถูกนำไปใช้กับ View ที่ซ่อนอยู่แล้ว ใช้ URLSessionTask ที่ยกเลิกได้ และยุติใน viewDidDisappear

ข้อผิดพลาดที่สาม — การติดตามใน viewWillAppear แทนที่จะเป็น viewDidAppear นักพัฒนาบางคนส่งเหตุการณ์ analytics ใน viewWillAppear แต่สิ่งนี้สร้างการแจ้งเตือนเท็จหากหน้าจอไม่ปรากฏ (เช่น เมื่อท่าทาง pop ถูกยกเลิก) viewDidAppear เป็นตัวบ่งชี้ที่เชื่อถือได้เท่านั้นว่าผู้ใช้เห็นหน้าจอจริง

ข้อผิดพลาดที่สี่ — ลืมเรียก super การเรียก super.viewDidAppear จำเป็นสำหรับการทำงานที่ถูกต้องของ UINavigationController, UITabBarController และ UISplitViewController หากไม่มี กลไกการนำทางและการอัปเดตอินเทอร์เฟซมาตรฐานอาจ เสียหาย

ข้อผิดพลาดที่ห้า — การเปลี่ยนทิศทางหรือขนาดหน้าจอโดยไม่คำนึงถึง viewDidLayoutSubviews หากแอนิเมชันของคุณใน viewDidAppear ขึ้นอยู่กับขนาดสุดท้ายของ View โปรดจำไว้ว่า viewDidLayoutSubviews อาจถูกเรียกหลายครั้งก่อน viewDidAppear เมื่อหน้าจอปรากฏครั้งแรก layout จะเสร็จสมบูรณ์ก่อนเรียก viewDidAppear แต่เมื่อมีการเปลี่ยนแปลงขนาดในภายหลัง — เช่น เมื่อหมุนอุปกรณ์ — viewDidAppear อาจไม่ถูกเรียก และแอนิเมชันของคุณจะไม่เริ่ม ในกรณีเช่นนี้ให้ใช้ viewDidLayoutSubviews พร้อมการตรวจสอบแฟล็ก firstLayout

การใช้งานที่ถูกต้องต้องเก็บการอ้างอิงไปยังออบเจกต์แอนิเมชันและยกเลิกอย่างชัดเจนเมื่อออกจากหน้าจอ ข้อผิดพลาดที่หก — การเริ่มแอนิเมชันที่ไม่มีที่สิ้นสุดโดยไม่มีแฟล็กหยุด หากใน viewDidAppear คุณเริ่มแอนิเมชันที่ทำซ้ำ (เช่น ตัวบ่งชี้การเต้นเป็นจังหวะหรือตัวโหลดหมุน) แต่ไม่หยุดใน viewDidDisappear แอนิเมชันจะใช้ทรัพยากร GPU ต่อไปแม้ว่าหน้าจอจะถูกซ่อน ควรเก็บการอ้างอิงไปยังแอนิเมชันที่ทำงานอยู่และเรียก removeAllAnimations หรือ setCompletion ในเมธอดที่เกี่ยวข้องของการสิ้นสุดวงจรชีวิต

ข้อผิดพลาดที่เจ็ด — การละเลย viewDidDisappear สำหรับการหยุดกิจกรรม หากคุณเริ่มการฟัง GPS, accelerometer หรือ gyroscope ใน viewDidAppear อย่าลืมหยุดใน viewDidDisappear มิฉะนั้นเซ็นเซอร์จะยังคงทำงานในพื้นหลัง ใช้แบตเตอรี่แม้ว่าผู้ใช้จะไปยังหน้าจออื่นแล้ว ใช้การเรียกคู่ start และ stop ในเมธอดวงจรชีวิตที่เกี่ยวข้อง — นี่รับประกันการจัดการทรัพยากรของอุปกรณ์อย่างถูกต้อง