Google Play ऐप्लिकेशन को Jetpack Compose पर माइग्रेट करना

सभी का स्वागत है!

मेरा नाम जॉन है.

मैं Google Play Store की टीम से हूं.

यह मेरे सहकर्मी किरिल हैं.

आज हम आपको बताएंगे कि हमने व्यू और फ़्रैगमेंट सिस्टम से बहुत सारे कोड को Compose में कैसे माइग्रेट किया.

चलिए, शुरू करते हैं।

इस बदलाव को कैसे अपनाया गया और इसका दायरा कितना बड़ा था?

हमारे ऐप्लिकेशन का कोड बेस, साल 2007 से लगातार बढ़ रहा है.

हमारे पास प्रोडक्शन कोड की लाखों लाइनें, 200 स्क्रीन, और 500 यूनीक यूज़र इंटरफ़ेस (यूआई) कॉम्पोनेंट हैं. इनका इस्तेमाल, उन कई अलग-अलग स्क्रीन पर किया जाता है.

साल 2020 में, हमें लगा कि डेवलपर वेलोसिटी, विश्वसनीयता, और परफ़ॉर्मेंस के मामले में, हम अपने लक्ष्यों को हासिल नहीं कर पा रहे हैं.

इसलिए, हमने यूज़र इंटरफ़ेस (यूआई) के लिए एक मॉडर्न टेक स्टैक इस्तेमाल करने का फ़ैसला किया.

हमने कई अलग-अलग लाइब्रेरी का आकलन किया.

उस समय, AndroidX के कुछ दोस्तों ने हमसे Compose के बारे में बात की. इसके बाद, हमने Compose को अपनाने और उसका पहला मुख्य पार्टनर बनने का फ़ैसला किया.

वह कैसा रहा?

छह साल बाद, अब Play Store ऐप्लिकेशन में 97% उपयोगकर्ता इंप्रेशन, सिर्फ़ Compose से बनी स्क्रीन पर मिलते हैं.

माफ़ करें, साल 2020 से फ़ोन और बड़ी स्क्रीन वाले डिवाइसों के लिए, सभी डेवलपमेंट Compose पर ही किए जा रहे हैं.

साल 2025 से, XR, टीवी, Android Auto, और Wear जैसे अन्य डिवाइसों के लिए भी Compose का इस्तेमाल किया जा रहा है.

इस सफलता में Compose का बहुत बड़ा योगदान रहा है. यही वजह है कि हम इसे ज़्यादा से ज़्यादा इस्तेमाल कर रहे हैं.

उनके पास एक बहुत ही मज़बूत और व्यापक टेस्ट सुइट है. इसकी मदद से, हम हफ़्ते में दो बार Compose के नए वर्शन अपना पाए.

इनके ऐल्फ़ा बिल्ड और नए एपीआई को शामिल करने से, हमें गड़बड़ियां ठीक करने, परफ़ॉर्मेंस को बेहतर बनाने, और कुछ नए एपीआई को एक्सप्लोर करने में मदद मिलती है. साथ ही, हम उपयोगकर्ताओं को नया अनुभव दे पाते हैं.

खास तौर पर परफ़ॉर्मेंस की बात करें, तो Compose ने हमारी सभी मुख्य स्क्रीन पर हमारे ऐप्लिकेशन के लिए, लगातार बेहतर परफ़ॉर्मेंस दी है.

यह खोज नतीजों का पेज, होम पेज, और ज़्यादा जानकारी वाला पेज है.

ये हमारे कारोबार और उपयोगकर्ता अनुभव के लिए बहुत अहम मेट्रिक हैं. जैसे, परफ़ॉर्मेंस, जैंक, और लोड लेटेंसी.

इसलिए, हमने पिछले 14 महीनों में 30% की बढ़ोतरी देखी है.

लेकिन हम यहां तक कैसे पहुंचे?

हम यहां इसी बारे में बात करने आए हैं.

चलिए, माइग्रेशन प्लान के बारे में बात करते हैं.

इसलिए, Play ने कई चरणों वाली रणनीति अपनाई.

हम एक ही बार में सारा पैसा नहीं लगाना चाहते थे.

हमने जोखिमों को समझने, अपने कारोबार पर इसके असर को जानने, और पूरी तरह से आगे बढ़ने से पहले भरोसा बनाने के लिए कुछ कदम उठाए.

