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 مکان مناسبی است.

هنگام ظاهر شدن از پس‌زمینه

وقتی برنامه از background به foreground بازمی‌گردد، ممکن است viewWillAppear و viewDidAppear در کنترلر قابل مشاهده فراخوانی شوند، اگر چرخه حیات View موقتاً متوقف شده باشد. با این حال برای ردیابی مطمئن بازگشت از پس‌زمینه به طور جداگانه از UIApplication.willEnterForegroundNotification استفاده کنید.

وظایف عملی در viewDidAppear

viewDidAppear وظایفی را حل می‌کند که برای اجرای صحیح به صفحه قابل مشاهده نیاز دارند. سناریوهای کلیدی استفاده در پروژه‌های واقعی را بررسی می‌کنیم.

ارسال رویدادهای analytics

رایج‌ترین وظیفه 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. در لحظه فراخوانی متد، کاربر از قبل رابط را می‌بیند، بنابراین می‌توان skeleton یا loader را نشان داد، بدون اینکه ظاهر صفحه به تأخیر بیفتد.

راه‌اندازی تایمرها و بازه‌ها

اگر در صفحه عناصری وجود دارند که نیاز به به‌روزرسانی دوره‌ای دارند — تایمر شمارش معکوس، نشانگر بارگذاری، انیمیشن پیشرفت — آنها در viewDidAppear راه‌اندازی و در viewDidDisappear متوقف می‌شوند. این کار از فعالیت تایمرها در زمانی که صفحه قابل مشاهده نیست جلوگیری می‌کند و باعث صرفه‌جویی در باتری و منابع CPU می‌شود.

شروع پخش محتوا

محتوای چندرسانه‌ای — ویدیو، صدا، انیمیشن‌های Lottie — دقیقاً در viewDidAppear راه‌اندازی می‌شوند، نه زودتر. اگر پخش در viewWillAppear شروع شود، کاربر ثانیه‌های اول را در حالی که صفحه هنوز در حال نمایش است از دست می‌دهد. در viewDidAppear می‌توانید AVPlayer یا انیمیشن Lottie را با اطمینان از اینکه کاربر محتوا را از فریم اول می‌بیند راه‌اندازی کنید. این به ویژه برای صفحات راهنما و اسپلش‌اسکرین‌ها مهم است، جایی که زمان‌بندی دقیق اهمیت دارد.

انیمیشن‌ها و عملکرد

لحظه مناسب شروع انیمیشن مستقیماً بر درک روانی رابط تأثیر می‌گذارد. تفاوت بین شروع در viewWillAppear و viewDidAppear ممکن است در انیمیشن‌های ساده نامحسوس باشد، اما برای صحنه‌های پیچیده حیاتی است.

وقتی UIKit یک انتقال push بین صفحات انجام می‌دهد، اسکرین‌شات می‌گیرد، آنها را انیمیشن می‌کند و همزمان 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
    }
}

برای ایجاد ظاهر آبشاری طبیعی عناصر از تأخیرها و میرایی استفاده کنید. این رویکرد درک رابط را بهبود می‌بخشد و dwell time را افزایش می‌دهد — کاربر محتوا را طولانی‌تر مطالعه می‌کند، که بر معیارهای رفتاری تأثیر مثبت دارد.

خطاهای رایج در 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 یک انیمیشن تکراری راه‌اندازی می‌کنید (مثلاً نشانگر ضربان‌دار یا loader چرخان)، اما آن را در viewDidDisappear متوقف نمی‌کنید، انیمیشن منابع GPU را حتی زمانی که صفحه مخفی است مصرف می‌کند. همیشه ارجاع به انیمیشن فعال را نگه دارید و در متد مربوطه پایان چرخه حیات removeAllAnimations یا setCompletion را فراخوانی کنید.

خطای هفتم — نادیده گرفتن viewDidDisappear برای توقف فعالیت‌ها. اگر گوش دادن به GPS، شتاب‌سنج یا ژیروسکوپ را در viewDidAppear شروع کرده‌اید، حتماً آن را در viewDidDisappear متوقف کنید. در غیر این صورت سنسورها به کار در پس‌زمینه ادامه می‌دهند و باتری را مصرف می‌کنند، حتی اگر کاربر مدت‌ها به صفحه دیگری رفته باشد. از فراخوانی‌های زوج start و stop در متدهای مربوطه چرخه حیات استفاده کنید — این مدیریت صحیح منابع دستگاه را تضمین می‌کند.