کند شدن در توسعه — چیست، دلایل و روش‌های بهینه‌سازی

«کند شدن» در توسعه موبایل به چه معناست

کند شدن — یک اصطلاح غیررسمی است که کاربران با آن عملکرد ذهنی کند برنامه را توصیف می‌کنند. برخلاف لگ که به صورت تأخیر ثابت ظاهر می‌شود، کند شدن هنگ‌های نامنظم است: برنامه می‌تواند چند ثانیه عالی کار کند و سپس 1–3 ثانیه «فکر کند».

ویژگی فنی پدیده

از دیدگاه پروفایل‌سازی، کند شدن به صورت یک سری فریم‌های از دست رفته (jank) با تأخیرهای پیک بیش از 100 ms ظاهر می‌شود. در نمودار FPS این به صورت افت‌های شدید دیده می‌شود: 60 → 20 → 55 → 10 فریم در ثانیه. برخلاف لگ با FPS یکنواخت پایین، کند شدن تغییرپذیری آشکاری دارد.

ادراک کاربر

وقتی برنامه کند می‌شود، کاربر منطق کندی را درک نمی‌کند: صفحه می‌تواند نرم اسکرول شود و سپس ناگهان برای یک ثانیه متوقف شود. این باعث ناامیدی و کاهش اعتماد به برنامه می‌شود. طبق Google، 53% کاربران سایت یا برنامه را ترک می‌کنند اگر بارگذاری بیش از 3 ثانیه طول بکشد.

دلایل کندی ناگهانی در برنامه‌ها

ماهیت نامنظم کند شدن نشان می‌دهد که مشکل ناشی از عوامل رویدادی است، نه بارگذاری دائمی. بیایید سناریوهای معمول را بررسی کنیم.

مکث‌های GC هنگام تخصیص اشیا

در Android در محیط ART، جمع‌آوری زباله همه رشته‌های برنامه را متوقف می‌کند. اگر در کد اشیای موقت زیادی ایجاد شود — مثلاً در هر فراخوانی onBindViewHolder یک String جدید از طریق اتصال ایجاد شود — GC بیشتر اجرا می‌شود. مکث بسته به اندازه heap و نسل اشیا می‌تواند 5–50 ms طول بکشد. کاربر این را به عنوان «فکر کردن» ناگهانی احساس می‌کند.

کوئری‌های همزمان SQL در رشته UI

Room در Android و Core Data در iOS از کوئری‌های ناهمزمان پشتیبانی می‌کنند، اما توسعه‌دهندگان اغلب برای سادگی getValue() فراخوانی می‌کنند یا کوئری را از طریق runBlocking اجرا می‌کنند. SELECT سنگین با join روی جدول 10 000 ردیفی می‌تواند 200–500 ms طول بکشد و UI را کاملاً مسدود کند.

دکدگذاری تصویر بدون downscale

بارگذاری تصویر دوربین (12 مگاپیکسل، 4000x3000 px) بدون مقیاس‌بندی تا 200 ms برای دکدگذاری به Bitmap طول می‌کشد. اگر تصاویر به صورت ناهمزمان بارگذاری شوند اما بدون پول رشته با محدودیت، اجرای همزمان 5–6 دکدگذاری می‌تواند CPU را بیش از حد بارگذاری کرده و باعث کندی‌های سرگردان شود.

• Android — اتصال رشته‌ها در حلقه‌ها، ایجاد اشیا در مسیرهای داغ، Bitmap بدون inSampleSize
• iOS — پول‌های autorelease با تعداد زیادی اشیا، imageWithContentsOfFile بدون مقیاس‌بندی، URLSession همزمان
• Cross-platform — تجزیه JSON در رشته UI، بارگذاری داده در رشته اصلی با انتظار پاسخ سرور

چگونه هنگ کردن را در Android و iOS تشخیص دهیم

تشخیص کندی‌های نامنظم دشوارتر از تشخیص لگ‌های ثابت است، زیرا مشکل ممکن است در هر اجرا تکرار نشود. نیاز به جمع‌آوری آمار در یک دوره طولانی است.

Memory Profiler با ثبت رویدادهای GC

Android Studio Memory Profiler نه تنها استفاده از حافظه، بلکه رویدادهای GC را نیز نشان می‌دهد: دفعات، نوع (Concurrent، Full)، مدت. اگر GC در حالت سکون بیش از 1 بار در 5 ثانیه رخ دهد — این نشانه تخصیص بیش از حد است. ثبت heap dump در لحظه کند شدن امکان دیدن اشیایی که حافظه را اشغال می‌کنند فراهم می‌کند.

Xcode Instruments با Allocation Tracking

در iOS از الگوی Allocations در Instruments برای ردیابی ایجاد و آزادسازی اشیا استفاده کنید. نسل‌ها (Generations) را فعال کنید — آنها امکان گرفتن عکس‌هایی از heap بین عملیات و دیدن اشیایی که در حافظه باقی می‌مانند را فراهم می‌کنند. اشیای پایدار (Persistent objects) که آزاد نمی‌شوند — منبع انباشت حافظه و مکث‌های بعدی هستند.

