लिखें और मेट्रिक देखें की तुलना करें

Jetpack Compose की मदद से, यूज़र इंटरफ़ेस (यूआई) को तेज़ी से डेवलप किया जा सकता है. साथ ही, Android डेवलपमेंट को बेहतर बनाया जा सकता है. हालांकि, इस बात का ध्यान रखें कि किसी मौजूदा ऐप्लिकेशन में Compose को जोड़ने से, ऐप्लिकेशन के APK साइज़, बिल्ड, और रनटाइम परफ़ॉर्मेंस जैसी मेट्रिक पर क्या असर पड़ सकता है.

APK का साइज़ और उसे बनाने में लगने वाला समय

इस सेक्शन में, APK के साइज़ और बिल्ड टाइम पर पड़ने वाले असर के बारे में बताया गया है. इसके लिए, Sunflower सैंपल ऐप्लिकेशन का इस्तेमाल किया गया है. यह एक ऐसा ऐप्लिकेशन है जो व्यू पर आधारित ऐप्लिकेशन को Compose में माइग्रेट करने के सबसे सही तरीकों के बारे में बताता है.

APK का साइज़

अपने प्रोजेक्ट में लाइब्रेरी जोड़ने से, उसके APK का साइज़ बढ़ जाता है. यहां दिए गए नतीजे, हर प्रोजेक्ट के छोटे किए गए रिलीज़ APK के लिए हैं. इनमें संसाधन और कोड को छोटा करने की सुविधा चालू है. साथ ही, R8 के फ़ुल मोड का इस्तेमाल किया गया है और APK Analyzer का इस्तेमाल करके मेज़र किया गया है.

सिर्फ़ व्यू मिक्स किए गए व्यू और कंपोज़ सिर्फ़ ईमेल लिखने की अनुमति
डाउनलोड आकार 2,252 केबी 3,034 केबी 2,966 केबी

Sunflower में पहली बार Compose जोड़ने पर, APK का साइज़ 2,252 केबी से बढ़कर 3,034 केबी हो गया. यानी, इसमें 782 केबी की बढ़ोतरी हुई. जनरेट किए गए APK में, व्यू और कंपोज़ को मिलाकर बनाया गया यूज़र इंटरफ़ेस (यूआई) शामिल था. Sunflower में अतिरिक्त डिपेंडेंसी जोड़ी गई हैं. इसलिए, इस बढ़ोतरी की उम्मीद की जा सकती है.

इसके उलट, जब Sunflower को सिर्फ़ Compose का इस्तेमाल करने वाले ऐप्लिकेशन पर माइग्रेट किया गया, तब APK का साइज़ 3,034 केबी से घटकर 2,966 केबी हो गया. यानी, 68 केबी की कमी आई. यह कमी, इस्तेमाल न की जा रही व्यू डिपेंडेंसी को हटाने की वजह से हुई है. जैसे, AppCompat और ConstraintLayout.

बिल्ड टाइम

Compose को जोड़ने से, आपके ऐप्लिकेशन को बनाने में ज़्यादा समय लगता है. ऐसा इसलिए होता है, क्योंकि Compose कंपाइलर, आपके ऐप्लिकेशन में कंपोज़ेबल को प्रोसेस करता है. यहां दिए गए नतीजे, स्टैंडअलोन gradle-profiler टूल का इस्तेमाल करके पाए गए हैं. यह टूल, कई बार बिल्ड को एक्ज़ीक्यूट करता है, ताकि Sunflower के डीबग बिल्ड की अवधि के लिए, बिल्ड के औसत समय का पता लगाया जा सके:

gradle-profiler --benchmark --project-dir . :app:assembleDebug
सिर्फ़ व्यू मिक्स किए गए व्यू और कंपोज़ सिर्फ़ ईमेल लिखने की अनुमति
बिल्ड प्रोसेस में लगने वाला औसत समय 299.47 मि॰से॰ 399.09 मि॰से॰ 342.16 मि॰से॰

Sunflower में पहली बार Compose जोड़ने पर, औसत बिल्ड टाइम 299 मि॰से॰ से बढ़कर 399 मि॰से॰ हो गया. यह 100 मि॰से॰ की बढ़ोतरी है. यह समय, कंपोज़ कंपाइलर को प्रोजेक्ट में तय किए गए कंपोज़ कोड को बदलने के लिए अतिरिक्त टास्क करने की वजह से लगता है.

इसके उलट, जब Sunflower को Compose पर माइग्रेट कर दिया गया, तब औसत बिल्ड टाइम 342 मि॰से॰ हो गया. यह 57 मि॰से॰ की कमी है. बिल्ड टाइम में कमी आने की कई वजहें हो सकती हैं. जैसे, डेटा बाइंडिंग हटाना, kapt का इस्तेमाल करने वाली डिपेंडेंसी को KSP पर माइग्रेट करना, और कई डिपेंडेंसी को उनके नए वर्शन पर अपडेट करना.

