bazel मोबाइल-इंस्टॉल

अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है किसी समस्या की शिकायत करें सोर्स देखें रात · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

Android के लिए तेज़ी से दोहराना

इस पेज पर बताया गया है कि bazel mobile-install किस तरह बार-बार होने वाला डेवलपमेंट करता है Android को तेज़ी से लोड करने में मदद कर सकते हैं. इसमें बताया गया है कि इस तरीके के फ़ायदे क्या हैं. साथ ही, बताया गया है कि ऐप्लिकेशन इंस्टॉल करने के पारंपरिक तरीके की चुनौतियां हैं.

खास जानकारी

किसी Android ऐप्लिकेशन में छोटे-छोटे बदलाव बहुत जल्दी इंस्टॉल करने के लिए, यह तरीका अपनाएं:

  1. जिस ऐप्लिकेशन को इंस्टॉल करना है उसके android_binary नियम पर जाएं.
  2. proguard_specs एट्रिब्यूट को हटाकर, ProGuard को बंद करें.
  3. multidex एट्रिब्यूट को native पर सेट करें.
  4. dex_shards एट्रिब्यूट को 10 पर सेट करें.
  5. अपने डिवाइस को यूएसबी की मदद से यूएसबी की मदद से कनेक्ट करें और यूएसबी की सुविधा चालू करें इस पर डीबग करता है.
  6. bazel mobile-install :your_target चलाएं. ऐप्लिकेशन को चालू करने में थोड़ा समय लगेगा सामान्य से धीमा.
  7. कोड या Android के संसाधनों में बदलाव करें.
  8. bazel mobile-install --incremental :your_target चलाएं.
  9. ज़्यादा इंतज़ार न करने का आनंद लें.

Basel के लिए कुछ कमांड-लाइन विकल्प जो उपयोगी हो सकते हैं:

  • --adb बेज़ल को बताता है कि किस adb बाइनरी का इस्तेमाल करना है
  • --adb_arg का इस्तेमाल, adb की कमांड लाइन में ज़्यादा आर्ग्युमेंट जोड़ने के लिए किया जा सकता है. इसका एक उपयोगी ऐप्लिकेशन यह है कि आप किस डिवाइस को इंस्टॉल करना चाहते हैं अगर आपके वर्कस्टेशन से कई डिवाइस कनेक्ट हैं, तो: bazel mobile-install --adb_arg=-s --adb_arg=<SERIAL> :your_target अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
  • --start_app अपने-आप ऐप्लिकेशन चालू कर देगा

किसी भी समय संदेह होने पर, उदाहरण या हमसे संपर्क करें.

परिचय

डेवलपर के टूलचेन की सबसे अहम विशेषताओं में से एक है स्पीड: कोड बदलने और उसे रन किए जाने के बीच का अंतर दूसरी जगह, आपको सुझाव या राय मिलने से पहले मिनटों तक, कभी-कभी कई घंटों तक इंतज़ार करना पड़ता है कि क्या आपके परिवर्तन आपकी उम्मीद के मुताबिक हैं.

दुर्भाग्य से, .apk बनाने के लिए पारंपरिक Android टूलचेन कई मोनोलिथिक और क्रम से चलने वाले चरण हैं. साथ ही, इन सभी चरणों को पूरा करने के बाद ही एक Android ऐप्लिकेशन कैसे बनाते हैं. Google में, एक लाइन बनाने के लिए पांच मिनट तक इंतज़ार करना पड़ सकता है Google Maps जैसे बड़े प्रोजेक्ट में बदलाव नहीं हुआ है.

bazel mobile-install, Android के लिए बार-बार डेवलपमेंट करने की सुविधा देता है. जिसमें बदलाव की काट-छांट, वर्क शार्डिंग, और चालाकी से हेर-फेर किए गए फ़ेरबदल किए गए वीडियो का इस्तेमाल किया जाता है Android की इंटरनल सुविधाएं, यानी कि आपके ऐप्लिकेशन के कोड में कोई बदलाव नहीं किया जाना चाहिए.

ऐप्लिकेशन को इंस्टॉल करने के पुराने तरीके में आने वाली समस्याएं

