Silent Push — ماهیت، وظایف پس‌زمینه و پیکربندی تحویل

Silent Push چیست — ماهیت و هدف

Silent Push (اعلام خاموش push) یک مکانیسم iOS است که داده‌ها را بدون هیچ اعلام دیداری به کاربر به دستگاه تحویل می‌دهد. به عکس push استاندارد که بانر نمایش می‌دهد، صدا پخش می‌کند و به Notification Center می‌رود، silent push برنامه را در پس‌زمینه «بیدار» می‌کند و داده‌ها را برای پردازش به آن انتقال می‌دهد. کاربر هرگز از تحویل چنین اعلامی مطلع نمی‌شود — نتیجه محتوای به‌روز شده در بار بعدی است.

تفاوت با اعلام‌های push عادی

تفاوت اصلی در بار JSON است: silent push حاوی پرچم content-available: 1 است و alert، sound یا badge ندارد. اعلام استاندارد با alert همیشه به کاربر نمایش داده می‌شود، صنعتر نظر به content-available. Silent Push فقط با content-available: 1 و بدون alert کار می‌کند — اگر alert اضافه شود، سیستم حتی با وجود پرچم تحویل پس‌زمینه، اعلام را نمایش خواهد داد.

وقتی از Silent Push استفاده کنیم

اعلام‌های خاموش برای سناریوهایی که داده‌ها باید در لحظه باز شدن برنامه تازه باشند، اما کاربر نباید منحرف شود، ضروری هستند. نمونه‌ها: به‌روزرسانی خوراک خبر در پس‌زمینه، همگام‌سازی اشتراک‌ها، دانلود محتوای جدید برای دسترسی آفلاین، به‌روزرسانی ویجت‌ها، باطل سازی کش. Silent Push همچنین برای «گرم کردن» برنامه قبل از عمل منتظر کاربر استفاده می‌شود.

تحویل اعلام‌های خاموش چگونه کار می‌کند

تحویل Silent Push اساساً با اعلام‌های عادی تفاوت دارد و تابع قوانین بهینه‌سازی مصرف انرژی است. سیستم iOS درخواست push را از APNS دریافت می‌کند، تشخیص می‌دهد که silent push است (content-available: 1) و بر اساس چندین عامل درباره تحویل تصمیم می‌گیرد: سطح ظرفیت باتری، حالت صرفه‌جویی انرژی، فرکانس silent push‌های قبلی، فعالیت برنامه و بار فعلی CPU.

نقش Power Nap و حالت‌های پس‌زمینه

در دستگاه‌های با تراشه Apple M و iOS 15+، silent push با مکانیسم Power Nap که دوره‌ای دستگاه را برای وظایف پس‌زمینه بیدار می‌کند، ادغام می‌شود. Power Nap چندین silent push را در یک دوره فعالیت ترکیب می‌کند که مصرف کل انرژی را کاهش می‌دهد. توسعه‌دهنده نمی‌تواند Power Nap را مستقیماً مدیریت کند — سیستم بر اساس رفتار کاربر و تاریخچه استفاده از برنامه به طور خودکار تصمیم می‌گیرد.

پنجره پردازش 30 ثانیه‌ای

وقتی سیستم silent push را تحویل می‌دهد، برنامه فراخوانی application(_:didReceiveRemoteNotification:fetchCompletionHandler:) را در AppDelegate دریافت می‌کند. توسعه‌دهنده موظف است که completion handler را طی 30 ثانیه با نتیجه درست (UIBackgroundFetchResult) فراخوان کند. اگر پردازش به موقع تکمیل نشود، سیستم می‌تواند فرکانس silent push را برای این برنامه محدود کند یا اصلاً آن‌ها را متوقف کند.

// پردازش Silent Push در AppDelegate
func application(
    _ application: UIApplication,
    didReceiveRemoteNotification userInfo: [AnyHashable: Any],
    fetchCompletionHandler completionHandler:
    @escaping (UIBackgroundFetchResult) -> Void
) {
    guard let type = userInfo["sync-type"] as? String
    else {
        completionHandler(.failed)
        return
    }

    if type == "news-feed" {
        NewsFeedSyncService().sync { success in
            completionHandler(success ? .newData : .failed)
        }
    } else if type == "cache-invalidate" {
        CacheManager.shared.invalidateAll()
        completionHandler(.newData)
    } else {
        completionHandler(.noData)
    }
}

