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

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

APK का साइज़ और बिल्ड होने में लगने वाला समय

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

APK का साइज़

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

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

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

बिल्ड प्रोसेस में लगने वाला समय

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

gradle-profiler --benchmark --project-dir . :app:assembleDebug

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

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

खास जानकारी

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

Compose for Teams का इस्तेमाल करना लेख में, ज़्यादा केस स्टडी पढ़ी जा सकती हैं.

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

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

स्मार्ट तरीके से फिर से कॉम्पोज़ करना

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

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

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

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

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

प्रोफ़ाइल इंस्टॉल करना

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