نظارت بر عملکرد — چیست، معیارها و جمع‌آوری داده

نظارت بر عملکرد چیست

نظارت بر عملکرد — روش ارزیابی کمی رفتار برنامه از طریق جمع‌آوری معیارهای زمان اجرا، استفاده از حافظه، نرخ فریم و مصرف انرژی. برخلاف گزارش کرش که فقط خرابی‌های مهلک را ثبت می‌کند، نظارت بر عملکرد تخریب تدریجی را ردیابی می‌کند: برنامه کار می‌کند، اما کندتر از آنچه باید.

بر اساس گزارش Google (2024)، ۵۳٪ کاربران برنامه را می‌بندند اگر بارگذاری آن بیش از ۳ ثانیه طول بکشد. هر ثانیه تأخیر اضافی به طور متوسط نرخ تبدیل را ۲۰٪ در رده‌های مختلف کاهش می‌دهد. این امر نظارت بر عملکرد را نه فقط یک رویه فنی، بلکه ضرورتی تجاری برای محصولات موبایل می‌سازد.

نظارت مدرن بر عملکرد چهار سطح را پوشش می‌دهد: سمت کلاینت (iOS, Android)، شبکه (درخواست‌های API، WebSocket)، سرویس‌های بک‌اند و زیرساخت. در توسعه موبایل، تمرکز بر معیارهای کلاینتی است، زیرا بیشتر مشکلات عملکرد دقیقاً در دستگاه کاربر رخ می‌دهد.

معیارهای کلیدی برنامه موبایل

برای نظارت کامل باید پنج گروه معیار را ردیابی کرد که هر کدام مسئول جنبه‌ای از تجربه کاربری هستند. FPS (frames per second) روانی انیمیشن‌ها و اسکرول را نشان می‌دهد — مقدار زیر ۳۰ فریم در ثانیه توسط چشم به عنوان کندی احساس می‌شود.

معیارهای زمان

زمان راه‌اندازی سرد برنامه — از لحظه لمس آیکون تا آمادگی کامل رابط کاربری. زمان راه‌اندازی گرم — بازگشت از پس‌زمینه. زمان پاسخ به عملکرد کاربر (tap-to-response). زمان راه‌اندازی برای Android از طریق ActivityManager و برای iOS از طریق dyld و زمان premain اندازه‌گیری می‌شود. به گفته Firebase Performance، میانه زمان راه‌اندازی سرد برای ۱۰۰ برنامه برتر ۱.۸ ثانیه است.

معیارهای حافظه و CPU

مصرف حافظه رم نباید از ۸۰٪ حجم موجود در دستگاه تجاوز کند، در غیر این صورت سیستم شروع به تخلیه برنامه از پس‌زمینه می‌کند. ردپای حافظه از طریق Xcode Instruments (iOS) و Android Profiler ردیابی می‌شود. نشت حافظه با افزایش مصرف در عملیات تکراری — مثلاً جابجایی بین صفحات — شناسایی می‌شود.

معیارهای شبکه

زمان اجرای درخواست HTTP، اندازه پاسخ، فراوانی تایم‌اوت و خطاها. تأخیر شبکه به ویژه برای برنامه‌های موبایلی که در شرایط اتصال ناپایدار کار می‌کنند (3G، مترو، آسانسور، رومینگ) حیاتی است. توصیه می‌شود زمان پاسخ p95 ردیابی شود — دقیقاً تجربه سنگین‌ترین کاربران با بدترین شرایط شبکه را نشان می‌دهد.

Real User Monitoring و Synthetic Monitoring

Real User Monitoring (RUM) داده‌هایی را از دستگاه‌های واقعی کاربران در محیط تولید جمع‌آوری می‌کند. این روش تأخیرهای واقعی را که کاربران با توجه به دستگاه‌ها، نسخه‌های سیستم‌عامل، شبکه و موقعیت جغرافیایی خود تجربه می‌کنند نشان می‌دهد. RUM دقیق‌ترین تصویر از عملکرد را ارائه می‌دهد، اما به این بستگی دارد که چه کاربرانی در نمونه قرار گرفته‌اند.

Synthetic Monitoring برعکس، سناریوهای از پیش تعیین‌شده را روی دستگاه‌های آزمایشی در شرایط کنترل‌شده اجرا می‌کند. این امکان تشخیص رگرسیون را پیش از رسیدن به کاربران و بازتولید مشکلات در محیطی یکسان فراهم می‌کند. Firebase Test Lab و BrowserStack تست‌های مصنوعی را روی دستگاه‌های واقعی بدون اجرای دستی ارائه می‌دهند.

استراتژی بهینه ترکیب هر دو رویکرد است: تست‌های مصنوعی رگرسیون‌ها را در مرحله CI می‌گیرند و RUM تصویر واقعی را در تولید نشان می‌دهد. به گفته Datadog (2024)، تیم‌هایی که از هر دو روش استفاده می‌کنند ۳۵٪ بیشتر مشکلات عملکرد را پیش از تبدیل شدن به حادثه کشف می‌کنند.

راه‌اندازی Firebase Performance Monitoring

