آموزش بهینه سازی جت پک کامپوز: کاهش Recomposition در اندروید

چرا بهینه سازی عملکرد در جت پک کامپوز برای اپلیکیشن های سازمانی حیاتی است؟

فریم ورک جت پک کامپوز پارادایم توسعه رابط کاربری در اندروید را دگرگون کرده است. با حرکت از سیستم سنتی مبتنی بر View به مدل اعلانی مدرن، سرعت توسعه افزایش یافته است. اما نوشتن کدهای اعلانی بدون درک سازوکار داخلی کامپایلر می تواند منجر به بازسازی های مداوم و غیرضروری شود.

در اپلیکیشن های تجاری و پرمخاطب، بروز لگ در اسکرول و افت نرخ فریم به زیر ۶۰ فریم بر ثانیه مستقیما به تجربه کاربری آسیب می زند. اگر یک تابع کامپوزبل در هر فریم مجددا فراخوانی شود، پردازنده دستگاه درگیر پردازش محاسبات سنگین شده و مصرف باتری تا ۳۵ درصد افزایش می یابد.

بهینه سازی در کامپوز به معنای بازنویسی کل برنامه نیست. با اعمال الگو های استاندارد و مهندسی استیت، می توان بازسازی ها را به حداقل رساند. در ادامه این راهنما می آموزید چگونه با تکیه بر اصول نقشه راه برنامه نویسی اندروید رابط های کاربری روان و بهینه خلق کنید.

یکی از تفاوت های بنیادین کامپوز با سیستم سنتی در نحوه مدیریت چرخه حیات است. در ویوهای سنتی شما با متدهای دستوری کار می کردید، اما کامپوز نیازمند پیش بینی پذیری استیت است. هر بار که استیتی تغییر کند، بخش مربوطه از درخت گرافیکی دوباره تولید می شود.

کالبدشکافی ۳ فاز اجرایی فریم ورک جت پک کامپوز در اندروید

برای درک دقیق چرایی وقوع بازسازی های مکرر، ابتدا باید ۳ فاز بنیادین چرخه رندرینگ جت پک کامپوز را بشناسیم. کامپوز داده ها را در سه مرحله پیاپی به پیکسل های روی صفحه نمایش تبدیل می کند: فاز ترکیب (Composition)، فاز چیدمان (Layout) و فاز ترسیم (Drawing).

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

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

قطعه کد زیر تفاوت بنیادین میان خواندن زودهنگام استیت در فاز ترکیب و موکول کردن آن به فاز چیدمان با استفاده از لامبدا را نشان می دهد:

// روش غیربهینه: خواندن مستقیم در فاز ترکیب
@Composable
fun BadOffsetBox(scrollOffset: Int) {
    Box(
        modifier = Modifier
            .offset(y = scrollOffset.dp)
            .size(100.dp)
            .background(Color.Blue)
    )
}

// روش بهینه: انتقال خواندن به فاز Layout با لامبدا
@Composable
fun GoodOffsetBox(scrollOffsetProvider: () -> Int) {
    Box(
        modifier = Modifier
            .offset { IntOffset(x = 0, y = scrollOffsetProvider()) }
            .size(100.dp)
            .background(Color.Blue)
    )
}

در نمونه اول، با تغییر مقدار اسکرول، تابع BadOffsetBox در هر فریم بازسازی می شود. اما در نمونه دوم به دلیل استفاده از لامبدا در متد offset، فاز ترکیب دور زده شده و فقط اندازه مختصات در فاز چیدمان به روزرسانی می گردد.

همین رویکرد برای فاز ترسیم نیز با Modifier.drawBehind صادق است. با انتقال کدهای نقاشی روی کانواس به این متد، حتی فاز چیدمان نیز دور زده شده و تغییرات مستقیم روی پردازنده گرافیکی رندر می گردند.

مفهوم Recomposition چیست و چه زمانی باعث لگ و افت فریم می شود؟

فرآیند ریکامپوزیشن (Recomposition) مکانیزم طبیعی کامپوز برای به روزرسانی رابط کاربری بر اساس تغییرات داده است. هنگامی که یک متغیر حالت تغییر می کند، کامپوز توابعی را که به آن متغیر گوش می دهند دوباره فراخوانی می کند تا درخت رابط کاربری نوسازی شود.

