توصیه میکنیم از Jetpack Macrobenchmark برای آزمایش عملکرد یک برنامه زمانی که نمایههای خط پایه فعال هستند، استفاده کنید و سپس آن نتایج را با معیاری با نمایههای پایه غیرفعال مقایسه کنید. با این رویکرد، میتوانید زمان راهاندازی برنامه را اندازهگیری کنید - هم زمان تا نمایش اولیه و هم کامل - یا عملکرد رندر زمان اجرا را اندازهگیری کنید تا ببینید آیا فریمهای تولید شده میتوانند باعث jank شوند یا خیر.
ماکرو بنچمارک ها به شما امکان می دهند با استفاده از CompilationMode
API کامپایل پیش اندازه گیری را کنترل کنید. از مقادیر مختلف CompilationMode
برای مقایسه عملکرد با حالت های مختلف کامپایل استفاده کنید. قطعه کد زیر نحوه استفاده از پارامتر CompilationMode
را برای اندازه گیری مزایای Baseline Profiles نشان می دهد:
@RunWith(AndroidJUnit4ClassRunner::class) class ColdStartupBenchmark { @get:Rule val benchmarkRule = MacrobenchmarkRule() // No ahead-of-time (AOT) compilation at all. Represents performance of a // fresh install on a user's device if you don't enable Baseline Profiles— // generally the worst case performance. @Test fun startupNoCompilation() = startup(CompilationMode.None()) // Partial pre-compilation with Baseline Profiles. Represents performance of // a fresh install on a user's device. @Test fun startupPartialWithBaselineProfiles() = startup(CompilationMode.Partial(baselineProfileMode = BaselineProfileMode.Require)) // Partial pre-compilation with some just-in-time (JIT) compilation. // Represents performance after some app usage. @Test fun startupPartialCompilation() = startup( CompilationMode.Partial( baselineProfileMode = BaselineProfileMode.Disable, warmupIteration = 3 ) ) // Full pre-compilation. Generally not representative of real user // experience, but can yield more stable performance metrics by removing // noise from JIT compilation within benchmark runs. @Test fun startupFullCompilation() = startup(CompilationMode.Full()) private fun startup(compilationMode: CompilationMode) = benchmarkRule.measureRepeated( packageName = "com.example.macrobenchmark.target", metrics = listOf(StartupTimingMetric()), compilationMode = compilationMode, iterations = 10, startupMode = StartupMode.COLD, setupBlock = { pressHome() } ) { // Waits for the first rendered frame, which represents time to initial display. startActivityAndWait() // Waits for content to be visible, which represents time to fully drawn. device.wait(Until.hasObject(By.res("my-content")), 5_000) } }
در اسکرین شات زیر، میتوانید نتایج را مستقیماً در برنامه Android Studio برای Now in Android که روی Google Pixel 7 اجرا میشود، مشاهده کنید. نتایج نشان میدهد که راهاندازی برنامه در هنگام استفاده از نمایههای خط پایه ( 229.0 میلیثانیه ) سریعترین سرعت را در مقایسه با بدون کامپایل ( 324.8 ) دارد. اماس ).
در حالی که مثال قبلی نتایج راهاندازی برنامه را نشان میدهد که با StartupTimingMetric
گرفته شده است، معیارهای مهم دیگری مانند FrameTimingMetric
وجود دارد که ارزش در نظر گرفتن دارد. برای کسب اطلاعات بیشتر در مورد همه انواع معیارها، به معیارهای اندازه گیری Macrobenchmark Capture مراجعه کنید.
زمان نمایش کامل
مثال قبلی زمان نمایش اولیه (TTID) را اندازه گیری می کند، که زمان صرف شده توسط برنامه برای تولید اولین فریم است. با این حال، این لزوماً نشاندهنده زمانی نیست که کاربر بتواند با برنامه شما تعامل برقرار کند. متریک زمان برای نمایش کامل (TTFD) در اندازه گیری و بهینه سازی مسیرهای کد لازم برای داشتن یک وضعیت برنامه کاملاً قابل استفاده مفیدتر است.
ما بهینه سازی را برای TTID و TTFD توصیه می کنیم، زیرا هر دو مهم هستند. TTID پایین به کاربر کمک می کند تا ببیند برنامه واقعاً در حال راه اندازی است. کوتاه نگه داشتن TTFD برای اطمینان از اینکه کاربر می تواند به سرعت با برنامه تعامل داشته باشد، مهم است.
برای استراتژیهای مربوط به گزارشدهی زمانی که رابط کاربری برنامه کاملاً ترسیم شده است، به بهبود دقت زمانبندی راهاندازی مراجعه کنید.
{% کلمه به کلمه %}برای شما توصیه می شود
- توجه: وقتی جاوا اسکریپت خاموش است، متن پیوند نمایش داده می شود
- [نوشتن یک ماکرو بنچمارک][11]
- [گرفتن معیارهای ماکرو بنچمارک][12]
- [تحلیل و بهینهسازی راهاندازی برنامه {:#app-startup-analysis-optimization}][13]