Firebase Performance Monitoring — ابزار رایگان از Google برای جمع‌آوری معیارهای عملکرد در iOS و Android. این ابزار به طور خودکار زمان راه‌اندازی برنامه، درخواست‌های HTTP و رندر صفحات را بدون نیاز به نوشتن کد اندازه‌گیری می‌کند. برای نصب کافی است SDK را به پروژه اضافه و ماژول Performance را در کنسول Firebase فعال کنید.

جمع‌آوری خودکار معیارها

پس از اتصال SDK، Firebase Performance به طور خودکار برای هر درخواست HTTP از طریق URLSession (iOS) یا OkHttp (Android) trace ایجاد می‌کند. رندر صفحه برای UIViewController و Activity اندازه‌گیری می‌شود و زمان از onCreate/viewDidLoad تا پایان اولین رندر را ثبت می‌کند. همه معیارها در کنسول Firebase با تفکیک نسخه‌های برنامه، دستگاه‌ها و کشورها جمع‌آوری می‌شوند.

import com.google.firebase.perf.FirebasePerformance
import com.google.firebase.perf.metrics.Trace

class PaymentService {
    private val firebasePerf = FirebasePerformance.getInstance()

    fun processPayment(amount: Double) {
        val trace = firebasePerf.newTrace("payment-flow")
        trace.start()
        trace.putAttribute("amount", amount.toString())
        // اجرای پرداخت
        trace.stop()
    }
}

کد یک trace سفارشی برای سناریوی پرداخت با ویژگی مبلغ ایجاد می‌کند. از طریق این trace در کنسول Firebase می‌توان میانه و p95 زمان اجرای پرداخت را مشاهده و بر اساس نسخه‌های برنامه و دستگاه‌ها گروه‌بندی کرد.

نظارت HTTP

Firebase به طور خودکار درخواست‌های شبکه را intercept کرده و URL، کد پاسخ، اندازه payload و زمان اجرا را ثبت می‌کند. برای OkHttp در Android ابزار دقیق خودکار بدون پیکربندی اضافی کار می‌کند. درخواست‌های شبکه در کنسول با گروه‌بندی بر اساس endpointها نمایش داده می‌شوند که امکان شناسایی سریع کندی یک API خاص را فراهم می‌کند.

Traceهای سفارشی برای منطق کسب‌وکار

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

هر trace سفارشی باید نام معناداری در قالب «سناریو-عمل» داشته باشد و شامل ویژگی‌هایی برای فیلتر کردن باشد. مثلاً trace «image-upload» با ویژگی‌های «file_size» و «compression_quality» امکان شناسایی وابستگی زمان بارگذاری به اندازه تصویر را فراهم می‌کند. توصیه می‌شود بیش از ۲۰ trace سفارشی برای یک صفحه ایجاد نشود — ابزار دقیق بیش از حد نویز ایجاد کرده و تحلیل را دشوار می‌کند.

import FirebasePerformance

func trackImageUpload(data: Data) {
    let trace = Performance.startTrace(name: "image-upload")
    trace?.setValue(data.count, forAttribute: "file_size")
    trace?.setValue("high", forAttribute: "compression")
    // بارگذاری تصویر
    trace?.stop()
}

مثال در Swift یک trace برای بارگذاری تصویر با ویژگی‌های اندازه فایل و سطح فشرده‌سازی ایجاد می‌کند. در کنسول Firebase این ویژگی‌ها به فیلدهایی برای گروه‌بندی و فیلتر کردن معیارها تبدیل می‌شوند.

آستانه‌های هشدار و اعلان

جمع‌آوری معیارها بدون سیستم اعلان بی‌فایده است. اعلان باید تیم را از خروج معیارها از محدوده مجاز آگاه کند، و آستانه‌های هشدار به سه سطح تقسیم می‌شوند: هشدار (warning)، بحرانی (critical) و قطعی (outage). هر سطح کانال اعلان را تعیین می‌کند: warning — در کانال Slack تیم، critical — در PagerDuty مهندس شیفت، outage — ارسال انبوه به همه ذی‌نفعان.

برای معیارهای موبایل توصیه می‌شود از آستانه‌های پویا بر اساس صدک‌ها استفاده شود: p95 زمان راه‌اندازی سرد بیش از ۴ ثانیه — هشدار بحرانی. آستانه‌های ایستا (مثلاً CPU > 90%) بدتر عمل می‌کنند زیرا نوسانات عادی بار را بر اساس زمان روز و روز هفته در نظر نمی‌گیرند. Firebase Performance از تنظیم هشدارها از طریق Firebase Console با ارسال به Slack، PagerDuty و ایمیل با قابلیت escalation در صورت عدم تأیید پشتیبانی می‌کند.

بر اساس Incident Management Survey (2024)، تیم‌هایی که هشدارها را بر اساس صدک‌ها تنظیم می‌کنند به جای مقادیر میانگین، ۴۵٪ حوادث کمتری را از دست می‌دهند. مقدار میانگین (average) نوسانات را هموار می‌کند — p95 به طور تضمینی بدترین سناریو را برای کاربران بدون توجه به زمان روز و نوسانات فصلی بار نشان می‌دهد.