इसलिए, मैं उन्हें ये नाम दूंगा: क्रॉलिंग, वॉकिंग, जॉगिंग, और रनिंग.

इसलिए, हमारे लिए क्रॉलिंग का मतलब Compose के बारे में ज़्यादा से ज़्यादा जानकारी हासिल करना था.

हमने कम ट्रैफ़िक वाले पेज से शुरुआत की.

जैसे, सेटिंग पेज, तीसरे पक्ष के लाइसेंस वगैरह.

आपका मुख्य लक्ष्य, Compose लाइब्रेरी के बारे में जानकारी हासिल करना है.

इसलिए, आपको पंक्तियों, कॉलम, टेक्स्ट, इमेज, और इस तरह की सभी चीज़ों का इस्तेमाल करने की आदत डालनी होगी.

इसके बाद, आपको अपने ऐप्लिकेशन के पूरे इन्फ़्रास्ट्रक्चर को Compose के साथ इस्तेमाल करना होगा. साथ ही, यह समझना होगा कि Compose के साथ यह कैसे काम करता है.

इसलिए, यह इंप्रेशन लॉगिंग, क्लिक लॉगिंग, थीमिंग हो सकती है. हम उसी समय डेटा लोड करने की प्रोसेस को फिर से शुरू कर रहे थे.

इसलिए, ये सभी चीज़ें ज़रूरी हैं.

हमें एक चीज़ काफ़ी मददगार लगी. वह यह कि हमारी सभी स्क्रीन एक जैसी दिखें. इसके लिए, हमने कुछ यूनिट टेस्ट और फ़ंक्शन की जांच की. इससे हमें यह पता चला कि Compose में मौजूद थीमिंग ऑब्जेक्ट, सीधे तौर पर एक्सएमएल स्टाइल, टाइपोग्राफ़ी, रंगों, और इन सभी चीज़ों से मैप किए गए हैं.

जब हम दोनों एक-दूसरे के साथ सहज हो गए, तो हमने वॉक पर जाने का फ़ैसला किया.

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

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

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

इस मामले में, आपको एक बात का ध्यान रखना चाहिए और शायद आपको इसकी उम्मीद भी हो. वह यह है कि जैंक और इंतज़ार के समय में थोड़ी बढ़ोतरी हो सकती है. हालांकि, ऐसा इसलिए होगा, क्योंकि अब आपके पास दो स्टैक हैं.

आपके पास एक रेंडरिंग स्टैक है, जो पूरी तरह से Compose में है और एक स्टैक Views में है.

इसलिए, मेमोरी थ्रैशिंग और कुछ अतिरिक्त क्लास लोड होने जैसी समस्याएं आ सकती हैं.

हालांकि, Compose का ज़्यादा से ज़्यादा इस्तेमाल करने पर, यह समस्या दूर हो जाएगी.

अगर आपको इस दौरान वाकई इसकी ज़रूरत है, तो उस स्क्रीन को थोड़ा पहले से वॉर्म-अप किया जा सकता है, ताकि उसे लाइन में लाया जा सके और कम समय में उस लागत को कम किया जा सके.

इसलिए, वॉक करने के बाद हम जॉगिंग करते हैं.

यह तब होता है, जब हम बहुत सहज हो जाते हैं.

ज़्यादा ट्रैफ़िक वाले पेज पर सिर्फ़ एक कॉम्पोनेंट को ऑप्टिमाइज़ करने के बजाय, पूरे पेज को ऑप्टिमाइज़ करें.

इसलिए, हमने इसमें नेविगेशन लाइब्रेरी और फ़्रैगमेंट का इस्तेमाल जारी रखा. हालांकि, हर स्क्रीन के लिए, इसे Compose में पूरी तरह से लागू किया गया.

हमने फ़्रैगमेंट को ComposeView दिखाने के लिए कहा.

इसलिए, आपको बेहतर इंतज़ार का समय और जैंक देखने को मिलेगा.

आपको मेमोरी थ्रैशिंग और क्लास लोड करने की समस्या का सामना नहीं करना पड़ रहा है, जिसके बारे में मैंने बात की थी.

Compose, ComposeView लेवल पर भी कुछ लेवल की कैश मेमोरी सेव करता है.

इसलिए, अगर आपके पास एक जैसा दिखने वाले कार्ड के साथ RecyclerView है और उनमें एक जैसे आइकॉन हो सकते हैं, तो आइकॉन को पार्स करने और रिसॉर्स के इस्तेमाल से जुड़ी सारी जानकारी, ComposeView में मौजूद हर चीज़ के साथ शेयर की जाती है.

