এই নথিতে সমস্যা নির্ণয়ে সাহায্য করার জন্য সর্বোত্তম অনুশীলন এবং সমস্যা সমাধানের পদক্ষেপগুলি প্রদান করা হয়েছে এবং নিশ্চিত করা হয়েছে যে আপনার বেসলাইন প্রোফাইলগুলি সর্বাধিক সুবিধা প্রদানের জন্য সঠিকভাবে কাজ করে।
বিল্ড সংক্রান্ত সমস্যা
যদি আপনি Now in Android নমুনা অ্যাপে বেসলাইন প্রোফাইলের উদাহরণটি অনুলিপি করে থাকেন, তাহলে বেসলাইন প্রোফাইল টাস্কের সময় আপনি পরীক্ষামূলক ব্যর্থতার সম্মুখীন হতে পারেন যেখানে বলা হয়েছে যে পরীক্ষাগুলি কোনও এমুলেটরে চালানো যাবে না:
./gradlew assembleDemoRelease
Starting a Gradle Daemon (subsequent builds will be faster)
Calculating task graph as no configuration cache is available for tasks: assembleDemoRelease
Type-safe project accessors is an incubating feature.
> Task :benchmarks:pixel6Api33DemoNonMinifiedReleaseAndroidTest
Starting 14 tests on pixel6Api33
com.google.samples.apps.nowinandroid.foryou.ScrollForYouFeedBenchmark > scrollFeedCompilationNone[pixel6Api33] FAILED
java.lang.AssertionError: ERRORS (not suppressed): EMULATOR
WARNINGS (suppressed):
...
অ্যান্ড্রয়েডে Now বেসলাইন প্রোফাইল জেনারেশনের জন্য একটি গ্রেডল-পরিচালিত ডিভাইস ব্যবহার করে, তাই এই ব্যর্থতাগুলি ঘটে। ব্যর্থতাগুলি প্রত্যাশিত, কারণ সাধারণত আপনার কোনও এমুলেটরে পারফরম্যান্স বেঞ্চমার্ক চালানো উচিত নয়। তবে, যেহেতু আপনি বেসলাইন প্রোফাইল তৈরি করার সময় পারফরম্যান্স মেট্রিক্স সংগ্রহ করছেন না, তাই সুবিধার জন্য আপনি এমুলেটরগুলিতে বেসলাইন প্রোফাইল সংগ্রহ চালাতে পারেন। এমুলেটর দিয়ে বেসলাইন প্রোফাইল ব্যবহার করতে, কমান্ড-লাইন থেকে বিল্ড এবং ইনস্টলেশন সম্পাদন করুন এবং বেসলাইন প্রোফাইল নিয়মগুলি সক্ষম করার জন্য একটি আর্গুমেন্ট সেট করুন:
installDemoRelease -Pandroid.testInstrumentationRunnerArguments.androidx.benchmark.enabledRules=BaselineProfile
বিকল্পভাবে, আপনি Run > Edit Configurations নির্বাচন করে এমুলেটরগুলিতে Baseline Profiles সক্ষম করতে Android Studio-তে একটি কাস্টম রান কনফিগারেশন তৈরি করতে পারেন:

প্রোফাইল ইনস্টলেশন এবং অ্যাপ্লিকেশন যাচাই করুন
আপনি যে APK অথবা Android অ্যাপ বান্ডেল (AAB) পরীক্ষা করছেন তা Baseline Profiles সহ একটি বিল্ড ভেরিয়েন্ট থেকে কিনা তা পরীক্ষা করতে, নিম্নলিখিতগুলি করুন:
- অ্যান্ড্রয়েড স্টুডিওতে, বিল্ড > বিশ্লেষণ APK নির্বাচন করুন।
- আপনার AAB অথবা APK খুলুন।
baseline.profফাইলটি বিদ্যমান কিনা তা নিশ্চিত করুন:- যদি আপনি একটি AAB পরিদর্শন করেন, তাহলে প্রোফাইলটি
/BUNDLE-METADATA/com.android.tools.build.profiles/baseline.profএ রয়েছে। যদি আপনি একটি APK পরিদর্শন করেন, তাহলে প্রোফাইলটি
/assets/dexopt/baseline.profএ রয়েছে।এই ফাইলের উপস্থিতি সঠিক বিল্ড কনফিগারেশনের প্রথম লক্ষণ। যদি এটি অনুপস্থিত থাকে, তাহলে এর অর্থ হল ইনস্টলের সময় অ্যান্ড্রয়েড রানটাইম কোনও প্রাক-সংকলন নির্দেশাবলী পাবে না।

