বেসলাইন প্রোফাইল চালু থাকলে অ্যাপ কেমন পারফর্ম করে তা পরীক্ষা করতে আমরা Jetpack Macrobenchmark ব্যবহার করার সাজেশন দিই এবং তারপর বেসলাইন প্রোফাইল বন্ধ থাকলে বেঞ্চমার্কের সাথে সেই ফলাফল তুলনা করুন। এই পদ্ধতির মাধ্যমে, আপনি অ্যাপ স্টার্টআপের সময়—প্রাথমিক ও সম্পূর্ণ ডিসপ্লে—অথবা রানটাইম রেন্ডারিং পারফর্ম্যান্স পরিমাপ করতে পারবেন, যাতে ফ্রেমের কারণে জ্যাঙ্ক হচ্ছে কিনা তা দেখতে পারেন।
Macrobenchmarks আপনাকে
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"} } } }
নিচের স্ক্রিনশটে, আপনি সরাসরি Android Studio-তে ফলাফল দেখতে পাবেন যা Google Pixel 7-এ চলা Now in Android স্যাম্পেল অ্যাপের জন্য। ফলাফল থেকে দেখা যায় যে, কোনও কম্পাইলেশন না থাকার (৩২৪.৮ms) তুলনায় বেসলাইন প্রোফাইল (২২৯.০ms) ব্যবহার করলে অ্যাপ সবচেয়ে দ্রুত চালু হয়।
ColdStartupBenchmark-এর ফলাফল
কোনও কম্পাইলেশন (৩২৪ মিলি সেকেন্ড), সম্পূর্ণ কম্পাইলেশন
(৩১৫ মিলি সেকেন্ড), আংশিক কম্পাইলেশন (৩১২ মিলি সেকেন্ড) এবং বেসলাইন প্রোফাইল
(২২৯ মিলি সেকেন্ড)-এর জন্য প্রাথমিক ডিসপ্লেতে সময় দেখাচ্ছে।আগের উদাহরণে StartupTimingMetric-এর মাধ্যমে ক্যাপচার করা অ্যাপ স্টার্টআপের ফলাফল দেখানো হলেও,
FrameTimingMetric-এর মতো অন্যান্য গুরুত্বপূর্ণ মেট্রিকও বিবেচনা করা উচিত। সব ধরনের মেট্রিক সম্পর্কে আরও জানতে, ম্যাক্রোবেঞ্চমার্ক মেট্রিক ক্যাপচার করুন দেখুন।
ফুল ডিসপ্লেতে দেখার সময়
আগের উদাহরণে প্রাথমিক ডিসপ্লেতে সময় (TTID) পরিমাপ করা হয়, যা হল অ্যাপের প্রথম ফ্রেম তৈরি করতে যে সময় লাগে। তবে, ব্যবহারকারী আপনার অ্যাপের সাথে ইন্টার্যাক্ট করা শুরু করতে পারবেন কিনা তা এর থেকে বোঝা যায় না। অ্যাপের অবস্থা সম্পূর্ণভাবে ব্যবহারযোগ্য করার জন্য প্রয়োজনীয় কোড পাথ পরিমাপ ও অপ্টিমাইজ করার ক্ষেত্রে সম্পূর্ণ ডিসপ্লে করার সময় (TTFD) মেট্রিক আরও বেশি উপযোগী।
আমরা TTID এবং TTFD, দুটির জন্যই অপ্টিমাইজ করার সাজেশন দিই, কারণ দুটিই গুরুত্বপূর্ণ। কম TTID ব্যবহারকারীকে বুঝতে সাহায্য করে যে অ্যাপটি আসলে চালু হচ্ছে। ব্যবহারকারী যাতে অ্যাপের সাথে দ্রুত ইন্টার্যাক্ট করতে পারেন তা নিশ্চিত করার জন্য TTFD কম রাখা গুরুত্বপূর্ণ।
অ্যাপ UI সম্পূর্ণভাবে ড্র করা হলে, রিপোর্টিং সংক্রান্ত স্ট্র্যাটেজির জন্য, স্টার্টআপ টাইমিংয়ের নির্ভুলতা উন্নত করুন দেখুন।
আপনার জন্য সাজেস্ট করা হয়েছে
- মনে রাখবেন: জাভাস্ক্রিপ্ট বন্ধ থাকলে লিঙ্ক টেক্সট দেখানো হয়
- [Write a Macrobenchmark][11]
- [Capture Macrobenchmark metrics][12]
- UI Automator-এর সাহায্যে অটোমেটেড টেস্ট লিখুন
- [অ্যাপ স্টার্টআপ বিশ্লেষণ ও অপ্টিমাইজেশন {:#app-startup-analysis-optimization}][14]