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

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

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

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

APK का साइज़

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

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

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% तक सुधार हो सकता है. ऐसा पहली बार ऐप्लिकेशन लॉन्च करने पर होता है. इसकी वजह यह है कि इसमें शामिल कोड पाथ के लिए, इंटरप्रेटेशन और जस्ट-इन-टाइम (JIT) कंपाइलेशन के चरणों को छोड़ दिया जाता है.

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

व्यू सिस्टम से तुलना

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 ऐप्लिकेशन को चालू होने में कम समय लगता है और वे बिना किसी रुकावट के काम करते हैं.