معیارهای ماکرو بنچمارک را ضبط کنید

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

قطعه کد زیر، زمان‌بندی فریم و معیارهای بخش ردیابی سفارشی را برای رابط کاربری طرح‌بندی تنبل Jetpack Compose ثبت می‌کند:

@OptIn(ExperimentalMetricApi::class)
    @Test
    fun scrollComposeList() {
        benchmarkRule.measureRepeated(
            // [START_EXCLUDE]
            packageName = TARGET_PACKAGE,
            metrics = listOf(
                FrameTimingMetric(),
                // Measure power usage. This is supported on Pixel 6 and later.
                PowerMetric(PowerMetric.Type.Power(
                    mapOf(
                        PowerCategory.CPU to PowerCategoryDisplayLevel.TOTAL,
                        PowerCategory.DISPLAY to PowerCategoryDisplayLevel.TOTAL,
                        PowerCategory.GPU to PowerCategoryDisplayLevel.TOTAL,
                        PowerCategory.NETWORK to PowerCategoryDisplayLevel.TOTAL,
                    )
                )),
                // Measure custom trace sections by name EntryRow (which is added to the EntryRow composable).
                // Mode.Sum measures combined duration and also how many times it occurred in the trace.
                // This way, you can estimate whether a composable recomposes more than it should.
                TraceSectionMetric("EntryRowCustomTrace", TraceSectionMetric.Mode.Sum),
                // This trace section takes into account the SQL wildcard character %,
                // which can find trace sections without the full name.
                // This way, you can measure composables produced by the composition tracing
                // and measure how long they took and how many times they recomposed.
                // WARNING: This metric only shows results when running with composition tracing, otherwise it won't be visible in the outputs.
                TraceSectionMetric("%EntryRow%", TraceSectionMetric.Mode.Sum),
            ),
            // Try switching to different compilation modes to see the effect
            // it has on frame timing metrics.
            compilationMode = CompilationMode.None(),
            startupMode = StartupMode.WARM, // restarts activity each iteration
            iterations = DEFAULT_ITERATIONS,
            // [END_EXCLUDE]
            setupBlock = {
                uiAutomator {
                    // Before starting to measure, navigate to the UI to be measured.
                    startIntent(Intent("$packageName.COMPOSE_ACTIVITY"))
                }
            }
        ) {
            uiAutomator {
                onElement { isScrollable }.fling(Direction.DOWN)
            }
        }
    }

در مثال زیر، EntryRowCustomTrace یک بخش ردیابی سفارشی را نشان می‌دهد که درون لایه‌های آیتم قابل ترکیب با استفاده از بسته‌بندی بلوک استاندارد Kotlin trace(sectionName) { ... } تعریف شده است. برای ارائه داده‌ها برای TraceSectionMetric ، باید اجزای رابط کاربری هدف را درون کدبیس تولید برنامه خود با بسته‌بندی بلوک trace استاندارد Jetpack runtime قرار دهید:

@Composable
private fun EntryRow(entry: Entry, modifier: Modifier = Modifier) = trace("EntryRowCustomTrace") {
    Card(modifier = modifier) {
        Row(verticalAlignment = Alignment.CenterVertically) {
            Text(
                text = entry.contents,
                modifier = Modifier
                    .padding(16.dp)
                    .wrapContentSize()
            )

            Spacer(modifier = Modifier.weight(1f))

            Checkbox(
                checked = false,
                onCheckedChange = {},
                modifier = Modifier.padding(16.dp)
            )
        }
    }
}

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

شکل ۱. نتایج ترکیبی کنسول TraceSectionMetric و FrameTimingMetric برای یک طرح‌بندی مدرن Compose.

StartupTimingMetric ، FrameTimingMetric ، TraceSectionMetric و PowerMetric در ادامه به تفصیل پوشش داده شده‌اند. برای فهرست کامل معیارهای معیار موجود، به زیرکلاس‌های Metric در مرجع API مراجعه کنید.

معیار زمان‌بندی استارتاپ

StartupTimingMetric معیارهای زمان‌بندی راه‌اندازی برنامه را با مقادیر زیر ثبت می‌کند:

• timeToInitialDisplayMs : مدت زمان از زمانی که سیستم یک هدف راه‌اندازی (launch intent) دریافت می‌کند تا زمانی که اولین فریم از صفحه مقصد را رندر می‌کند.
• timeToFullDisplayMs : مدت زمان از زمانی که سیستم یک intent راه‌اندازی را دریافت می‌کند تا زمانی که برنامه با استفاده از مکانیسم‌های گزارش‌دهی داخلی پلتفرم، گزارش‌های کامل ترسیم‌شده را ارائه می‌دهد. این اندازه‌گیری با تکمیل رندر اولین فریم پس از - یا شامل - سیگنال کاملاً ترسیم‌شده متوقف می‌شود.

StartupTimingMetric مقادیر حداقل، میانه و حداکثر را از تکرارهای راه‌اندازی خروجی می‌دهد. برای ارزیابی بهبود راه‌اندازی، همیشه روی مقادیر میانه تمرکز کنید، زیرا آنها بهترین تخمین از زمان‌های معمول راه‌اندازی کاربر را ارائه می‌دهند.

در معماری Compose-first، سعی نکنید activity.reportFullyDrawn را به صورت دستی فراخوانی کنید. در عوض، از ابزارهای ناهمزمان Compose-safe مانند ReportDrawn ، ReportDrawnWhen یا ReportDrawnAfter درون composableهای صفحه نمایش خود استفاده کنید تا به طور خودکار به Macrobenchmark سیگنال دهند که رندر داده‌های شبکه async یا حالت‌های پیچیده رابط کاربری شما به پایان رسیده است.

برای اطلاعات بیشتر در مورد تجزیه و تحلیل و بهینه‌سازی عملکرد راه‌اندازی، به زمان راه‌اندازی برنامه مراجعه کنید.

فریم تایمینگ متریک

FrameTimingMetric اطلاعات زمان‌بندی دقیق را از فریم‌های تولید شده توسط یک سفر معیار، مانند پیمایش یک لیست یا یک انیمیشن طرح‌بندی پیچیده رابط کاربری، ثبت می‌کند و مقادیر تشخیصی زیر را خروجی می‌دهد:

