इस दस्तावेज़ में, समस्याओं का पता लगाने और यह पक्का करने के लिए सबसे सही तरीके बताए गए हैं कि आपकी बेसलाइन प्रोफ़ाइलें सही तरीके से काम करें, ताकि आपको ज़्यादा से ज़्यादा फ़ायदा मिल सके.
बिल्ड से जुड़ी समस्याएं
अगर आपने 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):
...
ऐसा इसलिए होता है, क्योंकि Android में Now, बेसलाइन प्रोफ़ाइल जनरेट करने के लिए, Gradle से मैनेज किए जा रहे डिवाइस का इस्तेमाल करता है. गड़बड़ियां होना आम बात है, क्योंकि आम तौर पर, एमुलेटर पर परफ़ॉर्मेंस के मानदंड नहीं चलाए जाने चाहिए. हालांकि, बेसलाइन प्रोफ़ाइल जनरेट करते समय परफ़ॉर्मेंस मेट्रिक इकट्ठा नहीं की जाती हैं. इसलिए, सुविधा के लिए एमुलेटर पर बेसलाइन प्रोफ़ाइल कलेक्शन चलाया जा सकता है. किसी एमुलेटर के साथ बेसलाइन प्रोफ़ाइलों का इस्तेमाल करने के लिए, कमांड-लाइन से बिल्ड और इंस्टॉलेशन करें. साथ ही, बेसलाइन प्रोफ़ाइल के नियमों को चालू करने के लिए, एक आर्ग्युमेंट सेट करें:
installDemoRelease -Pandroid.testInstrumentationRunnerArguments.androidx.benchmark.enabledRules=BaselineProfile
इसके अलावा, Android Studio में कस्टम रन कॉन्फ़िगरेशन बनाया जा सकता है, ताकि एमुलेटर पर बेसलाइन प्रोफ़ाइलें चालू की जा सकें. इसके लिए, रन करें > कॉन्फ़िगरेशन में बदलाव करें को चुनें:
इंस्टॉलेशन संबंधी समस्याएं
देखें कि जिस APK या AAB की जांच की जा रही है वह ऐसे बिल्ड वैरिएंट का है जिसमें बेसलाइन प्रोफ़ाइलें शामिल हैं:
- Android Studio में, बिल्ड करें > APK का विश्लेषण करें को चुनें.
- अपना AAB या APK खोलें.
- अगर किसी AAB की जांच की जा रही है, तो प्रोफ़ाइल
/BUNDLE-METADATA/com.android.tools.build.profiles/baseline.profपर है. अगर किसी APK की जांच की जा रही है, तो प्रोफ़ाइल/assets/dexopt/baseline.profपर होती है.
बेसलाइन प्रोफ़ाइलों को उस डिवाइस पर कंपाइल करना ज़रूरी है जिस पर ऐप्लिकेशन चल रहा है. Play Store, Android Studio या Gradle Wrapper कमांड लाइन टूल का इस्तेमाल करके ऐप्लिकेशन इंस्टॉल करने पर, डिवाइस पर कंपाइलेशन अपने-आप हो जाता है. जब ऐप्लिकेशन को अन्य टूल का इस्तेमाल करके इंस्टॉल किया जाता है, तो बैकग्राउंड में DEX को ऑप्टिमाइज़ करने की अगली प्रोसेस के दौरान, प्रोफ़ाइलों को कंपाइल करने के लिए सूची में जोड़ने की ज़िम्मेदारी, Jetpack ProfileInstaller लाइब्रेरी की होती है. ऐसे मामलों में, अगर आपको यह पक्का करना है कि आपकी आधारभूत प्रोफ़ाइलों का इस्तेमाल किया जा रहा है, तो आपको आधारभूत प्रोफ़ाइलों को ज़बरदस्ती कंपाइल करना पड़ सकता है. ProfileVerifier की मदद से, प्रोफ़ाइल के इंस्टॉलेशन और कंपाइलेशन की स्थिति के बारे में क्वेरी की जा सकती है. इसका उदाहरण यहां दिया गया है:
Kotlin
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") } } }
Java
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 (एपीआई 28) और उसके बाद के वर्शन पर चलने वाले डिवाइसों पर, ऐप स्टोर या पैकेज मैनेजर से इंस्टॉल किया जाएगा. ऐसा इसलिए, क्योंकि इंस्टॉलेशन के दौरान कंपाइलेशन किया जाता है. RESULT_CODE_COMPILED_WITH_PROFILE_NON_MATCHING- ऐसी प्रोफ़ाइल इंस्टॉल की गई है जो मेल नहीं खाती और ऐप्लिकेशन को उसी के साथ कंपाइल किया गया है.
यह Google Play Store या पैकेज मैनेजर से इंस्टॉल करने पर दिखता है.
ध्यान दें कि यह नतीजा
RESULT_CODE_COMPILED_WITH_PROFILEसे अलग है, क्योंकि मैच न करने वाली प्रोफ़ाइल सिर्फ़ उन तरीकों को कंपाइल करेगी जो अब भी प्रोफ़ाइल और ऐप्लिकेशन के बीच शेयर किए जाते हैं. प्रोफ़ाइल, उम्मीद से कम होती है और बेसलाइन प्रोफ़ाइल में शामिल किए गए तरीकों की तुलना में कम तरीकों को कंपाइल किया जाएगा. RESULT_CODE_ERROR_CANT_WRITE_PROFILE_VERIFICATION_RESULT_CACHE_FILEProfileVerifier, पुष्टि के नतीजे की कैश मेमोरी फ़ाइल नहीं लिख सकता. ऐसा, ऐप्लिकेशन फ़ोल्डर की अनुमतियों में कोई गड़बड़ी होने या डिवाइस में डिस्क काफ़ी स्टोरेज न होने की वजह से हो सकता है.RESULT_CODE_ERROR_UNSUPPORTED_API_VERSION- ProfileVerifier
is running on an unsupported API version of Android. ProfileVerifierसिर्फ़ Android 9 (एपीआई लेवल 28) और उसके बाद के वर्शन पर काम करता है. RESULT_CODE_ERROR_PACKAGE_NAME_DOES_NOT_EXIST- ऐप्लिकेशन पैकेज के लिए
PackageManagerसे क्वेरी करने पर,PackageManager.NameNotFoundExceptionदिखता है. ऐसा बहुत ही कम होता है. ऐप्लिकेशन को अनइंस्टॉल करके, फिर से इंस्टॉल करें. RESULT_CODE_ERROR_CACHE_FILE_EXISTS_BUT_CANNOT_BE_READ- पुष्टि के पिछले नतीजे की कैश मेमोरी फ़ाइल मौजूद है, लेकिन उसे पढ़ा नहीं जा सकता. ऐसा बहुत कम होता है. ऐप्लिकेशन को अनइंस्टॉल करके, फिर से इंस्टॉल करें.
प्रोडक्शन में ProfileVerifier का इस्तेमाल करना
प्रोडक्शन में, ProfileVerifier का इस्तेमाल Firebase के लिए Google Analytics जैसी आंकड़ों की रिपोर्टिंग वाली लाइब्रेरी के साथ किया जा सकता है. इससे, प्रोफ़ाइल की स्थिति दिखाने वाले आंकड़ों के इवेंट जनरेट किए जा सकते हैं. उदाहरण के लिए, अगर ऐप्लिकेशन का कोई नया वर्शन रिलीज़ किया जाता है और उसमें बेसलाइन प्रोफ़ाइलें शामिल नहीं होती हैं, तो आपको तुरंत इसकी सूचना मिलती है.
बेसलाइन प्रोफ़ाइलों को ज़बरदस्ती कंपाइल करना
अगर आपकी बेसलाइन प्रोफ़ाइलों का कंपाइलेशन स्टेटस 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
|
ऐप्लिकेशन इंस्टॉल होने पर, बेसलाइन प्रोफ़ाइल को मैन्युअल तरीके से या Google Play ने कंपाइल किया हो. |
bg‑dexopt
|
आपका डिवाइस कुछ समय के लिए बंद होने पर, प्रोफ़ाइल को कंपाइल किया गया था. यह कोई बेसलाइन प्रोफ़ाइल हो सकती है या ऐप्लिकेशन के इस्तेमाल के दौरान इकट्ठा की गई प्रोफ़ाइल हो सकती है. |
cmdline
|
कंपाइलेशन को adb का इस्तेमाल करके ट्रिगर किया गया था. यह कोई बेसलाइन प्रोफ़ाइल हो सकती है या ऐप्लिकेशन के इस्तेमाल के दौरान इकट्ठा की गई प्रोफ़ाइल हो सकती है. |
परफ़ॉर्मेंस से जुड़ी समस्याएं
इस सेक्शन में, बेसलाइन प्रोफ़ाइलों से ज़्यादा से ज़्यादा फ़ायदा पाने के लिए, उन्हें सही तरीके से तय करने और उनके आधार पर तुलना करने के कुछ सबसे सही तरीके बताए गए हैं.
स्टार्टअप मेट्रिक का सही तरीके से बेंचमार्क करना
अगर आपकी स्टार्टअप मेट्रिक अच्छी तरह से तय की गई हैं, तो आपकी बेसलाइन प्रोफ़ाइलें ज़्यादा असरदार होंगी. दो मुख्य मेट्रिक, शुरुआती डिसप्ले में लगने वाला समय (टीटीआईडी) और पूरी तरह से डिसप्ले होने में लगने वाला समय (टीटीएफ़डी) हैं.
TTID तब होता है, जब ऐप्लिकेशन अपना पहला फ़्रेम दिखाता है. इसे जितना हो सके उतना छोटा रखना ज़रूरी है, क्योंकि कुछ दिखाने से उपयोगकर्ता को पता चलता है कि ऐप्लिकेशन चल रहा है. ऐप्लिकेशन के काम करने की जानकारी देने के लिए, प्रोग्रेस इंडिकेटर भी दिखाया जा सकता है.
TTFD तब होता है, जब ऐप्लिकेशन के साथ असल में इंटरैक्ट किया जा सकता है. उपयोगकर्ताओं को परेशानी से बचाने के लिए, इसे जितना हो सके उतना छोटा रखना ज़रूरी है. अगर आपने TTFD को सही तरीके से सिग्नल दिया है, तो इसका मतलब है कि आपने सिस्टम को यह बताया है कि TTFD के दौरान चलने वाला कोड, ऐप्लिकेशन के स्टार्टअप का हिस्सा है. इस वजह से, सिस्टम इस कोड को प्रोफ़ाइल में डालने की ज़्यादा संभावना रखता है.
अपने ऐप्लिकेशन को रिस्पॉन्सिव बनाने के लिए, TTID और TTFD, दोनों को जितनी हो सके उतनी कम रखें.
सिस्टम, TTID का पता लगा सकता है, उसे Logcat में दिखा सकता है, और उसे स्टार्टअप मानदंडों के हिस्से के तौर पर रिपोर्ट कर सकता है. हालांकि, सिस्टम टीटीएफ़डी का पता नहीं लगा सकता. साथ ही, ऐप्लिकेशन के पूरी तरह से इंटरैक्टिव होने पर, इसकी सूचना देना ऐप्लिकेशन की ज़िम्मेदारी है. ऐसा करने के लिए, reportFullyDrawn() को कॉल करें. अगर Jetpack Compose का इस्तेमाल किया जा रहा है, तो ReportDrawn को कॉल करें. अगर आपके ऐप्लिकेशन में एक से ज़्यादा बैकग्राउंड टास्क हैं और ऐप्लिकेशन को पूरी तरह से लोड होने में इन सभी टास्क को पूरा करना ज़रूरी है, तो ऐप्लिकेशन के खुलने में लगने वाले समय को सटीक बनाने का तरीका में बताए गए तरीके के हिसाब से, FullyDrawnReporter का इस्तेमाल किया जा सकता है.
लाइब्रेरी प्रोफ़ाइलें और कस्टम प्रोफ़ाइलें
प्रोफ़ाइलों के असर का आकलन करते समय, अपने ऐप्लिकेशन की प्रोफ़ाइलों के फ़ायदों को, लाइब्रेरी से मिलने वाली प्रोफ़ाइलों से अलग करना मुश्किल हो सकता है. जैसे, Jetpack लाइब्रेरी. APK बनाते समय, Android Gradle प्लग इन लाइब्रेरी डिपेंडेंसी के साथ-साथ आपकी कस्टम प्रोफ़ाइल में भी सभी प्रोफ़ाइलें जोड़ता है. यह पूरी परफ़ॉर्मेंस को ऑप्टिमाइज़ करने के लिए अच्छा है. साथ ही, रिलीज़ बिल्ड के लिए इसका सुझाव दिया जाता है. हालांकि, इससे यह मेज़र करना मुश्किल हो जाता है कि आपकी कस्टम प्रोफ़ाइल से परफ़ॉर्मेंस में कितनी बढ़ोतरी हुई है.
कस्टम प्रोफ़ाइल से मिलने वाले अतिरिक्त ऑप्टिमाइज़ेशन को मैन्युअल तरीके से देखने का एक आसान तरीका है कि आप उसे हटा दें और अपने बेंचमार्क चलाएं. इसके बाद, इसे बदलें और फिर से अपने बेंचमार्क चलाएं. दोनों की तुलना करने पर, आपको लाइब्रेरी प्रोफ़ाइलों के साथ-साथ अपनी कस्टम प्रोफ़ाइल से मिलने वाले ऑप्टिमाइज़ेशन दिखेंगे.
प्रोफ़ाइलों की तुलना करने का एक ऐसा तरीका है जिसे अपने-आप चालू किया जा सकता है. इसके लिए, एक नया बिल्ड वैरिएंट बनाएं. इसमें सिर्फ़ लाइब्रेरी प्रोफ़ाइलें होनी चाहिए, आपकी कस्टम प्रोफ़ाइल नहीं. इस वैरिएंट के बेंचमार्क की तुलना, रिलीज़ वैरिएंट से करें. इसमें लाइब्रेरी प्रोफ़ाइलें और आपकी कस्टम प्रोफ़ाइलें, दोनों शामिल होती हैं. इस उदाहरण में, सिर्फ़ लाइब्रेरी प्रोफ़ाइलों वाले वैरिएंट को सेट अप करने का तरीका बताया गया है. अपनी प्रोफ़ाइल के उपभोक्ता मॉड्यूल में, releaseWithoutCustomProfile नाम का नया वैरिएंट जोड़ें. आम तौर पर, यह आपका ऐप्लिकेशन मॉड्यूल होता है:
Kotlin
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")) } } }
Groovy
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 वैरिएंट पर लागू किया गया है. ऐसा लग सकता है कि प्रोफ़ाइल प्रोड्यूसर मॉड्यूल पर निर्भरता हटाने के बाद भी, लाइब्रेरी प्रोफ़ाइलें जोड़ी जा रही हैं. हालांकि, यह मॉड्यूल सिर्फ़ आपकी कस्टम प्रोफ़ाइल जनरेट करने के लिए ज़िम्मेदार है. Android Gradle प्लग इन अब भी सभी वैरिएंट के लिए काम कर रहा है. साथ ही, लाइब्रेरी प्रोफ़ाइलों को शामिल करने की ज़िम्मेदारी भी इसकी है.
आपको प्रोफ़ाइल जनरेटर मॉड्यूल में भी नया वैरिएंट जोड़ना होगा. इस उदाहरण में, प्रोड्यूसर मॉड्यूल का नाम :baselineprofile है.
Kotlin
android { ... buildTypes { ... // Release build with only library profiles. create("releaseWithoutCustomProfile") {} ... } ... }
Groovy
android { ... buildTypes { ... // Release build with only library profiles. releaseWithoutCustomProfile {} ... } ... }
Android Studio से बेंचमार्क चलाते समय, सिर्फ़ लाइब्रेरी प्रोफ़ाइलों की मदद से परफ़ॉर्मेंस मेज़र करने के लिए कोई releaseWithoutCustomProfile वैरिएंट चुनें. इसके अलावा, लाइब्रेरी और कस्टम प्रोफ़ाइलों की मदद से परफ़ॉर्मेंस मेज़र करने के लिए कोई release वैरिएंट चुनें.
I/O-बाउंड ऐप्लिकेशन के शुरू होने से बचना
अगर आपका ऐप्लिकेशन स्टार्टअप के दौरान बहुत सारे I/O कॉल या नेटवर्क कॉल कर रहा है, तो इससे ऐप्लिकेशन के स्टार्टअप होने में लगने वाले समय और स्टार्टअप की परफ़ॉर्मेंस का आकलन करने के तरीके पर बुरा असर पड़ सकता है. इन हेवीवॉग कॉल में, समय का पता नहीं चलता. यह समय, समय के साथ और एक ही मानदंड के बीच भी अलग-अलग हो सकता है. आम तौर पर, I/O कॉल, नेटवर्क कॉल से बेहतर होते हैं. ऐसा इसलिए, क्योंकि नेटवर्क कॉल पर डिवाइस के बाहरी और डिवाइस के अंदर मौजूद फ़ैक्टर का असर पड़ सकता है. डिवाइस के चालू होने के दौरान, नेटवर्क कॉल से बचें. अगर किसी एक का इस्तेमाल करना ज़रूरी है, तो I/O का इस्तेमाल करें.
हमारा सुझाव है कि आप अपने ऐप्लिकेशन के आर्किटेक्चर को इस तरह से बनाएं कि वह नेटवर्क या I/O कॉल के बिना ऐप्लिकेशन को शुरू कर सके. भले ही, इसका इस्तेमाल सिर्फ़ ऐप्लिकेशन के शुरू होने की परफ़ॉर्मेंस का आकलन करने के लिए किया जाए. इससे यह पक्का करने में मदद मिलती है कि आपके बेंचमार्क के अलग-अलग वर्शन के बीच कम से कम अंतर हो.
अगर आपका ऐप्लिकेशन Hilt का इस्तेमाल करता है, तो माइक्रो-बेंचमार्क और Hilt में बेंचमार्क करते समय, I/O-बाउंड के नकली लागू किए गए वर्शन दिए जा सकते हैं.
उपयोगकर्ता की सभी गतिविधियों को कवर करना
यह ज़रूरी है कि आप अपनी आधारभूत प्रोफ़ाइल जनरेशन में, उपयोगकर्ता की सभी अहम गतिविधियों को सटीक तरीके से शामिल करें. जिन उपयोगकर्ता गतिविधियों को कवर नहीं किया गया है उनमें बेसलाइन प्रोफ़ाइलों से सुधार नहीं होगा. सबसे असरदार बेसलाइन प्रोफ़ाइलों में, ऐप्लिकेशन शुरू करने के दौरान उपयोगकर्ता की सभी सामान्य गतिविधियां शामिल होती हैं. साथ ही, इनमें परफ़ॉर्मेंस पर असर डालने वाली इन-ऐप्लिकेशन गतिविधियां भी शामिल होती हैं, जैसे कि स्क्रोल करने वाली सूचियां.