فاصله بین تحویل‌ها

Apple فاصله دقیق بین silent push‌ها را منتشر نمی‌کند، اما بر اساس آزمایش‌ها و مستندات توصیه می‌شود که حداکثر 2–3 اعلام خاموش در ساعت به یک دستگاه ارسال شود. در صورت ارسال مکررتر، سیستم آغاز به نادیده گرفتن silent push‌ها می‌کند و داده‌ها ارسال نمی‌شوند. اگر همگام‌سازی مکررتری مورد نیاز است، از URLSession با پیکربندی پس‌زمینه یا VoIP push استفاده کنید.

سناریوهای استفاده از Silent Push

Silent Push در طیف وسیعی از وظایفی کاربرد دارد که داده‌ها بدون مشارکت فعال کاربر باید به‌روز باشند. به موثرترین سناریوهای استفاده از این مکانیسم در برنامه‌های واقعی iOS نگاه می‌کنیم.

به‌روزرسانی محتوا برای دسترسی آفلاین

برنامه‌های خبری، خواننده‌ها و برنامه‌های مسافرتی از Silent Push برای دانلود محتوای جدید در پس‌زمینه استفاده می‌کنند. وقتی کاربر برنامه را باز می‌کند، داده‌ها از قبل دانلود شده‌اند و حتی بدون اینترنت نیز دسترس هستند. این رویکرد تجربه کاربری را تغییر اساسی می‌دهد — صفحات بارگیری خالی ناپدید می‌شوند و محتوا فوراً نمایش داده می‌شود. سرور هنگام ظهور مقالات جدید silent push ارسال می‌کند و برنامه در پس‌زمینه آن‌ها را برای خواندن آفلاین دانلود می‌کند.

همگام‌سازی وضعیت ویجت‌ها

iOS WidgetKit ویجت‌ها را طبق زمان‌بندی به‌روز می‌کند، اما برای به‌روزرسانی فوری پس از تغییر داده‌ها در سرور، از Silent Push استفاده می‌شود. برنامه در پس‌زمینه silent push را پردازش می‌کند، انبار محلی داده برای ویجت‌ها را به‌روز می‌کند و از طریق WidgetCenter به‌روزرسانی timeline را اجبار می‌کند. کاربر اطلاعات به‌روز را در ویجت بدون باز کردن برنامه می‌بیند — نرخ ارز، پیش‌بینی هوا، وضعیت تحویل.

باطل سازی کش و پاک سازی داده‌های کدقیمی

وقتی سرور داده‌های حیاتی را به‌روز می‌کند (مثلاً قوانین تعرفه‌گذاری، لیست ویژگی‌های در دسترس برای کاربران premium)، Silent Push امکان باطل سازی فوری کش محلی را فراهم می‌کند. در بار بعدی باز شدن برنامه داده‌های تازه را از سرور بارگیری می‌کند و از کش منسوخی استفاده نمی‌کند. این به ویژه برای برنامه‌های با محتوای پرداختی یا اشتراک‌ها مهم است.

به‌روزرسانی بدج بدون اعلام قابل مشاهده

در برخی سناریوها، به‌روزرسانی بدج روی آیکون برنامه بدون نمایش اعلام مورد نیاز است. Silent Push با فیلد badge در بار امکان تنظیم مقدار شمارنده را بدون مزاحمت کاربر با بانر فراهم می‌کند. به عنوان مثال، یک برنامه چت می‌تواند بدج را با تعداد پیام‌های خوانده‌نشده به‌روز کند بدون اینکه هر پیام جدید را به صورت اعلام نشان دهد، اگر کاربر داخل برنامه است.

پیکربندی silent push: بار و ظرفیت‌ها

برای کارکرد صحیح Silent Push، پیکربندی در سه سطح مورد نیاز است: پروژه Xcode، بار JSON در سرور و کد پردازش در برنامه. هر سطح حیاتی است: حذف هر مرحله منجر می‌شود که اعلام به صورت عادی یا اصلاً تحویل نشود.

پیکربندی ظرفیت‌ها در Xcode

در Xcode باید capability Push Notifications و Background Modes با گزینه Remote notifications فعال شوند. Push Notifications گواهینامه برای APNS تولید می‌کند و Remote notifications در Background Modes به سیستم اجازه می‌دهد پس از دریافت silent push برنامه را بیدار کند. بدون Remote notifications، silent push تحویل داده می‌شود اما برنامه در پس‌زمینه فعال نمی‌شود و داده‌ها پردازش نمی‌شوند.