• frameOverrunMs : مدت زمانی که یک فریم مشخص، مهلت خود را از دست می‌دهد. اعداد مثبت نشان دهنده‌ی یک فریم از دست رفته همراه با پرش یا وقفه‌ی قابل مشاهده هستند. اعداد منفی نشان دهنده‌ی این هستند که یک فریم چقدر سریع‌تر نسبت به مهلت سخت‌افزار زیرسیستم تکمیل شده است. توجه: این معیار فقط در اندروید ۱۲ (سطح API ۳۱) و بالاتر در دسترس است.
• frameDurationCpuMs : مدت زمانی که فریم به طور فعال در CPU در هر دو نخ رابط کاربری اصلی برنامه و نخ رندرسازی (Compose RenderThread تولید می‌شود.

این اندازه‌گیری‌ها در توزیعی از صدک‌های ۵۰، ۹۰، ۹۵ و ۹۹ جمع‌آوری شده‌اند:

frameDurationCpuMs P50 3.5, P90 6.0, P95 6.4, P99 11.0
frameOverrunMs P50 -11.6, P90 -7.2, P95 -7.1, P99 -1.2

هنگام بهینه‌سازی سلسله مراتب طرح‌بندی Jetpack Compose، به فریم‌های با بدترین عملکرد خود (مرزهای P95 و P99) نگاه کنید. اگر frameOverrunMs در صدک‌های بالا به اعداد صحیح مثبت افزایش یابد، نشان می‌دهد که ترکیب‌های مجدد، نخ اصلی را در طول انیمیشن‌های پیمایش سنگین متوقف می‌کنند.

برای درک عمیق‌تر در مورد شناسایی و حل مشکل فریم‌های کند، به عملکرد Jetpack Compose مراجعه کنید.

ردیابی بخش متریک

تجربی: این کلاس آزمایشی است.

TraceSectionMetric تعداد دفعاتی که یک بخش ردیابی خاص رخ می‌دهد و مقدار مطلق زمان لازم برای اجرا را ثبت می‌کند. برای ردیابی زمان، حداقل، میانه و حداکثر زمان را بر حسب میلی‌ثانیه خروجی می‌دهد. بخش ردیابی هدف یا توسط فراخوانی تابع trace(sectionName) یا مرزهای بلوک سطح پایین‌تر بین Trace.beginSection(sectionName) و Trace.endSection() یا انواع ناهمزمان آنها تعریف می‌شود.

EntryRowCustomTraceCount min 20.0, median 28.0, max 50.0
EntryRowCustomTraceSumMs min 34.9, median 44.4, max 66.6

به طور پیش‌فرض، این معیار فقط بخش‌های ردیابی را که مستقیماً از فایل‌های باینری بسته برنامه شما کامپایل شده‌اند، خروجی می‌دهد. برای شامل کردن فرآیندهایی که از خارج از مرز بسته برنامه شما سرچشمه می‌گیرند، ویژگی targetPackageOnly = false قرار دهید.

هنگام کار با Jetpack Compose Runtime Tracing، می‌توانید با فعال کردن ردیابی ترکیب ، توابع قابل ترکیب مجزا را در نمودارهای ردیابی سیستم خود بدون نوشتن بسته‌های ردیابی دستی، نمایش دهید.

اگرچه اضافه کردن وابستگی androidx.compose.runtime:runtime-tracing به برنامه‌ی هدف شما برای ردیابی دستی پروفایلر کافی است، اما ثبت این ردیابی‌ها به صورت برنامه‌نویسی شده در یک اجرای Macrobenchmark نیاز به پیکربندی اضافی در ماژول بنچمارک شما دارد.

برای دستورالعمل‌های کامل راه‌اندازی، به ضبط ردیابی با Jetpack Macrobenchmark مراجعه کنید.

پاورمتریک

تجربی: این کلاس آزمایشی است.

PowerMetric تغییر در توان یا انرژی را در طول مدت اجرای Macrobenchmark شما ثبت می‌کند. هر دسته انتخاب شده به اجزای سخت‌افزاری قابل اندازه‌گیری خود تجزیه می‌شود، در حالی که دسته‌های انتخاب نشده در یک سطل "انتخاب نشده" گروه‌بندی می‌شوند.

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

این معیار، دو اندازه‌گیری برای هر دسته ارائه می‌دهد:

• power<category>Uw : میزان توان مصرفی در طول مدت آزمایش شما در این دسته (برحسب میکرووات).
• energy<category>Uws : کل مقدار انرژی منتقل شده در واحد زمان برای مدت زمان آزمایش شما در این دسته (اندازه‌گیری شده بر حسب میکرووات-ثانیه).

دسته بندی ها شامل موارد زیر است:

• CPU
• DISPLAY
• GPU
• GPS
• MEMORY
• MACHINE_LEARNING
• NETWORK
• UNCATEGORIZED

در برخی از دسته‌ها، مانند CPU ، ممکن است جدا کردن کار انجام شده توسط سایر فرآیندها از کار انجام شده توسط برنامه خودتان دشوار باشد. برای به حداقل رساندن تداخل، برنامه‌ها و حساب‌های غیرضروری را حذف یا محدود کنید.

powerCategoryCpuUw min 300.2, median 346.1, max 519.6
powerCategoryDisplayUw min 319.8, median 325.8, max 329.7
powerCategoryGpuUw min 18.8, median 23.3, max 36.9
powerCategoryNetworkUw min 97.3, median 123.3, max 681.3
powerTotalUw min 1234.8, median 1316.6, max 2112.4
powerUnselectedUw       min  483.3,  median  512.6,  max  561.7

تحلیل زیرسیستم‌های اصلی

PowerMetric تغییر در توان یا انرژی را در طول مدت آزمایش شما برای دسته‌های توان ارائه شده ثبت می‌کند. هر دسته‌ای که انتخاب می‌کنید به زیرمولفه‌های قابل اندازه‌گیری خود تجزیه می‌شود و دسته‌های انتخاب نشده به معیار "انتخاب نشده" اضافه می‌شوند.

خروجی‌های ترمینال به پیکربندی مورد نظر شما نگاشت می‌شوند:

• powerCategoryCpuUw : میزان مصرف برق توسط CPU در طول مدت آزمایش شما.
• powerCategoryGpuUw : میزان مصرف برق توسط پردازنده گرافیکی (GPU) در طول مدت آزمایش شما.
• powerUnselectedUw : مجموع توان مصرفی توسط تمام دسته‌های سخت‌افزاری موجود که صراحتاً در نقشه مقداردهی اولیه شما درخواست نشده‌اند .

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

منابع اضافی

محتوا را مشاهده می‌کند

• ثبت معیارهای Macrobenchmark (بازدیدها)

{% کلمه به کلمه %} {% فعل کمکی %}