viewDidAppear في iOS — ما هو ومتى يتم استدعاؤه وأمثلة

ما هو viewDidAppear

viewDidAppear هي طريقة من UIViewController يستدعيها UIKit بعد إضافة View إلى تسلسل النوافذ واكتمال رسم الانتقال المتحرك بالكامل. في هذه المرحلة، تكون الشاشة في حالتها النهائية: فهي مرئية ويمكن التفاعل معها، وتوقفت جميع رسوم UIKit المتحركة. يقوم المطور بتجاوز هذه الطريقة لتنفيذ إجراءات تتطلب أن تكون الشاشة أمام عيني المستخدم بشكل مضمون.

على عكس viewWillAppear، حيث تستعد الشاشة فقط للعرض، يشير viewDidAppear إلى أن المستخدم يرى بالفعل الواجهة. هذا فرق جوهري: بدء رسم متحرك في viewWillAppear قد يؤدي إلى فقدان الإطارات لأن UIKit لا يزال يعالج الانتقال. في viewDidAppear، اكتمل الانتقال ويمكن استخدام موارد وحدة التحكم لعرض محتوى جديد.

تقبل الطريقة معامل animated من نوع Bool، مشابهًا لـ viewWillAppear. إذا كان true، فإن ظهور الشاشة كان مصحوبًا برسم متحرك. يمكن استخدام هذا المعامل لتكييف سلوك الواجهة: على سبيل المثال، تخطي رسم متحرك للدخول أثناء عودة غير متحركة.

متى يتم استدعاء viewDidAppear

viewDidAppear تُستدعى في جميع السيناريوهات التي أكملت فيها الشاشة عملية ظهورها. دعنا نستعرض الحالات الرئيسية من منظور مطور iOS.

عند اكتمال انتقال التنقل

بعد أن ينهي UINavigationController رسمًا متحركًا للدفع أو الإزالة، تُستدعى viewDidAppear على وحدة التحكم الهدف. بالنسبة للشاشة الأولى في المكدس، يتم تشغيلها بعد الرسم المتحرك الافتتاحي الأولي. هذا هو السيناريو الرئيسي، وهو ما يستهدفه المطورون بشكل أساسي عند وضع المنطق في viewDidAppear.

بعد إغلاق نافذة مشروطة

عندما يغلق المستخدم وحدة تحكم معروضة بشكل مشروط ويعود إلى الوحدة السابقة، يستدعي UIKit viewDidAppear على وحدة التحكم العائدة. سيتوافق المعامل animated مع ما إذا كان الإغلاق قد تم برسم متحرك. هذه اللحظة مهمة لتحديث الواجهة بعد استلام البيانات من شاشة فرعية.

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. يمنع هذا تشغيل المؤقتات عندما لا تكون الشاشة مرئية، مما يوفر عمر البطارية وموارد المعالج.

بدء تشغيل المحتوى

المحتوى الوسائطي — فيديو، صوت، رسوم Lottie المتحركة — يُشغّل في viewDidAppear، وليس قبل ذلك. إذا بدأت التشغيل في viewWillAppear، سيفقد المستخدم الثواني الأولى بينما لا تزال الشاشة تظهر. في viewDidAppear، يمكنك تشغيل AVPlayer أو رسم Lottie متحرك بثقة أن المستخدم يرى المحتوى من الإطار الأول. هذا مهم بشكل خاص لشاشات التعريف وشاشات البداية حيث التوقيت الدقيق أمر بالغ الأهمية.

الرسوم المتحركة والأداء

التوقيت الصحيح لبدء الرسم المتحرك يؤثر بشكل مباشر على إدراك سلاسة الواجهة. قد يكون الفرق بين البدء في viewWillAppear و viewDidAppear غير ملحوظ للرسوم المتحركة البسيطة، لكنه يصبح حاسمًا للمشاهد المعقدة.

عندما ينفذ UIKit انتقال دفع بين الشاشات، يلتقط لقطات شاشة ويحركها ويستدعي في نفس الوقت viewWillAppear على وحدة التحكم الجديدة. إذا بدأت في هذه اللحظة رسمًا متحركًا ثقيلًا — تزيح، ضباب، تحويل — قد يفقد 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. بعض المطورين يرسلون أحداث التحليلات في viewWillAppear، لكن هذا يخلق إيجابيات كاذبة إذا لم تظهر الشاشة (على سبيل المثال، بسبب إيماءة pop ملغاة). viewDidAppear هو المؤشر الموثوق الوحيد على أن المستخدم رأى الشاشة بالفعل.

الخطأ الرابع هو نسيان super. استدعاء super.viewDidAppear ضروري للتشغيل الصحيح لـ UINavigationController و UITabBarController و UISplitViewController. بدونه، قد تتعطل آليات التنقل القياسية وتحديث الواجهة.

الخطأ الخامس هو تغيير الاتجاه أو حجم الشاشة دون النظر إلى viewDidLayoutSubviews. إذا كان رسمك المتحرك في viewDidAppear يعتمد على الأبعاد النهائية لـ View، تذكر أن viewDidLayoutSubviews قد تم استدعاؤه عدة مرات قبل viewDidAppear. عند أول ظهور للشاشة، يكتمل التخطيط قبل استدعاء viewDidAppear، ولكن عند تغييرات الحجم اللاحقة — على سبيل المثال، عند تدوير الجهاز — قد لا يتم استدعاء viewDidAppear ولن يبدأ رسمك المتحرك. في هذه الحالات، استخدم viewDidLayoutSubviews مع التحقق من علامة firstLayout.

يتطلب التنفيذ الصحيح الاحتفاظ بمرجع لكائن الرسم المتحرك وإلغاءه صراحة عند مغادرة الشاشة. الخطأ السادس هو بدء رسوم متحركة لا نهائية بدون علامة إيقاف. إذا بدأت رسمًا متحركًا متكررًا في viewDidAppear (مثل مؤشر نابض أو محمل دوار) لكنك لم توقفه في viewDidDisappear، فسيستهلك الرسم المتحرك موارد GPU حتى عندما تكون الشاشة مخفية. احتفظ دائمًا بمرجع للرسم المتحرك النشط واستدع removeAllAnimations أو setCompletion في طريقة دورة الحياة المقابلة.

الخطأ السابع هو تجاهل viewDidDisappear لإيقاف الأنشطة. إذا بدأت الاستماع إلى GPS أو مقياس التسارع أو الجيروسكوب في viewDidAppear، تأكد من إيقافه في viewDidDisappear. وإلا، ستستمر أجهزة الاستشعار في العمل في الخلفية، مستنزفة البطارية، حتى إذا كان المستخدم قد انتقل منذ فترة طويلة إلى شاشة أخرى. استخدم استدعاءات مقترنة للبدء والإيقاف في طرق دورة الحياة المقابلة — وهذا يضمن إدارة صحيحة لموارد الجهاز.