इसके बाद, हमने दौड़ना शुरू किया.

इसलिए, इस दौरान आपको पूरी मेहनत करनी चाहिए.

जब आपके ऐप्लिकेशन का ज़्यादातर ट्रैफ़िक Compose पर आ गया, तो हमने एक लेवल ऊपर जाने का फ़ैसला किया.

इसलिए, स्क्रीन के ऊपर, हमारे पास गतिविधि है.

इसलिए, ComposeView को ऐक्टिविटी रूट पर ले जाएं.

साथ ही, आपका ज़्यादातर कोड एक जैसा दिखेगा.

आप अब भी नेविगेशन से जुड़े निर्देश देने की कोशिश कर रहे हैं. जैसे, एक स्क्रीन से दूसरी स्क्रीन पर जाना.

हालांकि, फ़्रैगमेंट ट्रांज़ैक्शन करने के बजाय, कंपोज़ेबल फ़ंक्शन को कॉल किया जा रहा है.

इसे Nav2 लाइब्रेरी या Nav3 लाइब्रेरी के ऊपर किया जा सकता है. इनमें से कोई भी लाइब्रेरी चुनी जा सकती है.

हमने अपनी सभी स्क्रीन को माइग्रेट नहीं किया था.

मैंने बताया था कि हमारे पास बहुत सारे हैं.

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

आपको फिर से क्या उम्मीद करनी चाहिए, फिर से, जंक और इंतज़ार का समय हमारे कारोबार के लिए अहम है, इसलिए हम उस लिफ़ाफ़े को आगे बढ़ाते रहते हैं और आप उसे बेहतर बनाने के लिए देखते रहते हैं, क्योंकि अब हमारे पास स्क्रीन पर कैश मेमोरी है और इस मेमोरी थ्रैशिंग की समस्या बहुत कम है.

हालांकि, आपको नई सुविधाएं भी मिलती हैं.

दाईं ओर मौजूद इस GIF में इसका एक उदाहरण दिया गया है. इसमें स्क्रीन के बीच शेयर किए गए एलिमेंट ट्रांज़िशन किए जा सकते हैं.

इसलिए, हमारे पास एक इमेज है, जिसे हम एक स्क्रीन से दूसरी स्क्रीन पर जाने पर बड़ा कर रहे हैं. इससे, कॉन्टेंट को लगातार देखने का अनुभव मिलता है.

ट्रांज़िशन के दौरान, Compose की ऐनिमेशन से जुड़ी सभी सुविधाओं का भी फ़ायदा लिया जा सकता है.

अब मैं किरिल को बुलाना चाहूंगा, ताकि वे आपको कुछ और सुविधाओं के बारे में बता सकें.

धन्यवाद, जॉन.

मैं एक ऐसे विषय के बारे में बात करना चाहता हूं जो मेरे दिल के बहुत करीब है. यह विषय है, Android ऐप्लिकेशन के लिए थीम और स्टाइलिंग. मैं कुछ समय से इस पर काम कर रहा हूं.

व्यू वर्ल्ड में, Java कोड और कुछ समय बाद Kotlin कोड था. इसके बाद, X-- एक्सएमएल रिसॉर्स थे. जैसे, रंग, स्ट्रिंग, डाइमेंशन, लेआउट, थीम, और स्टाइल.

यह इस तरह काम करता था कि इन सभी एक्सएमएल रिसॉर्स को एक रिसॉर्स टेबल में कंपाइल किया जाता था, जो APK में शामिल होती थी. यह काफ़ी हद तक स्टैटिक होती थी.

एक एपीआई Resources.Theme.applyStyle था, जिसका इस्तेमाल रनटाइम के दौरान डाइनैमिक तौर पर किया जा सकता था. इससे यूज़र इंटरफ़ेस (यूआई) की हैरारकी के ऊपर, पसंद के मुताबिक स्टाइल लागू की जा सकती थी.

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

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

एक्सएमएल की दुनिया में, स्टाइल की हैरारकी का सही मेंटल मॉडल बनाना थोड़ा मुश्किल था.

आखिर में, Android Studio या किसी अन्य डेवलपमेंट टूल में ऐसा कोई यूनिफ़ाइड व्यू नहीं था जो Java, कोड, और एक्सएमएल के बीच की दूरी को कम कर सके.

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