API JankStats در Android

JankStats — کتابخانه Android که معیارهای فریم‌های از دست رفته را در زمان واقعی جمع‌آوری می‌کند. هر jank را به سناریوی فعلی (مثلاً «اسکرول لیست»، «باز کردن صفحه») متصل می‌کند که این امکان را می‌دهد بفهمیم کند شدن دقیقاً در کدام عمل رخ می‌دهد.

مثال ادغام JankStats برای ردیابی هنگ‌ها در Android:

class MainActivity : AppCompatActivity() {
    private lateinit var jankStats: JankStats

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        jankStats = JankStats.create(this.window.decorView) { frameData ->
            if (frameData.isJank()) {
                Log.w("Jank", "Duration=${frameData.durationMs}ms")
            }
        }
    }
}

روش‌های رفع کندی کار

رفع کند شدن نیاز به کار هدفمند با هر علت دارد. راه‌حل جهانی وجود ندارد — نیاز به تحلیل پروفایل‌های عملکرد خاص است.

پیاده‌سازی صفحه‌بندی از طریق Paging 3

اگر لیست شامل 1000+ عنصر است و همه یکباره بارگذاری می‌شوند — این کند شدن تضمینی است. Paging 3 در Android و NSFetchedResultsController در iOS داده‌ها را در حین اسکرول به صورت تکه‌ای بارگذاری می‌کنند. کاربر فقط 10–20 عنصر اول را می‌بیند، بقیه در پس‌زمینه بارگذاری می‌شوند.

بهینه‌سازی کوئری‌های SQL و ایندکس‌ها

Room امکان پروفایل‌سازی کوئری‌ها را از طریق Inspection Tool در Android Studio فراهم می‌کند: زمان اجرا، تعداد ردیف‌های برگشتی و plan کوئری قابل مشاهده است. افزودن ایندکس به ستون‌های WHERE و ORDER BY می‌تواند زمان کوئری را از 300 ms به 5 ms کاهش دهد. در iOS بررسی مشابه توسط Core Data Profiler در Instruments انجام می‌شود.

انتقال وظایف به WorkManager

همگام‌سازی‌های پس‌زمینه، بارگذاری فایل‌ها، پردازش داده‌ها — همه اینها باید از طریق WorkManager (Android) یا Background Tasks (iOS) انجام شوند. اگر همگام‌سازی در رشته UI اجرا شود، برنامه در طول اجرا کند می‌شود. WorkManager اجرا را در رشته پس‌زمینه با در نظر گرفتن وضعیت باتری و شبکه تضمین می‌کند.

مثال همگام‌سازی پس‌زمینه از طریق WorkManager در Android:

class SyncWorker(context: Context, params: WorkerParameters)
    : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result {
        return try {
            Log.d("Sync", "همگام‌سازی داده در رشته پس‌زمینه")
            syncData()
            Result.success()
        } catch (e: Exception) {
            Result.retry()
        }
    }
}

پیشگیری از کند شدن در مرحله توسعه

می‌توان از کند شدن در مرحله نوشتن کد با پیروی از اصول کار مؤثر با حافظه و رشته‌ها جلوگیری کرد.

Baseline Profiles برای کامپایل AOT

Baseline Profiles — فهرستی از کلاس‌ها و متدهایی است که Android از قبل (AOT) کامپایل می‌کند، نه JIT. بدون پروفایل، هر صفحه جدید در اولین باز شدن کامپایل می‌شود و باعث تأخیر 100–500 ms می‌شود. Baseline Profile را برای صفحات کلیدی آماده کنید و تولید را در Gradle از طریق baseline-profile-gradle-plugin فعال کنید.

حداقل‌سازی تخصیص در مسیرهای داغ

Hot path — کدی است که در هر فریم اجرا می‌شود: onBindViewHolder، draw، layoutSubviews. از ایجاد اشیا در این متدها خودداری کنید: از پول اشیا استفاده کنید، به جای اتصال از StringBuilder استفاده کنید، رشته‌های فرمت شده و فرمت‌ها را کش کنید. هر تخصیص اضافی GC بعدی را نزدیک‌تر می‌کند.

پروفایل‌سازی از طریق Baseline Profiles در CI

به pipeline CI اجرای Macrobenchmark با سناریوی اسکرول لیست و باز کردن صفحه اضافه کنید. آستانه تعیین کنید: صدک 99 زمان فریم نباید از 16 ms تجاوز کند. اگر آستانه افزایش شود — build تا بهینه‌سازی رد می‌شود.

• Android — Baseline Profiles، Macrobenchmark، JankStats، StrictMode با penaltyDeath
• iOS — MetricKit، os_signpost، XCTMetric، Main Thread Checker در طرح Debug
• رویکرد کلی — پروفایل‌سازی منظم، بازبینی کد با تمرکز بر تخصیص در مسیرهای داغ