Android ऐप्लिकेशन बनाने में कुछ समस्याएं आती हैं. इनमें ये समस्याएं शामिल हैं:

  • डेक्सिंग. डिफ़ॉल्ट रूप से, "dx" बिल्ड में ठीक एक बार इस्तेमाल किया जाता है और इसका इस्तेमाल नहीं किया जाता पिछले बिल्ड से काम दोबारा इस्तेमाल करने का तरीका जानें: यह हर तरीके को फिर से बदल देता है, यहां तक कि हालांकि, सिर्फ़ एक तरीका बदला गया था.

  • डिवाइस पर डेटा अपलोड हो रहा है. adb, यूएसबी 2.0 की पूरी बैंडविड्थ इस्तेमाल नहीं करता और बड़े ऐप्लिकेशन को अपलोड होने में बहुत समय लग सकता है. यह पूरा ऐप्लिकेशन अपलोड किए गए वीडियो के छोटे हिस्से में ही बदलाव हुआ हो. उदाहरण के लिए, संसाधन या भी शामिल नहीं करना है. इसलिए, यह एक बड़ी समस्या हो सकती है.

  • नेटिव कोड में कंपाइल करना. Android L ने ART पेश किया, एक नया Android रनटाइम, जो ऐप्लिकेशन को समय-समय पर कंपाइल करने की बजाय उन्हें समय से पहले ही कंपाइल कर देता है डाल्विक. इससे, लंबे समय तक इंस्टॉल किए जाने की लागत में ऐप्लिकेशन ज़्यादा तेज़ी से इंस्टॉल हो जाते हैं समय. यह उपयोगकर्ताओं के लिए एक अच्छा विकल्प है, क्योंकि वे आम तौर पर कोई ऐप्लिकेशन इंस्टॉल करते हैं उसे कई बार इस्तेमाल कर लें, लेकिन ऐप्लिकेशन का डेवलपमेंट धीमा हो जाता है, क्योंकि ऐप्लिकेशन कई बार इंस्टॉल होता है और हर वर्शन ज़्यादा से ज़्यादा बार चलता है.

bazel mobile-install को अपनाने का तरीका

bazel mobile-installये सुधार करता है:

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

  • इंक्रीमेंटल फ़ाइल ट्रांसफ़र. Android के संसाधन, .dex फ़ाइलें, और नेटिव विज्ञापन लाइब्रेरी को मुख्य .apk से हटा दिया जाता है और उन्हें एक अलग मोबाइल-इंस्टॉल डायरेक्ट्री में डालें. इससे कोड और Android को अपडेट करना आसान हो जाता है बिना किसी समस्या के संसाधनों को फिर से इंस्टॉल किए बिना. इसलिए, फ़ाइलों को ट्रांसफ़र करने में कम समय लगता है. साथ ही, इसमें सिर्फ़ वे .dex फ़ाइलें होती हैं जिनमें बदलावों को डिवाइस पर फिर से कंपाइल किया जाता है.

  • .apk के बाहर से ऐप्लिकेशन के कुछ हिस्से लोड करना. एक छोटा स्टब ऐप्लिकेशन .apk में डालें जो Android संसाधन, Java कोड और नेटिव कोड लोड करता है पर क्लिक करें, फिर नियंत्रण को असली ऐप. कुछ खास मामलों को छोड़कर, ऐप्लिकेशन पर यह जानकारी साफ़ तौर पर दी गई होती है जिनकी जानकारी नीचे दी गई है.

शार्ड डेक्सिंग

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

शार्डिंग एल्गोरिदम के पहले वर्शन में, .class फ़ाइलों को क्रम से लगाया गया फिर सूची को वर्णमाला के क्रम में रखें, फिर सूची को बराबर भागों में बांट दिया गया, लेकिन बेहतर नहीं होगा: अगर किसी क्लास को जोड़ा गया हो या हटाया गया हो (यहां तक कि नेस्ट किए गए या बिना नाम वाले) पहला, इसके बाद सभी क्लास वर्णमाला के क्रम में एक-एक शिफ़्ट हो जाएंगी, जिससे उन शार्ड को फिर से हटाया जा सकता है. इस प्रकार, यह निर्णय लिया गया कि न कि अलग-अलग क्लास के बजाय. बेशक, इससे अब भी यदि कोई नया पैकेज जोड़ा या निकाला जाता है तो कई शार्ड को नष्ट करना, लेकिन यह बहुत कम होता है एकल क्लास को जोड़ने या हटाने से ज़्यादा होता है.

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

इंक्रीमेंटल फ़ाइल ट्रांसफ़र

ऐप्लिकेशन बनाने के बाद, अगला चरण इसे इंस्टॉल करना है. आम तौर पर, कम से कम प्रयास संभव है. इंस्टॉल करने के लिए, यह तरीका अपनाया जाता है:

  1. .apk इंस्टॉल करना (आम तौर पर, adb install का इस्तेमाल करना)
  2. .dex फ़ाइलें, Android संसाधन, और स्थानीय लाइब्रेरी मोबाइल-इंस्टॉल डायरेक्ट्री