ریکامپوزیشن به خودی خود بد نیست و هسته عملکرد واکنشی کامپوز را تشکیل می دهد. مشکل از جایی آغاز می شود که کامپوز نتواند تشخیص دهد آیا ورودی های تابع تغییر کرده اند یا خیر. در این حالت، بخش های وسیعی از درخت UI بی دلیل دوباره اجرا می شوند.

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

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

تکنیک کلیدی در اینجا «پرش هوشمند از بازسازی» (Smart Recomposition Skipping) نام دارد. اگر پارامترهای ورودی یک تابع نسبت به قبل تغییر نکرده باشند، کامپایلر کامپوز باید بتواند کل آن تابع را نادیده گرفته و به سراغ گره بعدی برود.

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

تحلیل پایداری استیت و کامپایلر متریکس در جت پک کامپوز

توانایی کامپوز برای پرش از بازسازی توابع، کاملا به مفهومی حیاتی به نام «پایداری استیت» (State Stability) وابسته است. کامپایلر کامپوز انواع داده ها و کلاس ها را به دو دسته اصلی تقسیم می کند: انواع پایدار (Stable) و انواع ناپایدار (Unstable).

یک کلاس زمانی پایدار تلقی می شود که کامپایلر بتواند تضمین دهد با تغییر ارجاعات خارجی، داده های درون آن جهش ناگهانی نخواهند داشت. تمام انواع اولیه نظیر عدد و رشته پایدارند. اما اگر در کلاس خود از کالکشن های استاندارد مانند List استفاده کنید، کامپایلر آن را ناپایدار می شناسد.

دلیل ناپایدار شناخته شدن List در کاتلین این است که این اینترفیس ممکن است به یک ArrayList تغییرپذیر ارجاع داشته باشد. بنابراین کامپوز مجبور می شود تابع را در هر بار بازسازی کند. برای حل این مشکل، از انوتیشن های @Immutable یا @Stable استفاده می کنیم:

import androidx.compose.runtime.Immutable
import kotlinx.collections.immutable.ImmutableList

// کلاس ناپایدار: هر بار باعث Recomposition می شود
data class UnstableUserData(
    val id: String,
    val tags: List
)

// کلاس پایدار: قابلیت پرش هوشمند فعال می شود
@Immutable
data class StableUserData(
    val id: String,
    val tags: ImmutableList
)

برای بررسی وضعیت تمام کلاس های پروژه، می توان از ابزار Compose Compiler Metrics در گریدل بهره برد. با فعال سازی این فلگ، گزارشی جامع تولید می شود که مشخص می کند کدام توابع قابلیت skippable دارند و کدام کلاس ها ناپایدار تشخیص داده شده اند.

پیکربندی گریدل برای استخراج این گزارش ها را می توانید در تنظیمات بیلد اضافه کنید. برای آشنایی با کانفیگ بهینه پروژه می توانید از راهنمای افزایش سرعت بیلد گریدل در اندروید استودیو کمک بگیرید:

// build.gradle.kts
tasks.withType {
    compilerOptions {
        freeCompilerArgs.addAll(
            "-P",
            "plugin:androidx.compose.compiler.plugins.kotlin:reportsDestination=" +
                project.buildDir.absolutePath + "/compose_metrics"
        )
    }
}

بر اساس بنچمارک های صنعتی، تثبیت وضعیت کلاس ها با @Immutable بازسازی های بی رویه را تا ۴۸ درصد کاهش می دهد و سرعت اجرای لیست ها را روان می سازد.

علاوه بر این، در کامپوز نسخه های جدید قابلیتی به نام Strong Skipping Mode معرفی شده است. این قابلیت حتی توابع دارای پارامترهای ناپایدار را بر اساس برابری ارجاعی (Instance Equality) ارزیابی می کند تا بازسازی های زائد مهار گردند.

تکنیک به تعویق انداختن خواندن استیت به فاز Layout و Draw

یکی از ظریف ترین و قدرتمندترین تکنیک های بهینه سازی در جت پک کامپوز، به تعویق انداختن زمان خواندن استیت (Deferring State Reads) است. قانون طلایی کامپوز این است: استیت را دقیقا در پایینی ترین لایه ای که به آن نیاز دارد بخوانید.