नई दुनिया में, Compose की दुनिया में, खास तौर पर मटीरियल डिज़ाइन सिस्टम और Compose Material लाइब्रेरी के लिए, लेकिन अन्य डिज़ाइन सिस्टम के लिए भी, हमारे पास मटीरियल डिज़ाइन सिस्टम के लिए, एक MaterialTheme Composable है. इसे स्क्रीन पर अपने यूज़र इंटरफ़ेस (यूआई) की हैरारकी में सबसे ऊपर लागू किया जाता है. साथ ही, इस MaterialTheme को अपने यूज़र इंटरफ़ेस (यूआई) के किसी भी छोटे हिस्से पर ओवरले के तौर पर भी लागू किया जा सकता है.

दाईं ओर मौजूद स्क्रीन पर, आपको सबसे ऊपर Play Points गोल्ड दिखेगा. यह एक छोटा सा कार्ड है, जिसमें प्रोग्रेस इंडिकेटर और कुछ टेक्स्ट मौजूद हैं.

हम इस मटीरियल थीम ओवरले को, मटीरियल कलर यूटिलिटी लाइब्रेरी से जनरेट की गई कस्टम कलर स्कीम के साथ लागू करते हैं. यह लाइब्रेरी, GitHub पर आपके इस्तेमाल के लिए उपलब्ध है.

हम सीड के तौर पर, भूरे, पीले, और सुनहरे रंग को पास करते हैं. इससे मटीरियल कलर टोकन का पूरा स्पेक्ट्रम जनरेट होता है. इसमें प्राइमरी पर प्राइमरी और सेकंडरी पर सेकंडरी कलर शामिल होते हैं. इसके बाद, हम इस कार्ड को लागू करने के लिए इनका इस्तेमाल करते हैं.

इससे Android डेवलपर को डाइनैमिक थीमिंग की सुविधा का पूरा ऐक्सेस मिलता है.

यह सब कोड में किया जाता है, यह सब Kotlin में किया जाता है. इसका मतलब है कि यह सब कैसे काम करता है, इसका सही मेंटल मॉडल बनाना और डीबग करना बहुत आसान है.

इंटरनल तौर पर, ये ओवरले आपकी हैरारकी में मौजूद यूज़र इंटरफ़ेस (यूआई) के खास नोड में, कंपोज़िशन लोकल के तौर पर अटैच किए जाते हैं. ये नोड वे होते हैं जहां आपको ओवरले लागू करने होते हैं.

परफ़ॉर्मेंस से जुड़ी ज़रूरी बातें: Material Color Utilities लाइब्रेरी की मदद से पूरी कलर स्कीम जनरेट करने के लिए, शुल्क देना पड़ता है.

हालांकि, इसके लिए कुछ अतिरिक्त खर्च करना पड़ता है.

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

इसलिए, आपको यह मेज़र करना होगा कि इससे आपकी परफ़ॉर्मेंस पर क्या असर पड़ता है. साथ ही, आपको रनटाइम से बिल्ड टाइम तक के कुछ ओवरहेड को कम करना होगा.

बिल्ड टाइम के दौरान, Material Color Utilities लाइब्रेरी का इस्तेमाल करके, अपनी ब्रैंडिंग या प्रॉडक्ट की ज़रूरतों के हिसाब से कलर स्कीम पहले से जनरेट की जा सकती हैं. इससे, बिल्ड टाइम के दौरान इस ओवरहेड को कम किया जा सकता है.

मैंने जिन कंपोज़िशन लोकल के बारे में बताया था वे यूज़र इंटरफ़ेस (यूआई) की हैरारकी ट्री में ओवरले की सटीक जगह को ट्रैक करते हैं. ये काफ़ी सस्ते होते हैं, लेकिन मुफ़्त नहीं होते.

इसलिए, इस बात पर निर्भर करता है कि आपने कितने प्रॉडक्ट इस्तेमाल किए हैं, दर्जनों, सैकड़ों, यह जुड़ता जाता है.

साथ ही, आपको कभी न कभी इन सभी कंपोज़िशन लोकल की कुल लागत पर भी ध्यान देना होगा.

यह Compose की डाइनैमिक रनटाइम थीमिंग की क्षमताओं का एक उदाहरण है.

यहां हमारे पास चार क्वाड्रेंट हैं, एक जैसे विज़ुअल हैं, और एक जैसा इवेंट कार्ड है.