চিত্র ২. অ্যান্ড্রয়েড স্টুডিওতে APK অ্যানালাইজার ব্যবহার করে একটি বেসলাইন প্রোফাইল পরীক্ষা করুন।
- যদি আপনি একটি AAB পরিদর্শন করেন, তাহলে প্রোফাইলটি
অ্যাপটি চালানোর জন্য ডিভাইসে বেসলাইন প্রোফাইল কম্পাইল করতে হবে। যখন আপনি অ্যান্ড্রয়েড স্টুডিও বা গ্রেডল র্যাপার কমান্ড-লাইন টুল ব্যবহার করে নন-ডিবাগেবল বিল্ড ইনস্টল করেন, তখন ডিভাইসে কম্পাইলেশন স্বয়ংক্রিয়ভাবে হয়ে যায়। আপনি যদি গুগল প্লে স্টোর থেকে অ্যাপটি ইনস্টল করেন, তাহলে বেসলাইন প্রোফাইলগুলি ইনস্টলের সময় নয় বরং ব্যাকগ্রাউন্ড ডিভাইস আপডেটের সময় কম্পাইল করা হয়। যখন অ্যাপটি অন্যান্য টুল ব্যবহার করে ইনস্টল করা হয়, তখন জেটপ্যাক ProfileInstaller লাইব্রেরি পরবর্তী ব্যাকগ্রাউন্ড DEX অপ্টিমাইজেশন প্রক্রিয়ার সময় কম্পাইলেশনের জন্য প্রোফাইলগুলিকে সারিবদ্ধ করার জন্য দায়ী।
এইসব ক্ষেত্রে, যদি আপনি নিশ্চিত করতে চান যে আপনার Baseline Profiles ব্যবহার করা হচ্ছে, তাহলে আপনাকে Baseline Profiles জোর করে সংকলন করতে হতে পারে। ProfileVerifier আপনাকে প্রোফাইল ইনস্টলেশন এবং সংকলনের অবস্থা জিজ্ঞাসা করতে দেয়, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:
কোটলিন
private const val TAG = "MainActivity" class MainActivity : ComponentActivity() { ... override fun onResume() { super.onResume() lifecycleScope.launch { logCompilationStatus() } } private suspend fun logCompilationStatus() { withContext(Dispatchers.IO) { val status = ProfileVerifier.getCompilationStatusAsync().await() when (status.profileInstallResultCode) { RESULT_CODE_NO_PROFILE -> Log.d(TAG, "ProfileInstaller: Baseline Profile not found") RESULT_CODE_COMPILED_WITH_PROFILE -> Log.d(TAG, "ProfileInstaller: Compiled with profile") RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION -> Log.d(TAG, "ProfileInstaller: Enqueued for compilation") RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING -> Log.d(TAG, "ProfileInstaller: App was installed through Play store") RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST -> Log.d(TAG, "ProfileInstaller: PackageName not found") RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ -> Log.d(TAG, "ProfileInstaller: Cache file exists but cannot be read") RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE -> Log.d(TAG, "ProfileInstaller: Can't write cache file") RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION -> Log.d(TAG, "ProfileInstaller: Enqueued for compilation") else -> Log.d(TAG, "ProfileInstaller: Profile not compiled or enqueued") } } }
জাভা
public class MainActivity extends ComponentActivity { private static final String TAG = "MainActivity"; @Override protected void onResume() { super.onResume(); logCompilationStatus(); } private void logCompilationStatus() { ListeningExecutorService service = MoreExecutors.listeningDecorator( Executors.newSingleThreadExecutor()); ListenableFuture<ProfileVerifier.CompilationStatus> future = ProfileVerifier.getCompilationStatusAsync(); Futures.addCallback(future, new FutureCallback<>() { @Override public void onSuccess(CompilationStatus result) { int resultCode = result.getProfileInstallResultCode(); if (resultCode == RESULT_CODE_NO_PROFILE) { Log.d(TAG, "ProfileInstaller: Baseline Profile not found"); } else if (resultCode == RESULT_CODE_COMPILED_WITH_PROFILE) { Log.d(TAG, "ProfileInstaller: Compiled with profile"); } else if (resultCode == RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION) { Log.d(TAG, "ProfileInstaller: Enqueued for compilation"); } else if (resultCode == RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING) { Log.d(TAG, "ProfileInstaller: App was installed through Play store"); } else if (resultCode == RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST) { Log.d(TAG, "ProfileInstaller: PackageName not found"); } else if (resultCode == RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ) { Log.d(TAG, "ProfileInstaller: Cache file exists but cannot be read"); } else if (resultCode == RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE) { Log.d(TAG, "ProfileInstaller: Can't write cache file"); } else if (resultCode == RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION) { Log.d(TAG, "ProfileInstaller: Enqueued for compilation"); } else { Log.d(TAG, "ProfileInstaller: Profile not compiled or enqueued"); } } @Override public void onFailure(Throwable t) { Log.d(TAG, "ProfileInstaller: Error getting installation status: " + t.getMessage()); } }, service); } }
নিম্নলিখিত ফলাফল কোডগুলি কিছু সমস্যার কারণ সম্পর্কে ইঙ্গিত দেয়:
-
RESULT_CODE_COMPILED_WITH_PROFILE - প্রোফাইলটি ইনস্টল করা, কম্পাইল করা এবং অ্যাপটি চালানোর সময় ব্যবহার করা হয়। এটিই হল ফলাফল যা আপনি দেখতে চান।
-
RESULT_CODE_ERROR_NO_PROFILE_EMBEDDED - যে APK টি চালানো হচ্ছে তাতে কোনও প্রোফাইল খুঁজে পাওয়া যাচ্ছে না। যদি আপনি এই ত্রুটিটি দেখেন, তাহলে নিশ্চিত করুন যে আপনি এমন একটি বিল্ড ভেরিয়েন্ট ব্যবহার করছেন যাতে বেসলাইন প্রোফাইল অন্তর্ভুক্ত রয়েছে এবং APK তে একটি প্রোফাইল রয়েছে।
-
RESULT_CODE_NO_PROFILE - অ্যাপ স্টোর বা প্যাকেজ ম্যানেজারের মাধ্যমে অ্যাপটি ইনস্টল করার সময় এই অ্যাপের জন্য কোনও প্রোফাইল ইনস্টল করা হয়নি। এই ত্রুটি কোডের মূল কারণ হল
ProfileInstallerInitializerঅক্ষম থাকার কারণে প্রোফাইল ইনস্টলারটি চালানো হয়নি। মনে রাখবেন যে যখন এই ত্রুটিটি রিপোর্ট করা হয় তখনও অ্যাপ্লিকেশন APK-তে একটি এমবেডেড প্রোফাইল পাওয়া যায়। যখন একটি এমবেডেড প্রোফাইল পাওয়া যায় না, তখন ফেরত আসা ত্রুটি কোডটি হলRESULT_CODE_ERROR_NO_PROFILE_EMBEDDED। -
RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION - APK অথবা AAB-তে একটি প্রোফাইল পাওয়া যায় এবং কম্পাইলেশনের জন্য সারিবদ্ধ থাকে।
ProfileInstallerদ্বারা একটি প্রোফাইল ইনস্টল করা হলে, পরবর্তী সময়ে সিস্টেম দ্বারা ব্যাকগ্রাউন্ড DEX অপ্টিমাইজেশন চালানোর সময় এটি কম্পাইলেশনের জন্য সারিবদ্ধ থাকে। কম্পাইলেশন সম্পূর্ণ না হওয়া পর্যন্ত প্রোফাইলটি সক্রিয় থাকে না। কম্পাইলেশন সম্পূর্ণ না হওয়া পর্যন্ত আপনার বেসলাইন প্রোফাইলগুলিকে বেঞ্চমার্ক করার চেষ্টা করবেন না। আপনাকে জোর করে বেসলাইন প্রোফাইল সংকলন করতে হতে পারে। Android 9 (API 28) এবং উচ্চতর ভার্সন চালিত ডিভাইসগুলিতে Play Store বা প্যাকেজ ম্যানেজার থেকে অ্যাপ ইনস্টল করার সময় এই ত্রুটি ঘটবে না, কারণ কম্পাইলেশন ইনস্টলেশনের সময় সম্পন্ন হয়। -
RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING - একটি নন-ম্যাচিং প্রোফাইল ইনস্টল করা হয়েছে এবং অ্যাপটি এর সাথে কম্পাইল করা হয়েছে। এটি গুগল প্লে স্টোর বা প্যাকেজ ম্যানেজারের মাধ্যমে ইনস্টলেশনের ফলাফল। মনে রাখবেন যে এই ফলাফলটি
RESULT_CODE_COMPILED_WITH_PROFILEথেকে আলাদা কারণ নন-ম্যাচিং প্রোফাইলটি কেবলমাত্র প্রোফাইল এবং অ্যাপের মধ্যে ভাগ করা যেকোনো পদ্ধতি কম্পাইল করবে। প্রোফাইলটি প্রত্যাশার চেয়ে কার্যকরভাবে ছোট, এবং বেসলাইন প্রোফাইলে অন্তর্ভুক্ত পদ্ধতির চেয়ে কম পদ্ধতি কম্পাইল করা হবে। -
RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILE -
ProfileVerifierযাচাইয়ের ফলাফল ক্যাশে ফাইল লিখতে পারছে না। অ্যাপ ফোল্ডারের অনুমতিতে কোনও সমস্যা হওয়ার কারণে অথবা ডিভাইসে পর্যাপ্ত ফাঁকা ডিস্ক স্থান না থাকার কারণে এটি ঘটতে পারে। -
RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION - ProfileVerifier
is running on an unsupported API version of Android. ProfileVerifierশুধুমাত্র Android 9 (API লেভেল 28) এবং উচ্চতর সংস্করণ সমর্থন করে। -
RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST - অ্যাপ প্যাকেজের জন্য
PackageManagerজিজ্ঞাসা করার সময় একটিPackageManager.NameNotFoundExceptionতৈরি হয়। এটি খুব কমই ঘটে। অ্যাপটি আনইনস্টল করে সবকিছু পুনরায় ইনস্টল করার চেষ্টা করুন। -
RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ - পূর্ববর্তী যাচাইকরণ ফলাফলের ক্যাশে ফাইলটি বিদ্যমান, কিন্তু এটি পড়া যাচ্ছে না। এটি খুব কমই ঘটবে। অ্যাপটি আনইনস্টল করে সবকিছু পুনরায় ইনস্টল করার চেষ্টা করুন।
প্রোডাকশনে ProfileVerifier ব্যবহার করুন
প্রোডাকশনে, আপনি প্রোফাইল স্ট্যাটাস নির্দেশ করে অ্যানালিটিক্স ইভেন্ট তৈরি করতে, যেমন Google Analytics for Firebase এর মতো অ্যানালিটিক্স-রিপোর্টিং লাইব্রেরির সাথে ProfileVerifier ব্যবহার করতে পারেন। উদাহরণস্বরূপ, যদি কোনও নতুন অ্যাপ সংস্করণ প্রকাশিত হয় যেখানে বেসলাইন প্রোফাইল নেই, তাহলে এটি আপনাকে দ্রুত সতর্ক করে।
বেসলাইন প্রোফাইলের জোরপূর্বক সংকলন
যদি আপনার বেসলাইন প্রোফাইলের সংকলনের অবস্থা RESULT_CODE_PROFILE_ENQUEUED_FOR_COMPILATION হয়, তাহলে আপনি adb ব্যবহার করে তাৎক্ষণিক সংকলন জোর করতে পারেন:
adb shell cmd package compile -r bg-dexopt PACKAGE_NAME
ProfileVerifier ছাড়াই বেসলাইন প্রোফাইল সংকলনের অবস্থা পরীক্ষা করুন
যদি আপনি ProfileVerifier ব্যবহার না করেন, তাহলে আপনি adb ব্যবহার করে সংকলনের অবস্থা পরীক্ষা করতে পারেন, যদিও এটি ProfileVerifier মতো গভীর অন্তর্দৃষ্টি দেয় না:
adb shell dumpsys package dexopt | grep -A 2 PACKAGE_NAME
adb ব্যবহার করলে নিচের মতো কিছু তৈরি হয়:
[com.google.samples.apps.nowinandroid.demo]
path: /data/app/~~dzJiGMKvp22vi2SsvfjkrQ==/com.google.samples.apps.nowinandroid.demo-7FR1sdJ8ZTy7eCLwAnn0Vg==/base.apk
arm64: [status=speed-profile] [reason=bg-dexopt] [primary-abi]
[location is /data/app/~~dzJiGMKvp22vi2SsvfjkrQ==/com.google.samples.apps.nowinandroid.demo-7FR1sdJ8ZTy7eCLwAnn0Vg==/oat/arm64/base.odex]
স্ট্যাটাস মান প্রোফাইল সংকলনের অবস্থা নির্দেশ করে এবং নিম্নলিখিত মানগুলির মধ্যে একটি:
| সংকলনের অবস্থা | অর্থ |
|---|---|
speed‑profile | একটি সংকলিত প্রোফাইল বিদ্যমান এবং ব্যবহার করা হচ্ছে। |
verify | কোন সংকলিত প্রোফাইল বিদ্যমান নেই। |
একটি verify অবস্থা মানে এই নয় যে APK বা AAB তে কোনও প্রোফাইল নেই, কারণ এটি পরবর্তী ব্যাকগ্রাউন্ড DEX অপ্টিমাইজেশন টাস্কের মাধ্যমে সংকলনের জন্য সারিবদ্ধ হতে পারে।
কারণ মানটি নির্দেশ করে যে প্রোফাইলের সংকলনটি কী ট্রিগার করে এবং এটি নিম্নলিখিত মানগুলির মধ্যে একটি:
| কারণ | অর্থ |
|---|---|
install‑dm | অ্যাপটি ইনস্টল করার সময় একটি বেসলাইন প্রোফাইল ম্যানুয়ালি বা গুগল প্লে দ্বারা সংকলিত হয়েছিল। |
bg‑dexopt | আপনার ডিভাইসটি নিষ্ক্রিয় থাকাকালীন একটি প্রোফাইল সংকলিত হয়েছিল। এটি একটি বেসলাইন প্রোফাইল হতে পারে, অথবা এটি অ্যাপ ব্যবহারের সময় সংগৃহীত একটি প্রোফাইল হতে পারে। |
cmdline | সংকলনটি adb ব্যবহার করে ট্রিগার করা হয়েছিল। এটি একটি বেসলাইন প্রোফাইল হতে পারে, অথবা এটি অ্যাপ ব্যবহারের সময় সংগৃহীত একটি প্রোফাইল হতে পারে। |
DEX এবং r8.json এ স্টার্টআপ প্রোফাইল অ্যাপ্লিকেশন যাচাই করুন
R8 দ্বারা বিল্ড টাইমে স্টার্টআপ প্রোফাইল নিয়ম ব্যবহার করা হয় আপনার DEX ফাইলগুলিতে ক্লাসের লেআউট অপ্টিমাইজ করার জন্য। এই বিল্ড-টাইম অপ্টিমাইজেশন বেসলাইন প্রোফাইল ( baseline.prof ) যেভাবে ব্যবহৃত হয় তার থেকে আলাদা, কারণ এগুলি APK বা AAB-এর মধ্যে প্যাকেজ করা হয় যাতে ART অন-ডিভাইস সংকলন করতে পারে। যেহেতু স্টার্টআপ প্রোফাইল নিয়মগুলি বিল্ড প্রক্রিয়ার সময়ই প্রয়োগ করা হয়, তাই আপনার APK বা AAB-এর মধ্যে পরিদর্শন করার জন্য আলাদা কোনও startup.prof ফাইল নেই। পরিবর্তে স্টার্টআপ প্রোফাইলের প্রভাব DEX ফাইল লেআউটে দৃশ্যমান।
r8.json দিয়ে DEX বিন্যাস পরীক্ষা করুন (AGP 8.8 বা উচ্চতর সংস্করণের জন্য প্রস্তাবিত)
Android Gradle Plugin (AGP) 8.8 বা উচ্চতর সংস্করণ ব্যবহার করে এমন প্রকল্পগুলির জন্য, আপনি জেনারেট করা r8.json ফাইলটি পরীক্ষা করে স্টার্টআপ প্রোফাইল প্রয়োগ করা হয়েছে কিনা তা যাচাই করতে পারেন। এই ফাইলটি আপনার AAB-এর মধ্যে প্যাকেজ করা আছে।
- আপনার AAB আর্কাইভ খুলুন এবং
r8.jsonফাইলটি সনাক্ত করুন। -
dexFilesঅ্যারের জন্য ফাইলটি অনুসন্ধান করুন, যা তৈরি হওয়া DEX ফাইলগুলির তালিকা করে। এমন একটি
dexFilesঅবজেক্ট খুঁজুন যাতে"startup": trueকী-মান জোড়া থাকে। এটি স্পষ্টভাবে ইঙ্গিত করে যে স্টার্টআপ প্রোফাইল নিয়মগুলি সেই নির্দিষ্ট DEX ফাইলের লেআউটটি অপ্টিমাইজ করার জন্য প্রয়োগ করা হয়েছিল।"dexFiles": [ { "checksum": "...", "startup": true // This flag confirms profile application to this DEX file }, // ... other DEX files ]
সকল AGP সংস্করণের জন্য DEX ব্যবস্থা পরীক্ষা করুন।
যদি আপনি 8.8 এর কম AGP ভার্সন ব্যবহার করেন, তাহলে আপনার স্টার্টআপ প্রোফাইল সঠিকভাবে প্রয়োগ করা হয়েছে কিনা তা যাচাই করার প্রাথমিক উপায় হল DEX ফাইলগুলি পরীক্ষা করা। আপনি যদি AGP 8.8 বা উচ্চতর ভার্সন ব্যবহার করেন এবং DEX লেআউটটি ম্যানুয়ালি পরীক্ষা করতে চান তবে আপনি এই পদ্ধতিটিও ব্যবহার করতে পারেন। উদাহরণস্বরূপ, যদি আপনি প্রত্যাশিত কর্মক্ষমতা উন্নতি দেখতে না পান। DEX বিন্যাসটি পরীক্ষা করতে, নিম্নলিখিতগুলি করুন:
- অ্যান্ড্রয়েড স্টুডিওতে Build > Analyze APK ব্যবহার করে আপনার AAB অথবা APK খুলুন।
- প্রথম DEX ফাইলে যান। উদাহরণস্বরূপ,
classes.dex। - এই DEX ফাইলের বিষয়বস্তু পরীক্ষা করুন। আপনার স্টার্টআপ প্রোফাইল ফাইলে (
startup-prof.txt) সংজ্ঞায়িত গুরুত্বপূর্ণ ক্লাস এবং পদ্ধতিগুলি এই প্রাথমিক DEX ফাইলে উপস্থিত আছে কিনা তা যাচাই করতে সক্ষম হওয়া উচিত। একটি সফল অ্যাপ্লিকেশনের অর্থ হল দ্রুত লোডিংয়ের জন্য এই স্টার্টআপ-সমালোচনামূলক উপাদানগুলিকে অগ্রাধিকার দেওয়া হয়।
কর্মক্ষমতা সমস্যা
এই বিভাগটি আপনার বেসলাইন প্রোফাইলগুলি সঠিকভাবে সংজ্ঞায়িত এবং বেঞ্চমার্ক করার জন্য কিছু সেরা অনুশীলন দেখায় যাতে সেগুলি থেকে সর্বাধিক সুবিধা পাওয়া যায়।
সঠিকভাবে স্টার্টআপ মেট্রিক্স বেঞ্চমার্ক করুন
আপনার স্টার্টআপ মেট্রিক্সগুলি যদি সুনির্দিষ্টভাবে সংজ্ঞায়িত করা হয় তবে আপনার বেসলাইন প্রোফাইলগুলি আরও কার্যকর হবে। দুটি মূল মেট্রিক্স হল টাইম টু ইনিশিয়াল ডিসপ্লে (TTID) এবং টাইম টু ফুল ডিসপ্লে (TTFD) ।
TTID হলো যখন অ্যাপটি তার প্রথম ফ্রেম আঁকে। এটি যতটা সম্ভব ছোট রাখা গুরুত্বপূর্ণ কারণ কিছু প্রদর্শন করলে ব্যবহারকারী বুঝতে পারবেন যে অ্যাপটি চলছে। এমনকি অ্যাপটি প্রতিক্রিয়াশীল তা দেখানোর জন্য আপনি একটি অনির্দিষ্ট অগ্রগতি নির্দেশকও প্রদর্শন করতে পারেন।
TTFD হলো সেই সময় যখন অ্যাপটির সাথে আসলেই ইন্টারঅ্যাক্ট করা যায়। ব্যবহারকারীদের হতাশা এড়াতে এটি যতটা সম্ভব ছোট রাখা গুরুত্বপূর্ণ। যদি আপনি সঠিকভাবে TTFD সিগন্যাল করেন, তাহলে আপনি সিস্টেমকে বলছেন যে TTFD-তে যাওয়ার পথে যে কোডটি চালানো হচ্ছে তা অ্যাপ স্টার্টআপের অংশ। ফলস্বরূপ, সিস্টেমটি প্রোফাইলে এই কোডটি রাখার সম্ভাবনা বেশি।
আপনার অ্যাপটিকে প্রতিক্রিয়াশীল করে তুলতে TTID এবং TTFD উভয়ের মান যতটা সম্ভব কম রাখুন।
সিস্টেমটি TTID সনাক্ত করতে, Logcat-এ এটি প্রদর্শন করতে এবং স্টার্টআপ বেঞ্চমার্কের অংশ হিসাবে এটি রিপোর্ট করতে সক্ষম। তবে, সিস্টেমটি TTFD নির্ধারণ করতে অক্ষম, এবং এটি সম্পূর্ণরূপে টানা ইন্টারেক্টিভ অবস্থায় পৌঁছালে রিপোর্ট করার দায়িত্ব অ্যাপের। আপনি reportFullyDrawn() অথবা Jetpack Compose ব্যবহার করলে ReportDrawn কল করে এটি করতে পারেন। যদি আপনার একাধিক ব্যাকগ্রাউন্ড টাস্ক থাকে যা অ্যাপটিকে সম্পূর্ণরূপে টানা হিসাবে বিবেচনা করার আগে সম্পূর্ণ করতে হয়, তাহলে আপনি FullyDrawnReporter ব্যবহার করতে পারেন, যেমনটি Improve startup timeing accuracy -এ বর্ণিত হয়েছে।
লাইব্রেরি প্রোফাইল এবং কাস্টম প্রোফাইল
প্রোফাইলের প্রভাব বেঞ্চমার্ক করার সময়, আপনার অ্যাপের প্রোফাইলের সুবিধাগুলি লাইব্রেরি, যেমন জেটপ্যাক লাইব্রেরি দ্বারা প্রদত্ত প্রোফাইল থেকে আলাদা করা কঠিন হতে পারে। যখন আপনি আপনার APK তৈরি করেন তখন Android Gradle প্লাগইন আপনার কাস্টম প্রোফাইলের পাশাপাশি লাইব্রেরি নির্ভরতাগুলিতে থাকা যেকোনো প্রোফাইল যোগ করে। এটি সামগ্রিক কর্মক্ষমতা অপ্টিমাইজ করার জন্য ভাল, এবং আপনার রিলিজ বিল্ডগুলির জন্য সুপারিশ করা হয়। তবে, আপনার কাস্টম প্রোফাইল থেকে কতটা অতিরিক্ত কর্মক্ষমতা লাভ হয় তা পরিমাপ করা কঠিন করে তোলে।
আপনার কাস্টম প্রোফাইল দ্বারা প্রদত্ত অতিরিক্ত অপ্টিমাইজেশন ম্যানুয়ালি দেখার একটি দ্রুত উপায় হল এটি সরিয়ে আপনার বেঞ্চমার্কগুলি চালানো। তারপর এটি প্রতিস্থাপন করুন এবং আপনার বেঞ্চমার্কগুলি আবার চালান। দুটির তুলনা করলে আপনি কেবল লাইব্রেরি প্রোফাইল দ্বারা প্রদত্ত অপ্টিমাইজেশনগুলি এবং লাইব্রেরি প্রোফাইলগুলি এবং আপনার কাস্টম প্রোফাইলটি দেখতে পাবেন।
প্রোফাইল তুলনা করার একটি স্বয়ংক্রিয় উপায় হল একটি নতুন বিল্ড ভেরিয়েন্ট তৈরি করা যাতে শুধুমাত্র লাইব্রেরি প্রোফাইল থাকবে, আপনার কাস্টম প্রোফাইল থাকবে না। এই ভেরিয়েন্ট থেকে বেঞ্চমার্কগুলি রিলিজ ভেরিয়েন্টের সাথে তুলনা করুন যেখানে লাইব্রেরি প্রোফাইল এবং আপনার কাস্টম প্রোফাইল উভয়ই থাকবে। নিম্নলিখিত উদাহরণটি দেখায় যে কীভাবে শুধুমাত্র লাইব্রেরি প্রোফাইল থাকবে এমন ভেরিয়েন্ট সেট আপ করবেন। আপনার প্রোফাইল কনজিউমার মডিউলে releaseWithoutCustomProfile নামে একটি নতুন ভেরিয়েন্ট যোগ করুন, যা সাধারণত আপনার অ্যাপ মডিউল:
কোটলিন
android { ... buildTypes { ... // Release build with only library profiles. create("releaseWithoutCustomProfile") { initWith(release) } ... } ... } ... dependencies { ... // Remove the baselineProfile dependency. // baselineProfile(project(":baselineprofile")) } baselineProfile { variants { create("release") { from(project(":baselineprofile")) } } }
খাঁজকাটা
android { ... buildTypes { ... // Release build with only library profiles. releaseWithoutCustomProfile { initWith(release) } ... } ... } ... dependencies { ... // Remove the baselineProfile dependency. // baselineProfile ':baselineprofile"' } baselineProfile { variants { release { from(project(":baselineprofile")) } } }
পূর্ববর্তী কোড উদাহরণটি সমস্ত ভেরিয়েন্ট থেকে baselineProfile নির্ভরতা সরিয়ে দেয় এবং এটি শুধুমাত্র release ভেরিয়েন্টের জন্য বেছে বেছে প্রয়োগ করে। প্রোফাইল প্রযোজক মডিউলের উপর নির্ভরতা সরিয়ে ফেলা হলেও লাইব্রেরি প্রোফাইলগুলি এখনও যোগ করা হচ্ছে তা বিপরীত মনে হতে পারে। তবে, এই মডিউলটি কেবল আপনার কাস্টম প্রোফাইল তৈরি করার জন্য দায়ী। অ্যান্ড্রয়েড গ্রেডল প্লাগইনটি এখনও সমস্ত ভেরিয়েন্টের জন্য চলছে এবং লাইব্রেরি প্রোফাইল অন্তর্ভুক্ত করার জন্য দায়ী।
আপনাকে প্রোফাইল জেনারেটর মডিউলে নতুন ভেরিয়েন্টটিও যুক্ত করতে হবে। এই উদাহরণে প্রযোজক মডিউলটির নাম :baselineprofile ।
কোটলিন
android { ... buildTypes { ... // Release build with only library profiles. create("releaseWithoutCustomProfile") {} ... } ... }
খাঁজকাটা
android { ... buildTypes { ... // Release build with only library profiles. releaseWithoutCustomProfile {} ... } ... }
যখন আপনি Android Studio থেকে বেঞ্চমার্ক চালান, তখন শুধুমাত্র লাইব্রেরি প্রোফাইলের সাথে কর্মক্ষমতা পরিমাপ করার জন্য একটি releaseWithoutCustomProfile ভেরিয়েন্ট নির্বাচন করুন, অথবা লাইব্রেরি এবং কাস্টম প্রোফাইলের সাথে কর্মক্ষমতা পরিমাপ করার জন্য একটি release ভেরিয়েন্ট নির্বাচন করুন।
I/O-বাউন্ড অ্যাপ স্টার্টআপ এড়িয়ে চলুন
যদি আপনার অ্যাপটি স্টার্টআপের সময় প্রচুর I/O কল বা নেটওয়ার্ক কল করে, তাহলে এটি অ্যাপ স্টার্টআপের সময় এবং আপনার স্টার্টআপ বেঞ্চমার্কিংয়ের নির্ভুলতা উভয়কেই নেতিবাচকভাবে প্রভাবিত করতে পারে। এই ভারী কলগুলিতে অনির্দিষ্ট সময় লাগতে পারে যা সময়ের সাথে সাথে এবং এমনকি একই বেঞ্চমার্কের পুনরাবৃত্তির মধ্যেও পরিবর্তিত হতে পারে। I/O কলগুলি সাধারণত নেটওয়ার্ক কলের চেয়ে ভালো, কারণ পরবর্তী কলগুলি ডিভাইসের বাইরের কারণগুলির দ্বারা এবং ডিভাইসের মধ্যেই প্রভাবিত হতে পারে। স্টার্টআপের সময় নেটওয়ার্ক কল এড়িয়ে চলুন। যেখানে একটি বা অন্যটি ব্যবহার করা অনিবার্য, সেখানে I/O ব্যবহার করুন।
আমরা আপনার অ্যাপ আর্কিটেকচার সাপোর্ট অ্যাপ স্টার্টআপকে নেটওয়ার্ক বা I/O কল ছাড়াই করার পরামর্শ দিচ্ছি, এমনকি যদি এটি শুধুমাত্র স্টার্টআপের বেঞ্চমার্কিং করার সময় ব্যবহার করা হয়। এটি আপনার বেঞ্চমার্কের বিভিন্ন পুনরাবৃত্তির মধ্যে সর্বনিম্ন সম্ভাব্য পরিবর্তনশীলতা নিশ্চিত করতে সাহায্য করে।
যদি আপনার অ্যাপটি Hilt ব্যবহার করে, তাহলে আপনি Microbenchmark এবং Hilt- এ বেঞ্চমার্কিং করার সময় নকল I/O-বাউন্ড বাস্তবায়ন প্রদান করতে পারেন।
সমস্ত গুরুত্বপূর্ণ ব্যবহারকারীর ভ্রমণের তথ্য কভার করুন
আপনার বেসলাইন প্রোফাইল জেনারেশনের সমস্ত গুরুত্বপূর্ণ ব্যবহারকারীর ভ্রমণগুলি সঠিকভাবে কভার করা গুরুত্বপূর্ণ। যে কোনও ব্যবহারকারীর ভ্রমণ যা কভার করা হয়নি তা বেসলাইন প্রোফাইল দ্বারা উন্নত করা হবে না। সবচেয়ে কার্যকর বেসলাইন প্রোফাইলগুলির মধ্যে সমস্ত সাধারণ স্টার্টআপ ব্যবহারকারীর ভ্রমণের পাশাপাশি স্ক্রলিং তালিকার মতো কর্মক্ষমতা-সংবেদনশীল ইন-অ্যাপ ব্যবহারকারীর ভ্রমণ অন্তর্ভুক্ত থাকে।
A/B পরীক্ষার কম্পাইল-টাইম প্রোফাইল পরিবর্তন
যেহেতু স্টার্টআপ এবং বেসলাইন প্রোফাইলগুলি একটি কম্পাইল-টাইম অপ্টিমাইজেশন, তাই গুগল প্লে স্টোর ব্যবহার করে সরাসরি A/B পরীক্ষা করে বিভিন্ন APK প্রোডাকশন রিলিজের জন্য সাধারণত সমর্থিত নয়। প্রোডাকশন-সদৃশ পরিবেশে প্রভাব মূল্যায়ন করতে, নিম্নলিখিত পদ্ধতিগুলি বিবেচনা করুন:
অফ-সাইকেল রিলিজ : আপনার ব্যবহারকারী বেসের একটি ছোট শতাংশের জন্য একটি অফ-সাইকেল রিলিজ আপলোড করুন যাতে শুধুমাত্র প্রোফাইল পরিবর্তন অন্তর্ভুক্ত থাকে। এটি আপনাকে পারফরম্যান্সের পার্থক্যের উপর বাস্তব-বিশ্বের মেট্রিক্স সংগ্রহ করতে দেয়।
স্থানীয় বেঞ্চমার্কিং : প্রয়োগ করা প্রোফাইল সহ এবং ছাড়াই স্থানীয়ভাবে আপনার অ্যাপটিকে বেঞ্চমার্ক করুন। তবে, মনে রাখবেন যে স্থানীয় বেঞ্চমার্কিং আপনাকে প্রোফাইলের জন্য সেরা পরিস্থিতি দেখায়, কারণ এতে উৎপাদন ডিভাইসগুলিতে উপস্থিত ART থেকে ক্লাউড প্রোফাইলের প্রভাব অন্তর্ভুক্ত নয়।