पहले चरण में ज़्यादा बढ़ोतरी नहीं हुई: ऐप्लिकेशन या तो इंस्टॉल हो गया है या नहीं. फ़िलहाल, Basel को उपयोगकर्ता की मदद से यह तय करना होता है कि उसे यह चरण पूरा करना चाहिए या नहीं --incremental कमांड लाइन विकल्प के ज़रिए, क्योंकि यह सभी मामलों में.

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

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

Stub ऐप्लिकेशन

स्टब ऐप्लिकेशन की मदद से डेक्स, नेटिव कोड, और डिवाइस पर मौजूद mobile-install डायरेक्ट्री से, Android के संसाधन इकट्ठा किए जाते हैं.

असल में लोड होने की प्रोसेस, BaseDexClassLoader को सब-क्लास करके लागू की जाती है और यह इस तकनीक के बारे में पुख्ता सबूत मौजूद हैं. ऐसा किसी भी ऐप्लिकेशन के क्लास लोड हो जाती हैं, ताकि apk में मौजूद कोई भी ऐप्लिकेशन क्लास हो को डिवाइस पर मौजूद mobile-install डायरेक्ट्री में रखा गया है, ताकि उन्हें अपडेट किया जा सके adb install के बिना.

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

इसमें दी गई Application क्लास को बदलकर ऐसा किया जाता है AndroidManifest.xml स्टब ऐप्लिकेशन का इस्तेमाल करना. यह ऐप्लिकेशन के शुरू होने पर कंट्रोल करता है और क्लास लोड करने वाले टूल और कम से कम समय में सही तरीके से रिसोर्स मैनेजर (इसका कंस्ट्रक्टर) Android फ़्रेमवर्क के अंदरूनी हिस्सों पर Java का प्रतिबिंब.

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

ये सभी काम पूरे हो जाने के बाद, स्टब ऐप्लिकेशन वास्तविक Application क्लास, सभी संदर्भों को स्वयं में वास्तविक में बदल रहा है ऐप्लिकेशन बनाया जा सकता है.

नतीजे

परफ़ॉर्मेंस

आम तौर पर, bazel mobile-install का इस्तेमाल करने पर इमारत की स्पीडअप 4 गुना से 10 गुना हो जाती है और थोड़े से बदलाव के बाद बड़े ऐप्लिकेशन इंस्टॉल करना.

नीचे दी गई संख्याओं का हिसाब Google के कुछ प्रॉडक्ट के लिए लगाया गया है:

बेशक यह बदलाव के तरीके पर निर्भर करता है: बदलावों को बाद में, फिर से कंपाइल करने के बाद बेस लाइब्रेरी को बदलने में ज़्यादा समय लगता है.

सीमाएं

स्टब ऐप्लिकेशन की जो चालें चलती हैं वे सभी मामलों में काम नहीं करतीं. नीचे दिए गए मामले उन मामलों को हाइलाइट करते हैं जहां यह उम्मीद के मुताबिक काम नहीं करता:

  • जब Context को Application क्लास में कास्ट किया जाता है ContentProvider#onCreate(). इस तरीके का इस्तेमाल, आवेदन करने के दौरान किया जाता है स्टार्ट होने से पहले हमें Application के इंस्टेंस को बदलने का मौका नहीं मिलता क्लास है, इसलिए ContentProvider अब भी स्टब ऐप्लिकेशन का रेफ़रंस देगा में होती है. शायद, यह कोई बग नहीं है क्योंकि आप Context को इस तरह से डाउनग्रेड करना था, लेकिन ऐसा लगता है कि ऐप्लिकेशन है.

  • bazel mobile-install ने जो संसाधन इंस्टॉल किए हैं वे सिर्फ़ यहां से उपलब्ध हैं ऐप खोलें. अगर दूसरे ऐप्लिकेशन इसके ज़रिए संसाधनों को ऐक्सेस करते हैं PackageManager#getApplicationResources(), ये संसाधन पिछला गैर-इंक्रीमेंटल इंस्टॉल.

  • वे डिवाइस जिन पर ART नहीं चल रहा है. जब स्टब ऐप्लिकेशन इन डिवाइसों पर सही से काम करता है Froyo और बाद में, Delvik को एक बग मिला, जिससे उन्हें लगता है कि ऐप्लिकेशन अगर इसका कोड किसी खास स्थान में एकाधिक .dex फ़ाइलों पर वितरित किया गया है, तो यह गलत है मामलों में, उदाहरण के लिए, जब किसी खास तौर पर तरीका है. जब तक आपका ऐप्लिकेशन इन गड़बड़ियों को ठीक नहीं करता, तब तक इसे Delvik के साथ काम करना चाहिए. (हालांकि, ध्यान दें कि पुराने Android वर्शन के लिए समर्थन फ़ोकस)