ساختار بار JSON

بار Silent Push باید حاوی کلید aps با content-available: 1 باشد و alert، sound یا badge نداشته باشد. فیلدهای سفارشی در یک سطح با aps انتقال داده می‌شوند و حاوی داده‌های پردازش هستند: نوع عملیات، شناسه‌های شیئ، فرادادها. بار بدون content-available به عنوان اعلام عادی پردازش می‌شود؛ با alert — حتی با content-available، به عنوان عادی.

{
    "aps": {
        "content-available": 1
    },
    "sync-type": "news-feed",
    "last-article-id": "article_8521",
    "priority": "high"
}

پردازش در طرف کلینت

پس از دریافت silent push، iOS application(_:didReceiveRemoteNotification:fetchCompletionHandler:) را قبل از نمایان شدن برنامه فراخوان می‌کند. در این متد باید userInfo را تحلیل، کار مورد نیاز (درخواست‌های شبکه، نوشتن در Core Data، به‌روزرسانی کش) را انجام داد و حتماً در طول 30 ثانیه completionHandler را با نتیجه درست فراخوان کند. فراخوان نکردن completionHandler توسط سیستم به عنوان خطا در نظر گرفته می‌شود و بر فرکانس silent push‌های آینده تأثیر می‌گذارد.

محدودیت‌ها و روش‌های بهتر

Silent Push یک کانال قابل اعتماد برای عملیات حیاتی نیست — این یک مکانیسم بهینه‌سازی است، نه همگام‌سازی تضمینی. توسعه‌دهنده باید محدودیت‌ها را بفهمد و سیستم را به گونه‌ای طراحی کند که برنامه هم با silent push و هم بدون آن به درستی کار کند.

محدودیت‌های تحویل

iOS تحویل هر silent push را تضمین نمی‌کند. سیستم می‌تواند در صورت کاهش ظرفیت باتری (زیر 20، در حالة لیلی، در صورت فرکانس بالای silent push‌های قبلی، و همچنین اگر برنامه برای مدت طولانی توسط کاربر استفاده نشده باشد، تحویل را به تأخیر بیندازد یا لغو کند. آمار متوسط تحویل طبق Apple: حدود 70–80% از silent push‌ها طی 5 دقیقه تحویل می‌شوند، باقی ممکن است به تأخیر بیفتند یا از دست بروند.

توصیه‌های Apple برای silent push

Apple پیروی چند قاعده برای استفاده موثر از silent push را توصیه می‌کند. بیش از 2–3 silent push در ساعت به یک دستگاه ارسال نکنید — تجاوز از محدودیت منجر به محدودیت می‌شود. از compact payload استفاده کنید: حداقل حجم بار پردازش را سرع می‌بخشد و بار شبکه را کاهش می‌دهد. همیشه completionHandler را فراخوان کنید و تا حد امکان سریع‌تر: هر چه پردازش طولانی‌تر باشد، احتمال محدودیت silent push توسط سیستم در آینده بیشتر است.

جایگزین‌های Silent Push

برای سناریوهایی که نیازمند تحویل تضمینی یا زمان پردازش بیشتری هستند، جایگزین‌هایی را در نظر بگیرید. VoIP push (PushKit) تحویل را تضمین می‌کند و زمان بیشتری می‌دهد، اما فقط برای برنامه‌های VoIP است. Background fetch (UIApplication background fetch) توسط سیستم طبق زمان‌بندی اجرا می‌شود، اما قابل اجرا توسط سرور نیست. WebSocket اتصال ماندگار را حفظ می‌کند، اما باتری بیشتری مصرف می‌کند و برای همه انواع برنامه‌ها مناسب نیست.

نمایش و رفع اشکال

برای اشکال‌یابی Silent Push از Console.app در Mac با فیلتر بر اساس نام برنامه استفاده کنید. سیستم هر silent push را با برچسب «وظیفه پس‌زمینه» ثبت می‌کند و موفقیت‌آمیز بودن پردازش را نشان می‌دهد. در دستگاه بازرسی از طریق تنظیمات → توسعه‌دهنده → ثبت حالات پس‌زمینه انجام می‌شود. طرف سرور از طریق APNS Feedback Service برای تشخیص اعلام‌های تحویل ناشده پیگیری می‌شود.