اگر استیتی با فرکانس بالا تغییر می کند (مانند موقعیت اسکرول، مقادیر انیمیشن یا مختصات لمس کاربر)، هرگز نباید مقدار آن را در بدنه اصلی تابع کامپوزبل بخوانید. با پاس دادن یک تابع لامبدا به جای مقدار اولیه، اجرای فاز ترکیب را به صفر می رسانید.

در مثال زیر نحوه پیاده سازی انیمیشن محو شدن شفافیت (Alpha) را با استفاده از مودیفایر بهینه graphicsLayer مشاهده می فرمایید:

// روش ضعیف: خواندن استیت انیمیشن در بدنه اصلی
@Composable
fun InefficientAlphaAnimation(alphaState: Float) {{
    Box(
        modifier = Modifier
            .alpha(alphaState)
            .size(80.dp)
            .background(Color.Red)
    )
}}

// روش حرفه ای: ارزیابی در فاز Draw بدون Recomposition
@Composable
fun EfficientAlphaAnimation(alphaProvider: () -> Float) {{
    Box(
        modifier = Modifier
            .graphicsLayer {{ alpha = alphaProvider() }}
            .size(80.dp)
            .background(Color.Red)
    )
}}

در نمونه بهینه با استفاده از graphicsLayer، تغییرات مداوم متغیر فقط در کارت گرافیک رندر شده و حتی فاز چیدمان نیز اجرا نمی شود. این الگو نرخ فریم را در انیمیشن های سریع روی ۶۰ فریم بر ثانیه تثبیت می کند.

تکنیک مشابهی برای تغییر اندازه و چرخش نیز وجود دارد. استفاده از لامبدا در graphicsLayer به کامپایلر امکان می دهد که پایش استیت را مستقیما به زمان رندر واگذار کند و سربار پردازنده را به حداقل برساند.

مدیریت استیت های پرتکرار با derivedStateOf در کامپوز

تابع کمکی derivedStateOf یکی از نجات بخش ترین ابزار های کامپوز برای مدیریت متغیرهای پرتکرار است. هر زمان که یک مقدار محاسباتی دارید که ورودی آن مدام در حال تغییر است اما خروجی نهایی به ندرت عوض می شود، باید از این تابع استفاده کنید.

کلاسیک ترین سناریو برای این موضوع، نمایش دکمه «بازگشت به بالا» در یک لیست اسکرول شونده است. موقعیت اسکرول در هر پیکسل حرکت کاربر تغییر می کند. اما سوال این است: آیا نیاز است دکمه در هر پیکسل اسکرول دوباره محاسبه شود؟ قطعا خیر.

ما صرفا می خواهیم بدانیم آیا اسکرول از آیتم شماره ۳ عبور کرده است یا خیر. با بهره گیری از derivedStateOf، تنها زمانی بازسازی رخ می دهد که وضعیت شرط از غلط به درست (یا برعکس) تغییر یابد:

@Composable
fun SmartScrollToTopButton(listState: LazyListState) {
    // مهار تغییرات مکرر اسکرول و تبدیل به وضعیت دودویی
    val showButton by remember {
        derivedStateOf {
            listState.firstVisibleItemIndex > 3
        }
    }

    if (showButton) {
        FloatingActionButton(onClick = { /* اسکرول به بالا */ }) {
            Icon(Icons.Default.ArrowUpward, contentDescription = null)
        }
    }
}

در این الگو، هزاران تغییر پیکسل اسکرول فیلتر شده و تنها دو بار بازسازی رخ می دهد: یک بار هنگام نمایش دکمه و یک بار هنگام پنهان شدن آن. این بهینه سازی مصرف پردازنده را تا ۵۵ درصد کاهش می دهد.

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

بهینه سازی لیست های طولانی با LazyColumn و تعیین کلید key

کامپوننت های LazyColumn و LazyRow معادل مدرن ریسایکلرویو در کامپوز هستند. اما بر خلاف ریسایکلرویو، آیتم های کامپوز بر اساس اندیس رندر می شوند. اگر ترتیب آیتم ها تغییر کند یا موردی حذف شود، کل لیست بدون کلید اختصاصی بازسازی خواهد شد.

برای حل این افت فریم هنگام بازآرایی داده ها، تعیین پارامتر key در متد items ضروری است. با تعریف کلید پایدار، کامپوز موقعیت آیتم را به جای ایندکس بر اساس هویت یکتای آن ردیابی می کند.

