الملفات الشخصية الأساسية المرجعية باستخدام مكتبة مقاييس الأداء المجمّعة
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
ننصح باستخدام Jetpack Macrobenchmark لاختبار أداء التطبيق عند تفعيل "ملفات تعريف الخط الأساس"، ثم مقارنة هذه النتائج بمقياس أداء مع إيقاف "ملفات تعريف الخط الأساس". باستخدام هذا الأسلوب، يمكنك قياس وقت بدء تشغيل التطبيق، أي الوقت اللازم لعرض الشاشة الأولية والشاشة الكاملة، أو أداء العرض أثناء وقت التشغيل لمعرفة ما إذا كان بإمكان اللقطات التي تم إنتاجها أن تتسبّب في حدوث تشوّش.
تتيح لك اختبارات الأداء الشامل التحكّم في عملية التجميع المسبق للقياس باستخدام واجهة برمجة التطبيقات
CompilationMode. استخدِم قيم CompilationMode مختلفة لمقارنة الأداء مع حالات تجميع مختلفة. يوضّح مقتطف الرمز التالي كيفية استخدام المَعلمة CompilationMode لقياس فائدة "ملفات تعريف خط الأساس":
@RunWith(AndroidJUnit4ClassRunner::class)classColdStartupBenchmark{@get:RulevalbenchmarkRule=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.@TestfunstartupNoCompilation()=startup(CompilationMode.None())// Partial pre-compilation with Baseline Profiles. Represents performance of// a fresh install on a user's device.@TestfunstartupPartialWithBaselineProfiles()=startup(CompilationMode.Partial(baselineProfileMode=BaselineProfileMode.Require))// Partial pre-compilation with some just-in-time (JIT) compilation.// Represents performance after some app usage.@TestfunstartupPartialCompilation()=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.@TestfunstartupFullCompilation()=startup(CompilationMode.Full())privatefunstartup(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" لتطبيق نموذج Now in Android الذي تم تشغيله على هاتف Google Pixel 7. توضّح النتائج أنّ بدء تشغيل التطبيق يكون أسرع عند استخدام "ملفات Baseline Profile" (229.0 ملي ثانية) مقارنةً بعدم إجراء عملية تجميع (324.8 ملي ثانية).
الشكل 1. نتائج ColdStartupBenchmark
عرض وقت العرض الأوّلي بدون تجميع (324 ملي ثانية)، والتجميع الكامل
(315 ملي ثانية)، والتجميع الجزئي (312 ملي ثانية)، وملفات Baseline Profiles
(229 ملي ثانية).
في حين يعرض المثال السابق نتائج بدء تشغيل التطبيق التي تم تسجيلها باستخدام
StartupTimingMetric، هناك مقاييس مهمة أخرى يجب أخذها في الاعتبار،
مثل FrameTimingMetric. لمزيد من المعلومات عن جميع أنواع المقاييس، يُرجى الاطّلاع على تسجيل مقاييس Macrobenchmark.
الوقت اللازم للعرض بملء الشاشة
يقيس المثال السابق الوقت المستغرَق للعرض الأولي (TTID)، وهو الوقت الذي يستغرقه التطبيق لإنتاج إطاره الأول. ومع ذلك، لا يعكس هذا المقياس بالضرورة الوقت الذي يمكن للمستخدم أن يبدأ فيه التفاعل مع تطبيقك، بل إنّ مقياس وقت العرض الكامل (TTFD) أكثر فائدة في قياس مسارات الرموز اللازمة للوصول إلى حالة تطبيق قابلة للاستخدام بالكامل وتحسينها.
ننصحك بتحسين كلّ من TTID وTTFD، لأنّ كليهما مهمّان. يساعد وقت TTID المنخفض المستخدم في التأكّد من أنّ التطبيق يتم تشغيله بالفعل. من المهم الحفاظ على قيمة TTFD منخفضة لضمان تفاعل المستخدم مع التطبيق بسرعة.
للاطّلاع على استراتيجيات حول إعداد التقارير عند اكتمال عرض واجهة مستخدم التطبيق، يمكنك الاطّلاع على تحسين دقة توقيت بدء التشغيل.
اقتراحات مخصصة لك
ملاحظة: يتم عرض نص الرابط عندما تكون JavaScript غير مفعّلة
[كتابة اختبار Macrobenchmark][11]
[تسجيل مقاييس Macrobenchmark][12]
[تحليل عملية بدء تشغيل التطبيق وتحسينها {:#app-startup-analysis-optimization}][13]
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ Java وOpenJDK هما علامتان تجاريتان مسجَّلتان لشركة Oracle و/أو الشركات التابعة لها.
تاريخ التعديل الأخير: 2025-08-27 (حسب التوقيت العالمي المتفَّق عليه)
[[["يسهُل فهم المحتوى.","easyToUnderstand","thumb-up"],["ساعَدني المحتوى في حلّ مشكلتي.","solvedMyProblem","thumb-up"],["غير ذلك","otherUp","thumb-up"]],[["لا يحتوي على المعلومات التي أحتاج إليها.","missingTheInformationINeed","thumb-down"],["الخطوات معقدة للغاية / كثيرة جدًا.","tooComplicatedTooManySteps","thumb-down"],["المحتوى قديم.","outOfDate","thumb-down"],["ثمة مشكلة في الترجمة.","translationIssue","thumb-down"],["مشكلة في العيّنات / التعليمات البرمجية","samplesCodeIssue","thumb-down"],["غير ذلك","otherDown","thumb-down"]],["تاريخ التعديل الأخير: 2025-08-27 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["We recommend using [Jetpack Macrobenchmark](/topic/performance/benchmarking/macrobenchmark-overview) to test how an app performs when\nBaseline Profiles are enabled, and then compare those results to a benchmark\nwith Baseline Profiles disabled. With this approach, you can measure app startup\ntime---both time to initial and full display---or runtime rendering\nperformance to see if the frames produced can cause jank.\n\nMacrobenchmarks let you control pre-measurement compilation using the\n[`CompilationMode`](/reference/androidx/benchmark/macro/CompilationMode) API. Use different `CompilationMode` values to compare\nperformance with different compilation states. The following code snippet shows\nhow to use the `CompilationMode` parameter to measure the benefit of Baseline\nProfiles: \n\n```kotlin\n@RunWith(AndroidJUnit4ClassRunner::class)\nclass ColdStartupBenchmark {\n @get:Rule\n val benchmarkRule = MacrobenchmarkRule()\n\n // No ahead-of-time (AOT) compilation at all. Represents performance of a\n // fresh install on a user's device if you don't enable Baseline Profiles---\n // generally the worst case performance.\n @Test\n fun startupNoCompilation() = startup(CompilationMode.None())\n\n // Partial pre-compilation with Baseline Profiles. Represents performance of\n // a fresh install on a user's device.\n @Test\n fun startupPartialWithBaselineProfiles() =\n startup(CompilationMode.Partial(baselineProfileMode = BaselineProfileMode.Require))\n\n // Partial pre-compilation with some just-in-time (JIT) compilation.\n // Represents performance after some app usage.\n @Test\n fun startupPartialCompilation() = startup(\n CompilationMode.Partial(\n baselineProfileMode = BaselineProfileMode.Disable,\n warmupIteration = 3\n )\n )\n\n // Full pre-compilation. Generally not representative of real user\n // experience, but can yield more stable performance metrics by removing\n // noise from JIT compilation within benchmark runs.\n @Test\n fun startupFullCompilation() = startup(CompilationMode.Full())\n\n private fun startup(compilationMode: CompilationMode) = benchmarkRule.measureRepeated(\n packageName = \"com.example.macrobenchmark.target\",\n metrics = listOf(StartupTimingMetric()),\n compilationMode = compilationMode,\n iterations = 10,\n startupMode = StartupMode.COLD,\n setupBlock = {\n pressHome()\n }\n ) {\n // Waits for the first rendered frame, which represents time to initial display.\n startActivityAndWait()\n\n // Waits for content to be visible, which represents time to fully drawn.\n device.wait(Until.hasObject(By.res(\"my-content\")), 5_000)\n }\n}\n```\n| **Caution:** Run the benchmarks on a physical device to measure real world performance. Measuring performance on an Android emulator likely provides incorrect results, because resources are shared with its hosting machine.\n\nIn the following screenshot, you can see the results directly in Android Studio\nfor the [Now in Android sample](https://goo.gle/nia) app ran on Google Pixel 7. The\nresults show that app startup is fastest when using Baseline Profiles\n(**229.0ms** ) in contrast with no compilation (**324.8ms**).\n**Figure 1.** Results of `ColdStartupBenchmark` showing time to initial display for no compilation (324ms), full compilation (315ms), partial compilation (312ms), and Baseline Profiles (229ms). **Tip:** You can also retrieve the results as a JSON file to parse them as part of your CI pipeline. For more information, see [Benchmarking in CI](/topic/performance/benchmarking/benchmarking-in-ci).\n\nWhile the previous example shows app startup results captured with\n[`StartupTimingMetric`](/reference/androidx/benchmark/macro/StartupTimingMetric), there are other important metrics worth considering,\nsuch as [`FrameTimingMetric`](/reference/androidx/benchmark/macro/FrameTimingMetric). For more information about all the types of\nmetrics, see [Capture Macrobenchmark metrics](/topic/performance/benchmarking/macrobenchmark-metrics).\n\nTime to full display\n\nThe previous example measures the [time to initial display](/topic/performance/vitals/launch-time#time-initial) (TTID), which is\nthe time taken by the app to produce its first frame. However, this doesn't\nnecessarily reflect the time until the user can start interacting with your app.\nThe [time to full display](/topic/performance/vitals/launch-time#time-full) (TTFD) metric is more useful in measuring and\noptimizing the code paths necessary to have a fully useable app state.\n\nWe recommend optimizing for both TTID and TTFD, as both are important. A low\nTTID helps the user see that the app is actually launching. Keeping the TTFD\nshort is important to help ensure that the user can interact with the app\nquickly.\n\nFor strategies on reporting when the app UI is fully drawn, see [Improve\nstartup timing accuracy](/topic/performance/benchmarking/macrobenchmark-metrics#startup-accuracy).\n\nRecommended for you\n\n- Note: link text is displayed when JavaScript is off\n- \\[Write a Macrobenchmark\\]\\[11\\]\n- \\[Capture Macrobenchmark metrics\\]\\[12\\]\n- \\[App startup analysis and optimization {:#app-startup-analysis-optimization}\\]\\[13\\]"]]