Gradle और iOS बिल्ड तेज़ करें

KMP में आप JVM ऐप और iOS फ़्रेमवर्क बनाते हैं, इसलिए बिल्ड धीमे लग सकते हैं। थोड़ी समायोजन से हर रन में कई मिनट बचाए जा सकते हैं। ⏱️

Gradle का बिल्ड कैश पहले के रन के आउटपुट का दोबारा उपयोग करता है, इसलिए अपरिवर्तित मॉड्यूलों को शुरू से फिर बनाने के बजाय उनका पुनःसंकलन पूरी तरह छोड़ दिया जाता है।

स्वतंत्र मॉड्यूल एक साथ संकलित हो सकते हैं। समानांतर फ़्लैग Gradle को कई मॉड्यूलों का एक साथ उपयोग करने देता है, जिससे पूरा ग्राफ़ तेज़ी से पूरा होता है।

Gradle का डेमन बिल्ड के बीच चलता रहता है और सक्रिय JVM को बनाए रखता है, इसलिए अगला बिल्ड फिर से शुरू होने की लागत नहीं चुकाता।

बड़े KMP बिल्ड में मेमोरी कम पड़ सकती है। gradle.properties में JVM हीप बढ़ाने से धीमा कचरा-संग्रह बिल्ड को धीमा नहीं करता।

कॉन्फ़िगरेशन कैश आपके बिल्ड स्क्रिप्ट को दोबारा जाँचने से बचाता है, जब उनमें कुछ बदला न हो, जिससे बार-बार होने वाले बिल्ड का आरंभिक समय घटता है।

हर लक्ष्य काम को कई गुना बढ़ाता है। विकास के दौरान केवल उस सिम्युलेटर आर्किटेक्चर का बिल्ड करें जिसे आप वास्तव में चलाते हैं, हर उपकरण के हिस्से का नहीं।

Xcode का embedAndSign कार्य Kotlin फ़्रेमवर्क को जोड़ता है। एक बार में एक आर्किटेक्चर बनाने से यह धीमा चरण अनावश्यक रूप से बड़ा नहीं होता।

अनुमान लगाना मेहनत व्यर्थ करता है। Gradle का बिल्ड स्कैन ठीक-ठीक दिखाता है कि कौन से कार्य धीमे हैं, ताकि आप पहले वास्तविक बाधा को ठीक कर सकें।

रैपर का उपयोग करें, ताकि सभी लोग और आपका CI एक ही Gradle चलाएँ। एकसमान संस्करण होने पर कैश वास्तव में काम आते हैं और चुपचाप निष्क्रिय नहीं रहते।

कोई एक फ़्लैग जादुई नहीं होता। कैश, समानांतर निष्पादन, डेमन और उपयुक्त हीप को साथ इस्तेमाल करने से कठिन बिल्ड तेज़ बन जाता है।

आपने कैश, समानांतर रन, सक्रिय डेमन, अधिक हीप और छोटे iOS लक्ष्यों के साथ KMP बिल्ड तेज़ किए, फिर धीमे कार्य खोजने के लिए स्कैन का उपयोग किया। ⏱️