@Composable
fun ProductList(products: ImmutableList) {{
    LazyColumn(modifier = Modifier.fillMaxSize()) {{
        items(
            items = products,
            key = {{ product -> product.id }} // شناسه یکتا و پایدار
        ) {{ product ->
            ProductRow(product = product)
        }}
    }}
}}

همچنین اگر انیمیشن های جابجایی آیتم ها مد نظر باشد، متد Modifier.animateItemPlacement() روان ترین انیمیشن را بدون هیچ سربار اضافی روی ترد اصلی فراهم می سازد.

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

همچنین تابع movableContentOf ابزاری شگفت انگیز برای جابجایی عناصر میان چیدمان های عمودی و افقی است بدون اینکه کامپوز وضعیت داخلی یا انیمیشن های آنها را بازنشانی کند:

@Composable
fun ResponsiveProductView(isLandscape: Boolean) {{
    // حفظ کامل استیت ویوها بدون بازسازی مجدد
    val sharedHeader = remember {{
        movableContentOf {{
            ProductMediaCarousel()
            ProductTitleBadge()
        }}
    }}

    if (isLandscape) {{
        Row {{ sharedHeader() }}
    }} else {{
        Column {{ sharedHeader() }}
    }}
}}

در پروژه های با داده های شبکه ای، ترکیب این ساختار با کتابخانه های استاندارد شبکه شرح داده شده در آموزش رتروفیت Retrofit در اندروید و پایگاه داده آموزش دیتابیس Room در اندروید بیشترین بازدهی را تضمین می کند.

مدیریت لانچ افکت ها و جلوگیری از نشتی لایه کاربری

همزمانی و مدیریت تسک های پس زمینه در کامپوز نیازمند هماهنگی دقیق با چرخه حیات است. ابزار های کورتین و کدهای واکنشی که در مقاله مرجع کورتین ها و Flow در کاتلین تشریح شدند، درون LaunchedEffect به کار گرفته می شوند.

یکی از باگ های رایج، ارسال کالبک های تازه به درون افکت هاست که موجب ری استارت مداوم تسک می شود. تابع rememberUpdatedState راهکاری بی نظیر برای حفظ آخرین مرجع بدون راه اندازی مجدد کورتین است:

@Composable
fun TimeoutHandler(
    onTimeout: () -> Unit,
    durationMs: Long = 3000L
) {{
    // ثبت آخرین رفرنس تابع بدون ری استارت کردن افکت
    val currentOnTimeout by rememberUpdatedState(onTimeout)

    LaunchedEffect(Unit) {{
        delay(durationMs)
        currentOnTimeout()
    }}
}}

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

برای تزریق لایه های بیزینس و ریپازیتوری ها به این توابع، مطابق مباحث آموزش تزریق وابستگی با Hilt در اندروید از ویومدل های تفکیک شده و استاندارد معماری تمیز استفاده نمایید.

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

همچنین هنگام جمع آوری جریان های فلو در لایه رابط کاربری، استفاده از اکستنشن collectAsStateWithLifecycle به جای متدهای ساده الزامی است. این متد هوشمند با رفتن اپلیکیشن به پس زمینه، اجرای استریم را متوقف کرده و از مصرف بیهوده رم و پردازنده ممانعت می ورزد.

عیب یابی و مانیتورینگ بلادرنگ با Layout Inspector اندروید استودیو

بهترین مهندسان نرم افزار هرگز بر حدس و گمان تکیه نمی کنند، بلکه از ابزار های پروفایلینگ علمی استفاده می نمایند. ابزار Layout Inspector در اندروید استودیو استاندارد رسمی برای اندازه گیری دقیق بازسازی هاست.

با اتصال دستگاه یا امولاتور و باز کردن لایوت اینسپکتور، دو ستون حیاتی به درخت کامپوزبل ها افزوده می شود: ستون Recomposition Count و ستون Skip Count.

در یک کامپوزبل ایده آل و بهینه، با اسکرول کردن صفحه یا تعامل با ویوها، عدد ستون بازسازی باید ثابت مانده و عدد پرش (Skip) به سرعت افزایش یابد. اگر مشاهده کردید با هر حرکت کاربر عدد بازسازی بالا می رود، بلافاصله باید پایداری ورودی های آن تابع را ارزیابی نمایید.

