ম্যাক্রোবেঞ্চমার্ক লাইব্রেরি সহ বেঞ্চমার্ক বেসলাইন প্রোফাইল

বেসলাইন প্রোফাইল চালু থাকা অবস্থায় একটি অ্যাপ কেমন পারফর্ম করে তা পরীক্ষা করার জন্য আমরা Jetpack Macrobenchmark ব্যবহার করার পরামর্শ দিই, এবং তারপর সেই ফলাফলগুলোকে বেসলাইন প্রোফাইল বন্ধ থাকা অবস্থার বেঞ্চমার্কের সাথে তুলনা করতে বলি। এই পদ্ধতির মাধ্যমে, আপনি অ্যাপ চালু হওয়ার সময়—অর্থাৎ প্রাথমিক এবং সম্পূর্ণ প্রদর্শনের সময়—অথবা রানটাইম রেন্ডারিং পারফরম্যান্স পরিমাপ করতে পারবেন, এবং দেখতে পারবেন যে উৎপাদিত ফ্রেমগুলো জ্যাঙ্ক (jank) সৃষ্টি করতে পারে কিনা।

ম্যাক্রোবেঞ্চমার্ক আপনাকে CompilationMode API ব্যবহার করে পরিমাপ-পূর্ববর্তী কম্পাইলেশন নিয়ন্ত্রণ করতে দেয়। বিভিন্ন কম্পাইলেশন অবস্থার সাথে পারফরম্যান্স তুলনা করতে বিভিন্ন CompilationMode মান ব্যবহার করুন। নিম্নলিখিত কোড স্নিপেটটি দেখায় কিভাবে বেসলাইন প্রোফাইলের সুবিধা পরিমাপ করতে CompilationMode প্যারামিটারটি ব্যবহার করতে হয়:

@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()
        }
    ) {
        uiAutomator {
            startApp(packageName)
            onElement(5_000) { viewIdResourceName == "my-content"}
        }
    }
}

নিচের স্ক্রিনশটে, আপনি গুগল পিক্সেল ৭-এ চালানো ‘ Now in Android’ স্যাম্পল অ্যাপটির ফলাফল সরাসরি অ্যান্ড্রয়েড স্টুডিওতে দেখতে পাচ্ছেন। ফলাফল থেকে দেখা যায় যে, কোনো কম্পাইলেশন ছাড়া ( ৩২৪.৮ মিলিসেকেন্ড ) অ্যাপটি চালু হওয়ার তুলনায় বেসলাইন প্রোফাইল ব্যবহার করলে ( ২২৯.০ মিলিসেকেন্ড ) এটি সবচেয়ে দ্রুত চালু হয়।

যদিও পূর্ববর্তী উদাহরণটি StartupTimingMetric দিয়ে সংগৃহীত অ্যাপ স্টার্টআপের ফলাফল দেখাচ্ছে, FrameTimingMetric মতো আরও কিছু গুরুত্বপূর্ণ মেট্রিক রয়েছে যা বিবেচনা করার মতো। সব ধরনের মেট্রিক সম্পর্কে আরও তথ্যের জন্য, Capture Macrobenchmark metrics দেখুন।

সম্পূর্ণ প্রদর্শনে সময়

পূর্ববর্তী উদাহরণটি টাইম টু ইনিশিয়াল ডিসপ্লে (TTID) পরিমাপ করে, যা হলো অ্যাপটির প্রথম ফ্রেম তৈরি করতে নেওয়া সময়। তবে, এটি ব্যবহারকারী আপনার অ্যাপের সাথে ইন্টারঅ্যাক্ট করা শুরু করার আগ পর্যন্ত সময়কে আবশ্যিকভাবে প্রতিফলিত করে না। একটি সম্পূর্ণ ব্যবহারযোগ্য অ্যাপ স্টেট পাওয়ার জন্য প্রয়োজনীয় কোড পাথগুলো পরিমাপ ও অপ্টিমাইজ করার ক্ষেত্রে টাইম টু ফুল ডিসপ্লে (TTFD) মেট্রিকটি আরও বেশি উপযোগী।

আমরা TTID এবং TTFD উভয়কেই অপ্টিমাইজ করার পরামর্শ দিই, কারণ উভয়ই গুরুত্বপূর্ণ। একটি কম TTID ব্যবহারকারীকে বুঝতে সাহায্য করে যে অ্যাপটি আসলেই চালু হচ্ছে। TTFD কম রাখাটা জরুরি, যাতে ব্যবহারকারী দ্রুত অ্যাপটির সাথে ইন্টারঅ্যাক্ট করতে পারেন।

অ্যাপের UI সম্পূর্ণরূপে আঁকা হলে কীভাবে রিপোর্ট করতে হয়, সেই কৌশল জানতে “স্টার্টআপ টাইমিংয়ের নির্ভুলতা উন্নত করুন” দেখুন।