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

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

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

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

APK का साइज़

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

Sunflower में पहली बार Compose जोड़ने पर, APK का साइज़ 2,252 केबी से बढ़कर 3,034 केबी हो गया. यानी, इसमें 782 केबी की बढ़ोतरी हुई. जनरेट किए गए APK में, व्यू और Compose को मिलाकर बनाया गया यूज़र इंटरफ़ेस (यूआई) शामिल था. 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 की टीम ने पाया कि UI लिखने के लिए, बहुत कम कोड की ज़रूरत होती है. कभी-कभी यह 50%तक कम होता है. इससे, कोड की प्रॉडक्टिविटी और रखरखाव में बढ़ोतरी होती है.

Teams के लिए Compose को अपनाएं में जाकर, अन्य केस स्टडी पढ़ें.

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

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

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

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

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

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

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

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

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

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

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