हमारे पास यह हीरो इमेज है, जो पूरे कार्ड पर फैली हुई है. इसके बाद, हमारे पास सबसे ऊपर बाईं ओर एक लेबल, सबसे नीचे दाईं ओर एक बटन, और कुछ टेक्स्ट हैं.

हर क्वाड्रेंट की दाईं ओर, आपको कलर टोकन का कॉल आउट दिखता है. इनका इस्तेमाल, हर एलिमेंट के लिए डिज़ाइन स्पेसिफ़िकेशन के तौर पर किया जाता है.

इन चारों के लिए, कार्ड लागू करने का तरीका बिलकुल एक जैसा है.

इनमें सिर्फ़ यह अंतर है कि कार्ड को रैप करने वाला मटीरियल थीम ओवरले, इमेज के मुख्य रंग के आधार पर डाइनैमिक तरीके से बनाई गई कलर स्कीम के साथ जनरेट या कॉन्फ़िगर किया जाता है. जैसे, नीला, बैंगनी, पीला, और लाल.

बाकी सब कुछ पहले जैसा ही रहेगा.

आपको अपनी गतिविधि को मिटाने और फिर से बनाने की ज़रूरत नहीं है.

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

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

अब अगले सेक्शन के लिए, जॉन के पास चलते हैं.

हाँ।

इसलिए, किरिल ने जिस सुविधा के बारे में बात की थी वह कुछ और है.

आइए, भरोसेमंद होने और तेज़ी से काम करने के बारे में बात करते हैं.

इसलिए, सभी डेवलपर और कारोबारों को अच्छी क्वालिटी का कोड तेज़ी से लिखने की ज़रूरत होती है.

आइए, देखते हैं कि Compose ने Play को ऐसा करने में कैसे मदद की.

सबसे पहले, मुझे पता है कि बड़ा डायग्राम, आर्किटेक्चर की सादगी, कोड लिखने वाले और उसे मैनेज करने वाले सभी लोगों और एजेंट के लिए बहुत फ़ायदेमंद होती है.

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

अगर आपको इसके काम करने का तरीका नहीं पता है, तो बुनियादी तौर पर आपके पास एक डेटा सोर्स होता है.

डेटा सोर्स से डेटा मिलता है.

इस डेटा को किसी खास यूआई में बदला जा सकता है. इसे हम यूआई मॉडल के तौर पर आउटपुट करते हैं.

इसके बाद, Compose उस स्टेट पर वैल्यू प्रॉपर्टी को कॉल करके, आसानी से बदलावों को मॉनिटर कर सकता है.

यह इस डायग्राम के सबसे ऊपर मौजूद ऐरो की तरह है.

इसके बाद, इवेंट उल्टी दिशा में फ़्लो होते हैं.

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

इसलिए, सब कुछ इस आसान लूप से चलता है.

हमें इससे जो फ़ायदे मिले हैं उनमें से एक यह है कि इससे परफ़ॉर्मेंस को बेहतर बनाने की अवधि कम हो जाती है.

अब यह जानने की ज़रूरत नहीं है कि ये सभी कॉल, मुख्य थ्रेड पर हो रहे हैं या अन्य थ्रेड पर.

यह एक सामान्य लूप को फ़ॉलो करता है.

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

मेंटल मॉडल की वजह से, हमारी टीम में सोर्स ऑफ़ ट्रुथ के बारे में होने वाली कई बातचीत कम हो गई हैं. साथ ही, कई तरह की रेस कंडिशन पूरी तरह से खत्म हो गई हैं.

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

इससे, Store में लोड होने में लगने वाले समय में काफ़ी सुधार हुआ. जैसे, 50 मिलीसेकंड या इससे ज़्यादा.

यह हमारे लिए काफ़ी शानदार था.

एकतरफ़ा डेटा फ़्लो के साथ-साथ, Compose का एक और बड़ा फ़ायदा यह है कि इसमें डिक्लेरेटिव यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल किया जाता है.

किरिल ने इस बारे में थोड़ी जानकारी दी.

इसलिए, Play डेवलपर को भी यह सुविधा काफ़ी पसंद आई है.

यूज़र इंटरफ़ेस (यूआई) कंट्रोल फ़्लो अब एक ही फ़ाइल में है.

दाईं ओर एक उदाहरण दिया गया है, जो काफ़ी आसान है.