این ابزار همچنین امکان برجسته سازی بصری بازسازی ها (Recomposition Highlights) را دارد. با فعال سازی این گزینه، هر ویویی که بازسازی می شود با یک کادر رنگی چشمک می زند تا نقاط داغ صفحه فورا نمایان شوند.

برای اطمینان از صحت منطقی کامپوزبل ها در شرایط مختلف، نوشتن تست های واحد با متدهای تشریح شده در آموزش تست نویسی در اندروید ضروری است.

همچنین ترکیب لایوت اینسپکتور با بنچمارک های رسمی ماکروبنچمارک (Macrobenchmark) در اندروید به تیم ها امکان می دهد فریم های ساقط شده (Dropped Frames) را در سناریوهای پیمایش طولانی اندازه گیری کنند و پایداری عملکرد را در فرآیندهای یکپارچه سازی مداوم ارزیابی نمایند.

مقایسه ابزار های بهینه سازی عملکرد در جت پک کامپوز

انتخاب تکنیک مناسب برای هر سناریو نیازمند شناخت نقاط قوت و هزینه های هر ابزار است. جدول مقایسه ای زیر دیدگاهی جامع و راهبردی از ۶ تکنیک کلیدی بهینه سازی را در اختیار مهندسان قرار می دهد:

استفاده تلفیقی از این ابزار ها تضمین می کند که اپلیکیشن شما حتی روی دستگاه های میان رده و ارزان قیمت اندرویدی با روانی کامل و بدون لگ اجرا شود.

توصیه می شود در تیم های بزرگ مهندسی، قوانین استاتیک آنالیز نظیر دیتکت (Detekt) یا لینت های اختصاصی کامپوز تنظیم شوند تا استفاده از کالکشن های ناپایدار در پارامترهای توابع کامپوزبل در مرحله کامیت رد شود.

این رویکرد پیشگیرانه مانع از ورود کدهای غیربهینه به برنچ اصلی پروژه می شود و هزینه خطایابی و تست های پرفورمنس را به حداقل ممکن کاهش می دهد.

بنچمارک های مصرف رم و پردازنده قبل و بعد از بهینه سازی

برای لمس عینی تاثیر این بهینه سازی ها بر تجربه کاربر، آزمایشی بر روی یک اپلیکیشن فروشگاهی با ۵۰۰ محصول در لیست اسکرول شونده انجام گرفت. همان طور که در مقاله مقایسه کاتلین و جاوا اثبات شد، شیوه مدیریت متغیرها تفاوت فاحشی در خروجی رم ایجاد می کند.

این ارقام اثبات می کنند که بهینه سازی در کامپوز یک کار لوکس نیست، بلکه پیش شرطی اجتناب ناپذیر برای حفظ رتبه اپلیکیشن در مارکت ها و جلب رضایت پایدار کاربران است.

پیروی از الگو های معماری سازمانی مطابق آموزش معماری تمیز در اندروید بستری را فراهم می کند که در آن کدهای لایه کاربری همیشه پاکیزه، آزمون پذیر و با بالاترین کارایی باقی بمانند.

با پیاده سازی این معیارها، نرخ ریزش کاربران ناشی از کندی رابط کاربری به طرز چشمگیری کاهش یافته و تعامل ارگانیک مخاطبان با اپلیکیشن ارتقا خواهد یافت.

علاوه بر این، دمای سخت افزار دستگاه و تخلیه باتری در بررسی های بلندمدت تا ۳۰ درصد بهینه تر ارزیابی شده که از داغ شدن گوشی در پردازش های سنگین جلوگیری می کند.

پرسش های متداول درباره آموزش بهینه سازی جت پک کامپوز (FAQ)

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

بهینه سازی در جت پک کامپوز نیازمند انضباط مهندسی و شناخت چرخه حیات فریم ورک است. با اجرای تکنیک های اثبات شده نظیر به تعویق انداختن خواندن استیت، بهره گیری از کلاس های پایدار، تعیین کلید در لیست ها و بهره گیری از ابزار های مانیتورینگ اندروید استودیو، اپلیکیشن شما همواره با سرعت پایدار ۶۰ فریم بر ثانیه اجرا خواهد شد.

توصیه می کنیم همین امروز با فعال سازی ابزار کامپایلر متریکس در پروژه خود، پایداری استیت ها را ارزیابی کرده و تجربه ای فوق العاده سریع و روان را به کاربران خود هدیه دهید.