नमस्कार, हेब्र! गर्मियों में, मैंने एंड्रॉइड एप्लिकेशन के निर्माण पर एक रिपोर्ट के साथ समर ड्रॉयड मीटअप में बात की थी। वीडियो संस्करण यहां पाया जा सकता है:
habr.com/ru/company/funcorp/blog/462825 । और जो लोग अधिक पढ़ना पसंद करते हैं, उनके लिए मैंने यह लेख लिखा है।
यह इस बारे में है कि यह क्या है - एक Android एप्लिकेशन। हम अलग-अलग तरीकों से इकट्ठा करेंगे हैलो, दुनिया !: कंसोल से शुरू करें और देखें कि बिल्ड सिस्टम के हुड के नीचे क्या होता है, फिर अतीत में वापस, मावेन को याद करें और आधुनिक बाजेल और बक समाधान के बारे में जानें। और अंत में, यह सब तुलनीय है।
हमने विधानसभा प्रणाली में एक संभावित बदलाव के बारे में सोचा जब हमने एक नई परियोजना शुरू की। हमें यह प्रतीत हुआ कि ग्रैडल के कुछ विकल्पों की तलाश करने का यह एक अच्छा अवसर है। इसके अलावा, किसी मौजूदा प्रोजेक्ट का अनुवाद करने की तुलना में शुरुआत में ऐसा करना आसान है। निम्नलिखित ग्रेड दोषों ने हमें इस कदम पर धकेल दिया:
- उन्हें निश्चित रूप से वृद्धिशील विधानसभा के साथ समस्याएं हैं, हालांकि वह इस दिशा में प्रगति देख सकते हैं;
- वह बहुत बड़ी अखंड परियोजनाओं के साथ खराब प्रदर्शन करता है;
- ऐसा होता है कि एक दानव बहुत लंबे समय के लिए शुरू होता है;
- जिस मशीन पर यह चल रहा है, उसकी मांग करना।
APK
सबसे पहले, याद रखें कि एंड्रॉइड एप्लिकेशन में क्या हैं: संकलित कोड, संसाधन और AndroidManifest.xml।
स्रोत एक विशेष डेक्स प्रारूप में क्लासेस .dex फ़ाइल (एप्लिकेशन के आकार के आधार पर कई फाइलें हो सकती हैं) हैं, जो एंड्रॉइड वर्चुअल मशीन के साथ काम कर सकती हैं। आज यह एआरटी है, पुराने उपकरणों पर - दलविक। इसके अलावा, आप लिबर फ़ोल्डर पा सकते हैं, जहां मूल स्रोतों को सबफ़ोल्डर्स में व्यवस्थित किया जाता है। उन्हें लक्ष्य प्रोसेसर वास्तुकला के आधार पर नामित किया जाएगा, उदाहरण के लिए x86, हाथ, आदि। यदि आप एक्सोप्लेयर का उपयोग करते हैं, तो संभवतः आपके पास लिब है। और सहायता फ़ोल्डर, जिसमें इंटरप्रोसेस संचार इंटरफेस है। यदि आपको किसी अन्य प्रक्रिया में चल रही सेवा तक पहुंचने की आवश्यकता है तो वे काम में आएंगे। ऐसे इंटरफेस का उपयोग एंड्रॉइड में और GooglePlayServices के अंदर दोनों में किया जाता है।
विभिन्न गैर-संकलित संसाधन जैसे चित्र Res फ़ोल्डर में हैं। सभी संकलित संसाधन, जैसे कि शैलियों, रेखाओं, आदि को एक resource.arsc फ़ाइल में मिला दिया जाता है। एसेट फ़ोल्डर में, एक नियम के रूप में, वे सब कुछ डालते हैं जो संसाधनों में फिट नहीं होते हैं, उदाहरण के लिए, कस्टम फोंट।
इन सब के अलावा, APK में AndroidManifest.xml शामिल है। इसमें, हम एप्लिकेशन के विभिन्न घटकों का वर्णन करते हैं, जैसे गतिविधि, सेवा, विभिन्न अनुमतियाँ, आदि। यह बाइनरी रूप में निहित है, और अंदर देखने के लिए, इसे पहले मानव-पठनीय फ़ाइल में बदलना होगा।
कंसोल
अब जब हम जानते हैं कि एप्लिकेशन में क्या है, तो हम हैलो, दुनिया बनाने की कोशिश कर सकते हैं! एंड्रॉइड एसडीके द्वारा प्रदान किए जाने वाले टूल का उपयोग करने वाले कंसोल से। यह समझने में एक महत्वपूर्ण कदम है कि सिस्टम कैसे काम करते हैं, क्योंकि वे सभी इन उपयोगिताओं पर एक डिग्री या किसी अन्य पर भरोसा करते हैं। चूंकि प्रोजेक्ट कोटलिन में लिखा गया है, हमें कमांड लाइन के लिए इसके कंपाइलर की आवश्यकता है। अलग से डाउनलोड करना आसान है।
एप्लिकेशन की असेंबली को निम्नलिखित चरणों में विभाजित किया जा सकता है:
- उन सभी पुस्तकालयों को डाउनलोड और अनपैक करें जिन पर परियोजना निर्भर करती है। मेरे मामले में, यह appcompat पश्चगामी संगतता पुस्तकालय है, जो बदले में, appcompat-core पर निर्भर करता है, इसलिए हम इसे बाहर भी पंप करते हैं;
- R.java उत्पन्न करें। इस अद्भुत वर्ग में एप्लिकेशन में सभी संसाधनों के पहचानकर्ता शामिल हैं और उन्हें कोड में एक्सेस करने के लिए उपयोग किया जाता है;
- हम बाइटकोड में स्रोतों को संकलित करते हैं और इसे डेक्स में अनुवाद करते हैं, क्योंकि एंड्रॉइड वर्चुअल मशीन को पता नहीं है कि सामान्य बायोटेक के साथ कैसे काम किया जाए;
- हम एपीके में सब कुछ पैक करते हैं, लेकिन पहले सभी असंगत संसाधनों को संरेखित करते हैं, जैसे कि चित्र, फ़ाइल की शुरुआत के सापेक्ष। यह एपीके के आकार में पूरी तरह से महत्वहीन वृद्धि की कीमत को अपने काम में काफी तेजी लाने की अनुमति देता है। इस प्रकार, सिस्टम मिमीप () फ़ंक्शन का उपयोग करके रैम को सीधे संसाधनों को मैप कर सकता है।
- आवेदन पर हस्ताक्षर करें। यह प्रक्रिया एपीके की अखंडता की रक्षा करती है और लेखक की पुष्टि करती है। और इसके लिए धन्यवाद, उदाहरण के लिए, Play Market यह सत्यापित कर सकता है कि एप्लिकेशन आपके द्वारा बनाया गया था।
स्क्रिप्ट का निर्माणfunction preparedir() { rm -r -f $1 mkdir $1 } PROJ="src/main" LIBS="libs" LIBS_OUT_DIR="$LIBS/out" BUILD_TOOLS="$ANDROID_HOME/build-tools/28.0.3" ANDROID_JAR="$ANDROID_HOME/platforms/android-28/android.jar" DEBUG_KEYSTORE="$(echo ~)/.android/debug.keystore" GEN_DIR="build/generated" KOTLIN_OUT_DIR="$GEN_DIR/kotlin" DEX_OUT_DIR="$GEN_DIR/dex" OUT_DIR="out" libs_res="" libs_classes="" preparedir $LIBS_OUT_DIR aars=$(ls -p $LIBS | grep -v /) for filename in $aars; do DESTINATION=$LIBS_OUT_DIR/${filename%.*} echo "unpacking $filename into $DESTINATION" unzip -o -q $LIBS/$filename -d $DESTINATION libs_res="$libs_res -S $DESTINATION/res" libs_classes="$libs_classes:$DESTINATION/classes.jar" done preparedir $GEN_DIR $BUILD_TOOLS/aapt package -f -m \ -J $GEN_DIR \ -M $PROJ/AndroidManifest.xml \ -S $PROJ/res \ $libs_res \ -I $ANDROID_JAR --auto-add-overlay preparedir $KOTLIN_OUT_DIR compiledKotlin=$KOTLIN_OUT_DIR/compiled.jar kotlinc $PROJ/java $GEN_DIR -include-runtime \ -cp "$ANDROID_JAR$libs_classes"\ -d $compiledKotlin preparedir $DEX_OUT_DIR dex=$DEX_OUT_DIR/classes.dex $BUILD_TOOLS/dx --dex --output=$dex $compiledKotlin preparedir $OUT_DIR unaligned_apk=$OUT_DIR/unaligned.apk $BUILD_TOOLS/aapt package -f -m \ -F $unaligned_apk \ -M $PROJ/AndroidManifest.xml \ -S $PROJ/res \ $libs_res \ -I $ANDROID_JAR --auto-add-overlay cp $dex . $BUILD_TOOLS/aapt add $unaligned_apk classes.dex rm classes.dex aligned_apk=$OUT_DIR/aligned.apk $BUILD_TOOLS/zipalign -f 4 $unaligned_apk $aligned_apk $BUILD_TOOLS/apksigner sign --ks $DEBUG_KEYSTORE $aligned_apk
आंकड़ों के अनुसार, यह पता चलता है कि एक स्वच्छ विधानसभा में 7 सेकंड लगते हैं, और वृद्धिशील विधानसभा इसके पीछे नहीं रहती है, क्योंकि हम कुछ भी कैश नहीं करते हैं और हर बार सब कुछ पुनर्निर्माण करते हैं।
MAVEN
यह जावा प्रोजेक्ट बनाने के लिए अपाचे सॉफ्टवेयर फाउंडेशन के लोगों द्वारा विकसित किया गया था। इसके लिए कॉन्फ़िगर बनाएँ XML में वर्णित हैं। मावेन के शुरुआती संशोधन चींटी द्वारा एकत्र किए गए थे, और अब वे नवीनतम स्थिर रिलीज में बदल गए हैं।
मावेन के पेशेवरों:
- यह कैशिंग असेंबली कलाकृतियों का समर्थन करता है, अर्थात्। वृद्धिशील निर्माण स्वच्छ से अधिक तेज होना चाहिए;
- तृतीय-पक्ष निर्भरता को हल करने में सक्षम। यानी जब आप मावेन या ग्रैडल कॉन्फ़िगरेशन में किसी तीसरे पक्ष के पुस्तकालय पर निर्भरता निर्दिष्ट करते हैं, तो आपको इस बात पर चिंता करने की आवश्यकता नहीं है कि आप क्या निर्भर करते हैं;
- विस्तृत दस्तावेज का एक समूह है, क्योंकि यह काफी समय से बाजार में है।
- और यह एक परिचित निर्माण तंत्र हो सकता है यदि आप हाल ही में बैकएंड से एंड्रॉइड डेवलपमेंट की दुनिया में आए थे।
मावेन की विपक्ष:
- उस मशीन पर स्थापित जावा के संस्करण पर निर्भर करता है जिस पर विधानसभा होती है;
- एंड्रॉइड प्लगइन अब तीसरे पक्ष के डेवलपर्स द्वारा समर्थित है: व्यक्तिगत रूप से, मैं इसे एक बहुत ही महत्वपूर्ण दोष मानता हूं, क्योंकि एक दिन वे ऐसा करना बंद कर सकते हैं;
- XML अपने अतिरेक और बोझिलता के कारण बिल्ड कॉन्फिगरेशन का वर्णन करने के लिए बहुत उपयुक्त नहीं है;
- ठीक है, और जैसा कि हम बाद में देखेंगे, यह ग्रैडल की तुलना में धीमी गति से चलता है, कम से कम एक परीक्षण परियोजना पर।
निर्माण के लिए, हमें pom.xml बनाने की आवश्यकता है, जिसमें हमारी परियोजना का विवरण है। हेडर में एकत्र किए गए विरूपण साक्ष्य के बारे में बुनियादी जानकारी, साथ ही कोटलिन के संस्करण का संकेत मिलता है।
config pom.xml का निर्माण करें <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0"> <modelVersion>4.0.0</modelVersion> <groupId>com.example</groupId> <artifactId>myapplication</artifactId> <version>1.0.0</version> <packaging>apk</packaging> <name>My Application</name> <properties> <kotlin.version>1.3.41</kotlin.version> </properties> <dependencies> <dependency> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-stdlib</artifactId> <version>${kotlin.version}</version> </dependency> <dependency> <groupId>com.google.android</groupId> <artifactId>android</artifactId> <version>4.1.1.4</version> <scope>provided</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.jetbrains.kotlin</groupId> <artifactId>kotlin-maven-plugin</artifactId> <version>${kotlin.version}</version> <executions> <execution> <id>compile</id> <phase>process-sources</phase> <goals> <goal>compile</goal> </goals> </execution> </executions> </plugin> <plugin> <groupId>com.simpligility.maven.plugins</groupId> <artifactId>android-maven-plugin</artifactId> <extensions>true</extensions> <configuration> <sdk> <platform>28</platform> <buildTools>28.0.3</buildTools> </sdk> <failOnNonStandardStructure>false</failOnNonStandardStructure> </configuration> </plugin> </plugins> </build> </project>
संख्या के संदर्भ में, सब कुछ बहुत रसीला नहीं है। एक स्वच्छ विधानसभा में लगभग 12 सेकंड लगते हैं, जबकि एक वृद्धिशील एक - 10. इसका मतलब है कि मावेन किसी भी तरह पिछली विधानसभाओं से कलाकृतियों का पुन: उपयोग करता है, या, मेरी राय में, यह अधिक संभावना है कि एंड्रॉइड प्रोजेक्ट बनाने के लिए प्लग-इन इसे रोकता है।
अब वे यह सब उपयोग कर रहे हैं, मुझे लगता है, सबसे पहले, प्लगइन के निर्माता सरलता से लोग हैं। इस मुद्दे के बारे में अधिक विश्वसनीय जानकारी नहीं मिल सकी।
Bazel
Google के धनुष में इंजीनियरों ने अपनी परियोजनाओं के निर्माण के लिए Bazel का आविष्कार किया और अपेक्षाकृत हाल ही में इसे खुले स्रोत में स्थानांतरित कर दिया। बिल्ड-कॉन्फिग पाइथन के वर्णन के लिए जैसे स्काईलार्क या स्टारलार्क का उपयोग किया जाता है, दोनों नामों के लिए एक जगह है। इसे अपने नवीनतम स्थिर रिलीज का उपयोग करके इकट्ठा किया गया है।
Bazel के पेशेवरों:
- विभिन्न प्रोग्रामिंग भाषाओं के लिए समर्थन। यदि आप दस्तावेज़ पर विश्वास करते हैं, तो वह जानता है कि आईओएस, एंड्रॉइड या यहां तक कि बैकएंड के लिए प्रोजेक्ट कैसे इकट्ठा किया जाए;
- पहले एकत्रित कलाकृतियों को कैश कर सकते हैं
- मावेन निर्भरता के साथ काम करने में सक्षम;
- Bazel बहुत अच्छा है, मेरी राय में, वितरित परियोजनाओं के लिए समर्थन। वह निर्भरता के रूप में गिट रिपॉजिटरी के विशिष्ट संशोधनों को निर्दिष्ट कर सकता है, और वह उन्हें निर्माण प्रक्रिया के दौरान उन्हें अनलोड और कैश कर देगा। स्केलेबिलिटी का समर्थन करने के लिए, Bazel, उदाहरण के लिए, क्लाउड-आधारित बिल्ड सर्वर पर विभिन्न लक्ष्यों को वितरित कर सकता है, जो आपको भारी परियोजनाओं को जल्दी से बनाने की अनुमति देता है।
Bazel की विपक्ष:
- यह सब आकर्षण बनाए रखना बहुत मुश्किल है, क्योंकि बिल्ड कॉन्फिगर बहुत विस्तृत हैं और निम्न स्तर पर असेंबली का वर्णन करते हैं;
- अन्य बातों के अलावा, ऐसा लगता है कि बज़ेल अब सक्रिय रूप से विकसित हो रहा है। इस वजह से, कुछ उदाहरण एकत्र नहीं किए जाते हैं, और जो एकत्र किए जाते हैं वे पुरानी कार्यक्षमता का उपयोग कर सकते हैं, जो कि पदावनत के रूप में चिह्नित है;
- प्रलेखन अब वांछित होने के लिए बहुत कुछ छोड़ देता है, खासकर जब ग्रैडल की तुलना में;
- छोटे प्रोजेक्ट्स पर, बिल्ड-कॉन्फिग्स को वार्मिंग और एनालिसिस करने में असेंबली से ज्यादा समय लग सकता है, जो कि मेरी राय में अच्छा नहीं है।
वैचारिक रूप से, बुनियादी बाज़ल विन्यास में काम शामिल है, जहाँ हम एक परियोजना के लिए सभी प्रकार की वैश्विक चीजों का वर्णन करते हैं, और भवन, जिसमें विधानसभा के लिए सीधे लक्ष्य होते हैं।
चलो कार्यों का वर्णन करते हैं। चूंकि हमारे पास एक एंड्रॉइड प्रोजेक्ट है, इसलिए हम जो पहली चीज कॉन्फ़िगर करते हैं वह एंड्रॉइड एसडीके है। साथ ही, कॉन्फ़िगरेशन को अनलोड करने के लिए एक नियम यहां आयात किया गया है। फिर, चूंकि प्रोजेक्ट कोटलिन में लिखा गया है, इसलिए हमें इसके लिए नियम निर्दिष्ट करने चाहिए। यहाँ हम ऐसा करते हैं, सीधे एक विशिष्ट संशोधन का जिक्र करते हुए सीधे गिट रिपॉजिटरी से।
WORKSPACE android_sdk_repository( name = "androidsdk", api_level = 28, build_tools_version = "28.0.3" ) load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
अब हम BUILD पर आरंभ करते हैं।
पहले हम कोटलिन को इकट्ठा करने के लिए नियम का आयात करते हैं और वर्णन करते हैं कि हम क्या इकट्ठा करना चाहते हैं। हमारे मामले में, यह एक Android एप्लिकेशन है, इसलिए हम android_binary का उपयोग करते हैं, जहां हम मैनिफ़ेस्ट, न्यूनतम SDK, आदि सेट करते हैं। हमारा आवेदन स्रोत पर निर्भर करेगा, इसलिए हम उन्हें डिप्स में उल्लेख करते हैं और आगे बढ़ते हैं कि वे क्या हैं और उन्हें कहां खोजना है। कोड संसाधनों और एपकॉम लाइब्रेरी पर भी निर्भर करेगा। संसाधनों के लिए, हम एंड्रॉइड स्रोतों को असेंबल करने के लिए सामान्य लक्ष्य का उपयोग करते हैं, लेकिन हम केवल जावा कक्षाओं के बिना इसे संसाधन प्रदान करते हैं। और हम कुछ नियमों का वर्णन करते हैं जो तीसरे पक्ष के पुस्तकालयों का आयात करते हैं। इसमें appcompat_core का भी उल्लेख है, जो appcompat पर निर्भर करता है।
BUILD load("@io_bazel_rules_kotlin//kotlin:kotlin.bzl", "kt_android_library") android_binary( name = "app", custom_package = "com.example.myapplication", manifest = "src/main/AndroidManifest.xml", manifest_values = { "minSdkVersion": "15", }, deps = [ ":lib", ], ) kt_android_library( name = "lib", srcs = glob(["src/main/java/**/*"]), deps = [ ":res", ":appcompat", ], ) android_library( name = "res", resource_files = glob(["src/main/res/**/*"]), manifest = "src/main/AndroidManifest.xml", custom_package = "com.example.myapplication", ) aar_import( name = "appcompat", aar = "libs/appcompat.aar", deps = [ ":appcompat_core", ] ) aar_import( name = "appcompat_core", aar = "libs/core.aar", )
इस तरह के एक छोटे से प्रोजेक्ट के लिए, सब कुछ उदास लग रहा है। आधे मिनट से अधिक एक स्वच्छ निर्माण में नमस्ते, दुनिया! - बहुत कुछ। इंक्रीमेंटल बिल्ड टाइम भी परफेक्ट से दूर है।
Bazel का उपयोग इसके रचनाकारों (Google) द्वारा उनकी कुछ परियोजनाओं के लिए किया जाता है, जिसमें सर्वर वाले, साथ ही ड्रॉपबॉक्स और हुआवेई भी शामिल हैं, जो उनके लिए मोबाइल एप्लिकेशन एकत्र करते हैं। और कुख्यात डैगर 2 भी बाज़ल में जा रहा है।
बक
इसका आविष्कार Google से लेकर फेसबुक तक के दोषियों ने किया था। उन्होंने विन्यास का वर्णन करने के लिए पायथन का उपयोग किया और फिर आज वर्णित स्काईलार्क में चले गए। वह चींटी प्रणाली का उपयोग करते हुए अचानक जा रहा है।
बक पेशेवरों:
- विभिन्न प्रोग्रामिंग भाषाओं का समर्थन करता है और एंड्रियोड और आईओएस दोनों का निर्माण कर सकता है;
- पहले एकत्रित कलाकृतियों को कैश कर सकते हैं
- बक ने अपना डीएक्स कार्यान्वयन किया, जो मानक एक से अधिक तेजी से काम करता है और सिस्टम डेमॉन के साथ लटका हुआ है। इसलिए वे डेक्स आरंभीकरण पर समय बचाते हैं। इंजीनियरों ने वास्तव में बहुत कुछ अनुकूलित किया है। उदाहरण के लिए, बक उस कोड को इकट्ठा नहीं करता है जो लाइब्रेरी पर निर्भर करता है अगर लाइब्रेरी इंटर्नल्स को बदलते समय इंटरफ़ेस नहीं बदला है। इसी तरह संसाधनों के लिए: यदि पहचानकर्ता नहीं बदले हैं, तो संसाधनों को बदलते समय, कोड को पुन: प्राप्त नहीं किया जाता है।
- एक प्लगइन है जो ग्रेडलोव्स्की विन्यास के पीछे बक को छिपा सकता है। यानी आपको एक सामान्य ग्रेडल परियोजना की तरह कुछ मिलता है, जो वास्तव में बक के माध्यम से बनाया गया है।
विपक्ष बक:
- यह Bazel के रूप में बनाए रखने के लिए मुश्किल है। यानी यहां निम्न-स्तरीय नियमों का वर्णन करना भी आवश्यक है जो स्पष्ट रूप से विधानसभा प्रक्रिया का वर्णन करते हैं;
- अन्य बातों के अलावा, बक अपने आप पर मावेन निर्भरता को हल नहीं कर सकता है।
तो, हैलो, दुनिया के लिए असेंबली कॉन्फ़िगर क्या करता है! रुपये के माध्यम से? यहां हम एक कॉन्फ़िगरेशन फ़ाइल का वर्णन करते हैं, जहां हम इंगित करते हैं कि हम एक एंड्रॉइड प्रोजेक्ट बनाना चाहते हैं जिसे डीबग कुंजी के साथ हस्ताक्षरित किया जाएगा। इसी तरह आवेदन स्रोत पर निर्भर करेगा - डीईएस सरणी में देय। अगला हस्ताक्षर सेटिंग्स के साथ लक्ष्य आता है। मैं एक डेबिट कुंजी का उपयोग कर रहा हूं जो एंड्रॉइड एसडीके के साथ आता है। इसके तुरंत बाद यह लक्ष्य का पीछा करता है, जो हमारे लिए कोटलिन के स्रोतों को इकट्ठा करेगा। बाज़ल की तरह, यह संसाधनों और संगतता पुस्तकालयों पर निर्भर करता है।
हम उनका वर्णन करते हैं। बक में संसाधनों के लिए एक अलग लक्ष्य है, इसलिए बाइक उपयोगी नहीं हैं। डाउनलोड किए गए तृतीय-पक्ष लाइब्रेरी के लिए नियम निम्नलिखित हैं।
BUILD android_binary( name = 'app', manifest = 'src/main/AndroidManifest.xml', manifest_entries = { 'min_sdk_version': 15, }, keystore = ':debug_keystore', deps = [ ':lib', ], ) keystore( name = 'debug_keystore', store = 'debug.keystore', properties = 'debug.keystore.properties', ) android_library( name = 'lib', srcs = glob(['src/main/java/*.kt']), deps = [ ':res', ':compat', ':compat_core', ], language = 'kotlin', ) android_resource( name = 'res', res = "src/main/res", package = 'com.example.myapplication', ) android_prebuilt_aar( name = 'compat', aar = "libs/appcompat.aar", ) android_prebuilt_aar( name = 'compat_core', aar = "libs/core.aar", )
यह पूरी बात बहुत ही क्रूरता से चल रही है। एक साफ विधानसभा 7 सेकंड से थोड़ा अधिक समय लेती है, जबकि एक वृद्धिशील विधानसभा पूरी तरह से अदृश्य 200 मिलीसेकंड है। मुझे लगता है कि यह बहुत अच्छा परिणाम है।
यही फेसबुक करता है। अपने प्रमुख एप्लिकेशन के अलावा, वे उनके लिए फेसबुक मैसेंजर एकत्र करते हैं। और उबेर, जिन्होंने लिफ़्ट के साथ ग्रैडल और एयरबीएनबी के लिए प्लगइन बनाया।
निष्कर्ष
अब जब हमने प्रत्येक बिल्ड सिस्टम के बारे में बात की है, तो हम हैलो, दुनिया के उदाहरण का उपयोग करके उनकी एक दूसरे के साथ तुलना कर सकते हैं! कंसोल असेंबली इसकी स्थिरता से प्रसन्न है। टर्मिनल से स्क्रिप्ट के निष्पादन का समय स्वच्छ बिल्ड की विधानसभा के लिए संदर्भ माना जा सकता है, क्योंकि पार्सिंग स्क्रिप्ट के लिए तीसरे पक्ष की लागत यहां न्यूनतम है। इस मामले में, मैं मावेन को वृद्धिशील विधानसभा में एक अत्यंत तुच्छ वृद्धि के लिए एक स्पष्ट बाहरी व्यक्ति कहूंगा। बाजेल पार्स बहुत लंबे समय के लिए कॉन्फ़िगर करता है और इनिशियलाइज़ करता है: एक विचार है कि यह किसी भी तरह प्रारंभिक परिणाम को कैश करता है, क्योंकि वृद्धिशील निर्माण इसे साफ करने की तुलना में बहुत तेजी से चलाता है। बक इस संग्रह के निर्विवाद नेता हैं। बहुत तेजी से दोनों स्वच्छ और वृद्धिशील विधानसभा।
अब पेशेवरों और विपक्ष की तुलना करें। मैं तुलना में मावेन को शामिल नहीं करूंगा, क्योंकि यह स्पष्ट रूप से ग्रैडल से हार जाता है और बाजार में लगभग कभी भी उपयोग नहीं किया जाता है। मैं बक और बाजेल को एकजुट करता हूं, क्योंकि उनके पास लगभग समान फायदे और नुकसान हैं।
इसलिए, ग्रेड के बारे में:
- पहली और मेरी राय में, सबसे महत्वपूर्ण बात यह है कि यह सरल है। बहुत सरल;
- बॉक्स से बाहर, अनलोड और अनलोड निर्भरता
- उसके लिए अलग-अलग प्रशिक्षण और दस्तावेज हैं;
- Google और समुदाय दोनों द्वारा सक्रिय रूप से समर्थित। एंड्रॉइड स्टूडियो के साथ महान एकीकरण, वर्तमान प्रमुख विकास उपकरण। और एंड्रॉइड एप्लिकेशन के निर्माण के लिए सभी नई सुविधाएँ पहले ग्रैडल में दिखाई देती हैं।
बक / बाजेल के बारे में:
- ग्रैडल की तुलना में निश्चित रूप से बहुत तेज हो सकता है। मेरा मानना है कि यह बहुत बड़ी परियोजनाओं पर विशेष रूप से ध्यान देने योग्य है
- आप एक परियोजना रख सकते हैं जिसमें आईओएस और एंड्रॉइड दोनों के स्रोत कोड होंगे, और उन्हें एक निर्माण प्रणाली के साथ इकट्ठा किया जा सकता है। यह एप्लिकेशन के कुछ हिस्सों को प्लेटफार्मों के बीच फूटने की अनुमति देता है। उदाहरण के लिए, यह क्रोमियम कैसे जा रहा है;
- विस्तार से निर्भरता का वर्णन करने के लिए मजबूर किया गया और इस प्रकार वस्तुतः डेवलपर को बहु-मॉड्यूलर होने के लिए मजबूर किया गया।
विपक्ष के बारे में मत भूलना।
ग्रैडल अपनी सादगी के लिए धीमा और अक्षम होने के कारण भुगतान करता है।
बक / बाजेल, इसके विपरीत, इसकी गति के कारण, विन्यास में निर्माण प्रक्रिया का अधिक विस्तार से वर्णन करने की आवश्यकता से ग्रस्त है। ठीक है, क्योंकि वे अपेक्षाकृत हाल ही में बाजार में दिखाई दिए, बहुत सारे दस्तावेज और विभिन्न चीट शीट नहीं हैं।
iFUNNY
शायद आपके पास एक सवाल है कि हम iFunny को कैसे इकट्ठा करते हैं। जैसे कई - ग्रेडेल का उपयोग करना। और इसके कारण हैं:
- यह अभी तक स्पष्ट नहीं है कि विधानसभा गति में किस तरह का लाभ हमें मिलेगा। IFunny की एक साफ निर्माण में लगभग 3 मिनट लगते हैं, और वृद्धिशील - एक मिनट के बारे में, जो वास्तव में बहुत लंबा नहीं है।
- बक या बाजेल बिल्ड कॉन्फ़िगरेशन को बनाए रखना अधिक कठिन होता है। बक के मामले में, आपको जुड़े पुस्तकालयों और उन पुस्तकालयों की प्रासंगिकता की निगरानी करने की भी आवश्यकता है जिन पर वे निर्भर करते हैं।
- एक मौजूदा परियोजना को ग्रैडल से बक / बज़ेल में स्थानांतरित करना महंगा है, खासकर असंगत लाभ की स्थितियों में।
यदि आपकी परियोजना में 45 मिनट से अधिक समय लगने वाला है और एंड्रॉइड डेवलपमेंट टीम में लगभग 20 लोग हैं, तो यह बिल्ड सिस्टम को बदलने के बारे में सोचने के लिए समझ में आता है। यदि आप और आपका दोस्त एक स्टार्टअप को देख रहे हैं, तो ग्रेडेल का उपयोग करें और इन विचारों को छोड़ दें।
मुझे टिप्पणियों में ग्रैडल के विकल्पों की संभावनाओं पर चर्चा करने में खुशी होगी!
प्रोजेक्ट का लिंक