@Composable
fun PurchaseRow(onClick: () -> Unit, modifier: Modifier) {
  Row(modifier) {
    Text("20% off sale")
    if (LocalExpts.current.useButtonV2) {
      ButtonV2("Buy", onClick = onClick)
    } else {
      ButtonV1("Buy", onClick = onClick)
    }
  }
}

हम एक्सपेरिमेंट फ़्लैग के आधार पर, दो बटन लागू करने के बीच स्विच कर रहे हैं.

कई व्यू फ़ाइलों या फ़्रैगमेंट फ़ाइलों और एक्सएमएल फ़ाइलों को पढ़ने के बजाय, इसे ऊपर से नीचे तक पढ़ा जा सकता है. इससे इसे पढ़ना बहुत आसान हो गया है.

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

हमने यह भी देखा है कि लाइफ़-साइकल कॉलबैक काफ़ी आसान हो गए हैं. साथ ही, अब आपको इनकी संख्या के बारे में ज़्यादा चिंता करने की ज़रूरत नहीं है.

इसलिए, व्यू लाइफ़-साइकल, फ़्रैगमेंट लाइफ़-साइकल, और ऐक्टिविटी लाइफ़-साइकल के बजाय, आपको डिस्पोज़ेबल इफ़ेक्ट और साइड इफ़ेक्ट मिलते हैं. साथ ही, इसे जहां भी रखा जाता है उसके हिसाब से यह एक जैसा काम करता है.

इसलिए, हमें इससे काफ़ी फ़ायदा मिला है.

इसलिए, मेरे हिसाब से आर्किटेक्चर में किए गए इन दो बदलावों ने एलएलएम के लिए एक नई राह खोली है. इनकी वजह से, एलएलएम अब अच्छी क्वालिटी का कोड जनरेट कर पाते हैं.

मुझे यकीन है कि आप में से कई लोगों ने अपने पसंदीदा एलएलएम के साथ ऐसा किया होगा या करने की कोशिश की होगी.

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

हालांकि, इसकी कुछ सीमाएं हैं.

Google Play को आपके कोड बेस के बारे में जानकारी नहीं होती, है न?

इसे यह नहीं पता होता कि आपने पहले से कौनसे कॉम्पोनेंट बनाए हैं, जिन्हें इसे फिर से इस्तेमाल करना चाहिए. साथ ही, इसे डिज़ाइन टोकन के नाम भी नहीं पता होते.

यह आपको सिर्फ़ हार्ड-कोड किए गए रंग और स्ट्रिंग देता है.

डिवाइस से कौनसा कॉन्टेंट आना चाहिए, सर्वर से कौनसा कॉन्टेंट आना चाहिए या मैं यह कैसे पक्का करूं कि LazyList का इस्तेमाल करने पर, यह बेहतर परफ़ॉर्म करे और सिर्फ़ एक बड़ा कॉलम न बनाए?

इसलिए, हमने इनमें से कुछ समस्याओं को हल करने के लिए, उन स्क्रीनशॉट में थोड़ा और मेटाडेटा जोड़ा है.

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

इसके बाद, एक बहुत ही हाई-लेवल फ़ंक्शन सिग्नेचर भी होता है, ताकि आप इसे बता सकें कि कौनसा कॉन्टेंट डाइनैमिक है और कौनसा स्टैटिक.

इसलिए, आपको कुछ ऐसा मिलता है जो हमारे पास पहले था, लेकिन अब वह बाद में मिलता है.

मेरे पास यहां बाउंडिंग बॉक्स नहीं हैं, क्योंकि इससे डायग्राम में बहुत ज़्यादा शोर होगा.

हालांकि, आपको हार्ड-कोड किए गए रंग और टाइपोग्राफ़ी के नाम, टाइटल लार्ज और ऑन सरफ़ेस से बदले हुए दिखेंगे.

हमने कार्ड हेडर और आइकॉन बैज जैसे कॉम्पोनेंट के नाम साफ़ तौर पर मार्क किए हैं.

इस तरह, उन्हें आपके कोड बेस में ढूंढा जा सकता है.

हमारे लिए, इनमें से कई डिज़ाइन, कॉमन डिज़ाइन लाइब्रेरी से भी आ रहे हैं. इनके बारे में किरिल कुछ ही देर में बताएंगे.

इसलिए, आपको हर बार इन सभी के लिए कस्टम लेबल नहीं बनाना होगा.