खास जानकारी

Compose का इस्तेमाल करने से, आपके ऐप्लिकेशन का APK साइज़ बढ़ जाएगा. साथ ही, Compose कोड को कंपाइल करने की प्रोसेस की वजह से, आपके ऐप्लिकेशन को बनाने में लगने वाला समय भी बढ़ जाएगा. हालांकि, इन कमियों की तुलना Compose के फ़ायदों से की जानी चाहिए. खास तौर पर, Compose का इस्तेमाल करने पर डेवलपर की प्रॉडक्टिविटी में होने वाली बढ़ोतरी के बारे में. उदाहरण के लिए, Play Store की टीम ने पाया कि यूआई लिखने के लिए, बहुत कम कोड की ज़रूरत होती है. कभी-कभी यह 50%तक कम होता है. इससे प्रॉडक्टिविटी बढ़ती है और कोड को बनाए रखना आसान हो जाता है.

Adopt Compose for Teams में जाकर, अन्य केस स्टडी के बारे में पढ़ा जा सकता है.

रनटाइम परफ़ॉर्मेंस

इस सेक्शन में, Jetpack Compose में रनटाइम परफ़ॉर्मेंस से जुड़े विषयों के बारे में बताया गया है. इससे आपको यह समझने में मदद मिलेगी कि Jetpack Compose की परफ़ॉर्मेंस, व्यू सिस्टम की परफ़ॉर्मेंस से कितनी बेहतर है. साथ ही, यह भी पता चलेगा कि इसे कैसे मेज़र किया जा सकता है.

स्मार्ट रीकंपोज़िशन

जब यूज़र इंटरफ़ेस (यूआई) के कुछ हिस्से अमान्य होते हैं, तो Compose सिर्फ़ उन हिस्सों को फिर से कंपोज़ करने की कोशिश करता है जिन्हें अपडेट करने की ज़रूरत होती है. इसके बारे में ज़्यादा जानने के लिए, कंपोज़ेबल का लाइफ़साइकल और Jetpack Compose के फ़ेज़ दस्तावेज़ पढ़ें.

बेसलाइन प्रोफ़ाइलें

बेसलाइन प्रोफ़ाइलें, उपयोगकर्ता की सामान्य गतिविधियों को तेज़ी से पूरा करने का बेहतरीन तरीका है. अपने ऐप्लिकेशन में बेसलाइन प्रोफ़ाइल शामिल करने से, कोड को चलाने की स्पीड में करीब 30% तक सुधार हो सकता है. ऐसा पहली बार ऐप्लिकेशन लॉन्च करने के दौरान होता है. इसमें, शामिल किए गए कोड पाथ के लिए इंटरप्रेटेशन और जस्ट-इन-टाइम (जेआईटी) कंपाइलेशन के चरणों को शामिल नहीं किया जाता है.

Jetpack Compose लाइब्रेरी में अपनी बेसलाइन प्रोफ़ाइल शामिल होती है. अपने ऐप्लिकेशन में Compose का इस्तेमाल करने पर, आपको ये ऑप्टिमाइज़ेशन अपने-आप मिल जाते हैं. हालांकि, ये ऑप्टिमाइज़ेशन सिर्फ़ Compose लाइब्रेरी में मौजूद कोड पाथ पर असर डालते हैं. इसलिए, हमारा सुझाव है कि Compose के बाहर के कोड पाथ को कवर करने के लिए, अपने ऐप्लिकेशन में एक बेसलाइन प्रोफ़ाइल जोड़ें.

View सिस्टम से तुलना

Jetpack Compose में, व्यू सिस्टम की तुलना में कई सुधार किए गए हैं. इन सुधारों के बारे में, यहां दिए गए सेक्शन में बताया गया है.

हर चीज़, व्यू को एक्सटेंड करती है

स्क्रीन पर दिखने वाले हर View, जैसे कि TextView, Button या ImageView के लिए मेमोरी ऐलोकेशन, साफ़ तौर पर स्टेट ट्रैकिंग, और अलग-अलग कॉलबैक की ज़रूरत होती है, ताकि सभी इस्तेमाल के उदाहरणों को सपोर्ट किया जा सके. इसके अलावा, कस्टम View के मालिक को साफ़ तौर पर लॉजिक लागू करना होगा, ताकि जब ज़रूरत न हो, तब उसे फिर से न बनाया जाए. उदाहरण के लिए, बार-बार डेटा प्रोसेस करने के लिए.