इसके बाद, इसे किसी मेथड सिग्नेचर के साथ जोड़ें, जैसा कि हमने सबसे नीचे OfferCard में किया है. इसके बाद, इसे पता चल जाता है कि टाइटल, endDate, और इमेज, सभी डाइनैमिक हैं.

हमें उन्हें हार्ड-कोड नहीं करना चाहिए.

इन सिमैंटिक नामों के साथ, अब हम उन सभी अलग-अलग कलर ऐप्लिकेशन में स्विच कर सकते हैं जिनके बारे में किरिल बात कर रहे थे.

इसकी मदद से, हम ज़्यादा कोड जनरेट कर रहे हैं.

अब मैं किरिल को बुलाना चाहूंगा, ताकि वे आपको बता सकें कि हम क्वालिटी को कैसे बनाए रखते हैं.

दाईं ओर.

धन्यवाद, जॉन.

एलएलएम और एजेंटिक-असिस्टेड डेवलपमेंट के इस विषय को जारी रखते हुए, हम सबसे पहले यूएक्स डिज़ाइन के बारे में बात करेंगे.

आपको बस इतना करना है कि आपका डिज़ाइन टूल चाहे जो भी हो, जैसे कि Figma या कोई और, आपको एक ऐसा शेयर किया गया टेंप्लेट बनाना होगा जिसका इस्तेमाल सभी डिज़ाइनर कर सकें. इस टेंप्लेट में, आपके पसंदीदा डिज़ाइन सिस्टम के कलर टोकन, टाइपोग्राफ़ी टोकन, और शेप टोकन होने चाहिए.

शायद यह मटीरियल है.

शायद यह आपका कस्टम डिज़ाइनर सिस्टम है.

अगर आपको खास तौर पर कलर टोकन के लिए, उन टेंप्लेट में पहले से मौजूद सहायता चाहिए, तो हल्के और गहरे रंग वाले मोड के बीच स्विच करें. साथ ही, सामान्य, मीडियम, और हाई कंट्रास्ट मोड के बीच स्विच करें. ये मोड कुछ साल पहले Android लेवल पर लॉन्च किए गए थे.

इससे डिज़ाइनर, इन अलग-अलग कॉम्बिनेशन के बीच तेज़ी से स्विच कर सकते हैं. साथ ही, यह देख सकते हैं कि उनके डिज़ाइन की खास बातें, इन कॉम्बिनेशन के हिसाब से कैसे काम करती हैं.

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

आखिर में, हमें Google Play के पैमाने पर जो चीज़ बहुत काम की लगी, वह यह है कि हमारे पास दर्जनों नहीं, बल्कि कुछ सौ कॉम्पोनेंट, क्लस्टर, कार्ड, और कंटेनर हैं. इनका इस्तेमाल, हमारी अलग-अलग स्क्रीन पर किया जाता है.

हमें लगता है कि इन सभी चीज़ों को एक ही जगह पर ट्रैक करना ज़्यादा फ़ायदेमंद होता है. हम इसे कॉम्पोनेंट कैटलॉग कहते हैं. इसके बाद, उस कॉम्पोनेंट कैटलॉग पर कस्टम एजेंट को ट्रेनिंग दी जाती है.

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

इससे डिज़ाइन और लागू करने की लागत में काफ़ी कमी आती है.

लागू करने के लिए, हम मुख्य और कस्टम Lint नियमों पर बहुत ज़्यादा भरोसा करते हैं.

मैं Lint के कुछ मुख्य नियमों के बारे में बताना चाहता हूं. इनमें से एक है, FrequentlyChangingValueDetector. इससे उन सोर्स की पहचान करने में मदद मिलती है जिनकी वजह से, बार-बार रीकंपोज़िशन होता है. इससे इंतज़ार का समय बढ़ सकता है और ऐप्लिकेशन हैंग हो सकता है. दूसरा नियम है, ScaffoldPaddingDetector. इससे उन मामलों को फ़्लैग किया जाता है जहां हम Material Compose Scaffold composable का इस्तेमाल करते हैं, लेकिन आने वाली पैडिंग को अनदेखा कर देते हैं.

यह लेटेंसी और जैंक की वजह नहीं है. हालांकि, कुछ मामलों में इसे डीबग करना बहुत मुश्किल हो सकता है. जैसे, कुछ मामलों में लेआउट का गलत अलाइनमेंट, जैसे कि यह एज-टू-एज है या फ़ोल्ड, अनफ़ोल्ड है.

आखिर में, BoxWithConstraints का इस्तेमाल करने पर, परफ़ॉर्मेंस से जुड़ी कुछ बातों का ध्यान रखना पड़ता है.

सभी चीज़ों को सही तरीके से लेआउट करने में दो फ़्रेम लग सकते हैं.

हम इसे पूरी तरह से ब्लॉक नहीं करते हैं. हालांकि, हम इसे Lint चेतावनी के तौर पर फ़्लैग करते हैं, ताकि उस स्क्रीन पर काम करने वाले डेवलपर को पता चल सके कि वे BoxWithConstraints का इस्तेमाल करने के लिए कोई खास विकल्प चुन रहे हैं. इसके अलावा, वे उस लेआउट के लिए कुछ और इस्तेमाल करने का विकल्प भी चुन सकते हैं.

थीम को ऑटोमेट करने के लिए, कलर टोकन, टाइपोग्राफ़ी टोकन, और शेप टोकन का इस्तेमाल किया जाता है.

हमारे पास एक लिंट नियम है, जो हार्डकोड किए गए रंगों और हार्डकोड की गई टाइपोग्राफ़ी के इस्तेमाल को रोकता है.

हमारे पास एक Lint नियम है, जो Material 2 कॉम्पोनेंट के इस्तेमाल को फ़्लैग करता है.

हम सिर्फ़ Material 3 का इस्तेमाल करना चाहते हैं. यह सबसे नया और बेहतरीन वर्शन है. इसमें पिछले साल और इस साल पेश किए गए नए कॉम्पोनेंट शामिल हैं.

हम चाहते हैं कि हमारे पास एक कस्टम लिंट नियम हो, जो लोगों को लेगसी एक्सएमएल फ़ाइलों से रंग पढ़ने से रोके.

हम नई स्क्रीन के लिए, Compose को पहली और एकमात्र प्राथमिकता देना चाहते हैं.

साथ ही, टेक्स्ट कंपोज़ेबल, खास तौर पर मटीरियल डिज़ाइन सिस्टम में, स्टाइल और रंग के लिए फ़ॉलबैक होते हैं.

वे इसे स्थानीय कॉन्टेंट के रंग और स्थानीय टाइपोग्राफ़ी से पढ़ते हैं. हालांकि, हम इस पर भरोसा नहीं करना चाहते.

हम चाहते हैं कि हर टेक्स्ट में, डिज़ाइन स्पेसिफ़िकेशन के हिसाब से खास स्टाइल, टाइपोग्राफ़ी स्टाइल, और खास रंग का इस्तेमाल किया जाए.

इसलिए, यह एक Lint नियम है जो हमारे पास है.

आखिरी बात, ScaffoldPaddingDetector की तरह ही, हमारे पास एक कस्टम Lint नियम है. यह नियम यह पक्का करता है कि हमारे पास मौजूद हर Composable फ़ंक्शन, अपने इनपुट मॉडिफ़ायर का इस्तेमाल करे.

इससे, नए इस्तेमाल को गलत तरीके से लागू होने से रोका जा सकता है. साथ ही, बैकग्राउंड को सही तरीके से इस्तेमाल किया जा सकता है.

इस प्रज़ेंटेशन में, हम आपको इन तीन मुख्य बातों के बारे में बताना चाहते हैं.

पहली बात यह है कि आज, 2026 के आखिर में, हमारी राय में Compose एक बेहतरीन यूज़र इंटरफ़ेस (यूआई) टूलकिट है. यह बड़े पैमाने पर इस्तेमाल की जा रही है.

Android, Compose-फ़र्स्ट है.

इस साल की शुरुआत में Google I/O में, हमने एलान किया था कि सभी यूज़र इंटरफ़ेस (यूआई) लाइब्रेरी और सभी एजेंटिक फ़्लो, Compose-फ़र्स्ट हैं.

जॉन ने प्रज़ेंटेशन में पहले ही बताया था कि क्रॉल, वॉक, जॉग, और रन के लिए, हमारा सुझाव है कि आप धीरे-धीरे माइग्रेट करें. खास तौर पर, बड़े कोड बेस के लिए, ताकि डेवलपर फ़्लो और एजेंटिक फ़्लो के लिए आपकी स्पीड बढ़ सके.

आज हमारे साथ जुड़ने के लिए धन्यवाद. कुछ ही मिनटों में, मैं और जॉन आपके सवालों के जवाब देने के लिए बाहर होंगे.

अपना समय देने के लिए धन्यवाद.