Jetpack Compose, इस समस्या को कई तरीकों से हल करता है. Compose में, ड्रॉइंग व्यू के लिए अपडेट किए जा सकने वाले ऑब्जेक्ट नहीं होते. यूज़र इंटरफ़ेस (यूआई) एलिमेंट, कंपोज़ किए जा सकने वाले सामान्य फ़ंक्शन होते हैं. इनकी जानकारी को कंपोज़िशन में इस तरह लिखा जाता है कि इसे फिर से चलाया जा सके. इससे, साफ़ तौर पर स्टेट ट्रैकिंग, मेमोरी के बंटवारे, और कॉल बैक को कम करने में मदद मिलती है. ऐसा सिर्फ़ उन कंपोज़ेबल के लिए किया जाता है जिन्हें इन सुविधाओं की ज़रूरत होती है. ऐसा इसलिए किया जाता है, ताकि किसी दिए गए View टाइप के सभी एक्सटेंशन के लिए इनकी ज़रूरत न पड़े.

इसके अलावा, Compose में स्मार्ट रीकंपोज़िशन की सुविधा मिलती है. इसकी मदद से, अगर आपको कोई बदलाव नहीं करना है, तो पहले से बनाए गए नतीजे को फिर से चलाया जा सकता है.

एक से ज़्यादा लेआउट पास

पारंपरिक ViewGroups में, मेज़र और लेआउट एपीआई के ज़रिए कई तरह के एक्सप्रेशन इस्तेमाल किए जा सकते हैं. इस वजह से, लेआउट को कई बार पास करना पड़ता है. लेआउट के कई पास की वजह से, व्यू के नेस्ट किए गए कुछ खास पॉइंट पर बहुत ज़्यादा काम हो सकता है.

Jetpack Compose, अपने एपीआई कॉन्ट्रैक्ट के ज़रिए सभी लेआउट कंपोज़ेबल के लिए, सिंगल लेआउट पास लागू करता है. इससे Compose, डीप यूज़र इंटरफ़ेस (यूआई) ट्री को बेहतर तरीके से मैनेज कर पाता है. अगर कई मेज़रमेंट की ज़रूरत है, तो Compose में इंट्रिंसिक मेज़रमेंट होते हैं.

स्टार्टअप की परफ़ॉर्मेंस देखना

किसी लेआउट को पहली बार दिखाते समय, व्यू सिस्टम को एक्सएमएल लेआउट को बड़ा करना होता है. इस लागत को Jetpack Compose में सेव किया जाता है, क्योंकि लेआउट Kotlin में लिखे जाते हैं और आपके ऐप्लिकेशन के बाकी हिस्सों की तरह कंपाइल किए जाते हैं.

Compose को बेंचमार्क करना

Jetpack Compose 1.0 में, debug और release मोड में किसी ऐप्लिकेशन की परफ़ॉर्मेंस में काफ़ी अंतर होता है. प्रतिनिधि के समय के लिए, अपने ऐप्लिकेशन की प्रोफ़ाइल बनाते समय debug के बजाय release बिल्ड का इस्तेमाल हमेशा करें.

Jetpack Macrobenchmark लाइब्रेरी का इस्तेमाल करके, यह देखा जा सकता है कि आपका Jetpack Compose कोड कैसा परफ़ॉर्म कर रहा है. इसे Jetpack Compose के साथ इस्तेमाल करने का तरीका जानने के लिए, MacrobenchmarkSample प्रोजेक्ट देखें.

Jetpack Compose की टीम, Macrobenchmark का इस्तेमाल करके यह पता लगाती है कि कहीं कोई रिग्रेशन तो नहीं हुआ है. उदाहरण के लिए, रिग्रेशन को ट्रैक करने के लिए, लेज़ी कॉलम के लिए बेंचमार्क और उसके डैशबोर्ड देखें.

प्रोफ़ाइल इंस्टॉल करने के लिए ईमेल लिखना

Jetpack Compose एक अनबंडल्ड लाइब्रेरी है. इसलिए, इसे Zygote से कोई फ़ायदा नहीं मिलता. Zygote, View सिस्टम के यूज़र इंटरफ़ेस (यूआई) टूलकिट क्लास और ड्रॉएबल को पहले से लोड करता है. Jetpack Compose 1.0, रिलीज़ बिल्ड के लिए प्रोफ़ाइल इंस्टॉलेशन का इस्तेमाल करता है. प्रोफ़ाइल इंस्टॉलर की मदद से, ऐप्लिकेशन ऐसे ज़रूरी कोड के बारे में बता सकते हैं जिन्हें इंस्टॉल करते समय, पहले से ही (एओटी) कंपाइल किया जा सकता है. Compose, शिपिंग प्रोफ़ाइल के इंस्टॉलेशन के नियम तय करता है. इससे Compose ऐप्लिकेशन को चालू होने में कम समय लगता है और वे आसानी से काम करते हैं.