एंड्रॉइड सपोर्ट लाइब्रेरी कैसे काम करती है?

Question

जहाँ तक मुझे पता है, समर्थन लाइब्रेरी का उपयोग कर रहा है क्योंकि पुराने उपकरणों में नए एपीआई नहीं हैं। उदाहरण के लिए वे नहीं जानते कि टुकड़ा क्या है और इसे कैसे कार्यान्वित किया जाए। इसलिए, इन व्यवहारों को समर्थन पुस्तकालय में परिभाषित किया गया है।

तो, मेरा मुख्य प्रश्न यह है कि एपीआई 11 (एंड्रॉइड v3.0, हनीकॉम) में पेश किए गए जुड़वां के साथ समर्थन लाइब्रेरी में फ्रैगमेंट की लाइब्रेरी के बीच क्या अंतर/अंतर है।

मेरा दूसरा सवाल यह है कि, यदि समर्थन पुस्तकालय में हर नई एपीआई डालना संभव है, तो हमारे पास दो प्रकार के पुस्तकालय क्यों हैं? मेरा मतलब है कि एंड्रॉइड समर्थन पुस्तकालय और एंड्रॉइड संस्करण X.xx लाइब्रेरी के बजाय समर्थन लाइब्रेरी के तहत सभी एपीआई जारी कर सकता है।

Answer 1

(जो आदर्श तरीका होना चाहिए) करने का इरादा सिफारिश की है

जहां तक ​​मुझे समझा गया, समर्थन पुस्तकालय अंतर्निहित एपीआई के विकल्प के रूप में काम कर सकते हैं, लेकिन ऐसा नहीं होना चाहिए, क्योंकि वे सीधे आवेदन के आकार को प्रभावित करते हैं।

उदाहरण के लिए, एक समर्थन पुस्तकालय 2 एमबी है, और इसकी कार्यक्षमता का उपयोग करने के लिए, यह सभी वर्गों, संसाधनों, आदि (2 एमबी) लेता है, इसलिए अब classes.dex (आवेदन में इस्तेमाल होने वाले सभी वर्गों की दल्विक निष्पादन योग्य फ़ाइल) एप्लिकेशन में संसाधन लाइब्रेरी कक्षाएं भी शामिल हैं, और संसाधनों के लिए समान हैं। इसलिए, अगर समर्थन पुस्तकालय के बिना मेरा ऐप आकार 1 एमबी था, तो अब समर्थन पुस्तकालय के साथ आकार 2 एमबी अतिरिक्त है, जिसका अर्थ है 3 एमबी कुल।

अब, मान लीजिए कि यह समर्थन लाइब्रेरी सुविधा इतनी आम है कि एकल डिवाइस पर, यदि मेरे पास 10 ऐप्स हैं, तो कम से कम 9 इस समान समर्थन लाइब्रेरी का उपयोग कर रहे हैं, इसलिए मेरे डिवाइस पर 9 * 2 = 18 एमबी का उपयोग किया जा रहा है एक ही समर्थन लाइब्रेरी, जिसे हर एप्लिकेशन में दोहराया जाता है, जो खराब है, क्योंकि अब 18 एमबी इतनी ज्यादा नहीं हो सकती है, लेकिन यदि आपके पास उस समर्थन लाइब्रेरी का उपयोग करके अधिक एप्लिकेशन हैं, तो आवश्यक स्थान बढ़ सकता है।

इस प्रकार, सबसे अच्छा विकल्प यह है कि प्रत्येक एप्लिकेशन के लिए इसे किसी भी ऐप के लिए पहले से ही आपके ओएस में 2 एमबी समर्थन लाइब्रेरी रखना है। इसलिए, समर्थन पुस्तकालयों का उपयोग तब किया जाना चाहिए जब आप वास्तव में पुराने संस्करणों का समर्थन करने के लिए अपने ऐप में कुछ कुशल सुविधाएं चाहते हैं।

एक और सवाल यहां उठता है:

क्यों इस समर्थन पुस्तकालय, अपने स्वयं के अद्यतन के रूप में ओएस में जोड़ा जाता है नहीं तो यह है कि आकार समस्याओं के बिना हर अनुप्रयोग है कि कार्यक्षमता का उपयोग कर सकते हैं?

उत्तर यह है कि बहुत सारी त्रुटियां हो सकती हैं। मान लीजिए कि कुछ उपयोगकर्ता के पास उस अद्यतन (समर्थन लाइब्रेरी) स्थापित नहीं है ...

यह भी मौका है कि एक अद्यतन के रूप में, यह माना जा सकता है कि यह उतना कुशल नहीं हो सकता है, या इसके साथ एकीकृत होने पर समस्याएं हो सकती हैं ओएस, जैसा कि हमने पहले ही देखा है कि प्रत्येक ओएस (विंडोज़, लिनक्स, मैक) सभी नए फीचर्स के लिए जीवन समय के अपडेट देने के बजाय नए संस्करणों के साथ आता है।

Answer 2

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

दो पुस्तकालय क्यों हैं?

क्योंकि समस्या का हिस्सा था गूगल केवल वापस सामान में से कुछ मोड़ा है, लेकिन मैं समझता हूँ कि, इसके साथ ही, नई कार्यक्षमता में से कुछ वापस कोर ओएस ढांचे सीमाओं और लापता एपीआई गहरी की वजह से पोर्ट नहीं किया जा सकता है एंड्रॉइड यूआई ढांचे के मूल में।

Answer 3

हनीकॉम + के टुकड़ों के बराबर समर्थन पुस्तकालय से टुकड़े।

दूसरी खोज करने के लिए

, प्रलेखन से:

v13 v4 का सुपरसेट है और अतिरिक्त सहायता वर्गों यानी एक ही कार्यात्मक v13 एपीआई के साथ काम करने

भी शामिल है, बस v13 के लिए अनुकूलित एपीआई।

मैं संशोधित v4 समर्थन लाइब्रेरी का उपयोग कर रहा हूं - नक्शे के साथ।

Answer 4

एंड्रॉइड हालिया रिलीज में टुकड़ों और एक्शन बार की शानदार सुविधाओं के साथ आया।

अब अगर हम इन सुविधाओं का उपयोग करना चाहते हैं और एंड्रॉइड के पुराने संस्करण का भी समर्थन करना चाहते हैं तो हमें अत्यधिक गन्दा संस्करण आश्रित कोड लिखना होगा, जो अच्छा नहीं है।

हमें इन सभी गड़बड़ी से बचाने के लिए, एंड्रॉइड समर्थन लाइब्रेरी के साथ आया जो नई सुविधाओं का पूर्ण समर्थन प्रदान नहीं करता है लेकिन डेवलपर्स को स्वच्छ डिवाइस लिखने की अनुमति देने के लिए पर्याप्त है जो सभी उपकरणों पर समर्थित है।

आपके दूसरे प्रश्न का उत्तर बहुत आसान है, टुकड़े v3.0 का एकीकृत हिस्सा हैं और यदि आप चाहते हैं कि आप केवल v3.0 + पर चलने के लिए आवेदन करें तो आपको वास्तव में बाहरी पुस्तकालय शामिल करने की आवश्यकता नहीं है।

Answer 5

क्या कहा गया है कि यह पहले से ही सच है। हालांकि कुछ विवरण गायब हैं। वास्तव में, मुझे पिछले Google आईओ में एक सत्र में भाग लेने का मौका मिला जहां उन्होंने विशेष रूप से उस बारे में बात की थी। यह जानने के लिए वास्तव में आश्चर्यजनक था कि समर्थन लाइब्रेरी सभी सकारात्मक API संस्करणों के लिए कोड होस्ट नहीं करती है, बल्कि यह उन नई सुविधाओं का अनुकूलन है जो उन्हें लगता है कि उन्हें पुराने प्लेटफॉर्म पर उपलब्ध कराने के लिए पर्याप्त प्रासंगिक हैं।तो जिस तरह से यह यह काम करता है आम तौर पर है निम्नलिखित:

• मान लीजिए कि हम ConnectivityManager नेटवर्क का ट्रैक बदल जाता
• हम समर्थन लाइब्रेरी v4 शामिल हैं और हम का उपयोग रखने के लिए (एपीआई 16 से उपलब्ध है) ब्रांड के नए उपयोग करने की आवश्यकता हैं कक्षा
• जिस तरह से यह काम करता है वह यह है कि सिस्टम हमारे एपीआई संस्करण की जांच करेगा और अगर हम एपीआई 16 में हैं तो अंतर्निहित देशी कोड चलाएंगे या किसी अन्य मामले में समर्थन लाइब्रेरी का कोड चलाएंगे।

तो यह किसी प्रकार के मार्ग गेटवे की तरह अभिनय कर रहा है। कारण यह है कि यह अंतिम ओएस और अंतिम सिस्टम सुधार (यानी हार्डवेयर त्वरण) के लिए अनुकूलित अंतिम कोड का उपयोग करने के लिए आम तौर पर अधिक कुशल (और प्रदर्शन) है।

फिर भी कुछ तत्व हैं जिन्हें कंपैट लाइब्रेरी में अनुवादित नहीं किया गया क्योंकि वे देशी अंतर्निर्मित कोड में हैं। मिसाल के तौर पर टुकड़े फिर से लिखे जाने के लिए नहीं थे क्योंकि वे API13 से हैं क्योंकि वे एक विशाल घटक हैं जिन्हें कम क्षमताओं वाले सिस्टम और उपकरणों के भीतर विभिन्न परिदृश्यों की एक विस्तृत श्रृंखला में चलाने की आवश्यकता है।

अंत में और यह सब क्योंकि, यह compats पुस्तकालयों जो एक अच्छा अभ्यास के रूप में जाना जाता है का उपयोग करने के, खासतौर से पुराने संस्करणों के लिए आपकी ऐप्लिकेशन/कोड उपलब्ध

Answer 6

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

उदाहरण के लिए टुकड़े जो आपने लाए हैं, वास्तव में संगतता लाइब्रेरी की तुलना में आईसीएस में थोड़ा अलग हैं क्योंकि आईसीएस में इसका उपयोग अधिक सुविधाएं हो सकती हैं। यदि आप टुकड़े वर्ग के लिए आईसीएस के लिए कोड देखते हैं, तो वे संगतता पुस्तकालय में समान नहीं हैं। आईसीएस में फ्रैगमेंट्स की तरह कुछ "कोड" बनाने के लिए कोड का एक दूसरा दूसरा सेट प्रोग्रामर के बिना जिंजरब्रेड जैसे पुराने संस्करण में बहुत अंतर देखता है।

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

जहां तक ​​वे समर्थन लाइब्रेरी को बढ़ते रहते हैं और समान बेस ओएस छोड़ते हैं - इसका उत्तर संगतता समस्या है। यदि उपयोगकर्ता के पास केवल v4 और v12 है, तो क्या होता है? एंड्रॉइड अभी ओएस के एंड्रॉइड एपीआई संस्करण को एप्लिकेशन संगतता के आधार के रूप में उपयोग करता है और डेवलपर्स के पास विकल्प से में समर्थन पुस्तकालय (उनके ऐप का फ़ाइल आकार बढ़ाना, लेकिन उन्हें नई सुविधाएं देना) शामिल हैं। समर्थन पुस्तकालयों का उपयोग करने वाले प्रत्येक एप्लिकेशन में स्वतंत्र रूप से उन्हें शामिल किया जाता है (जिसका अर्थ है 4 ऐप्स = 4x शामिल)।

विचार यह है कि, आप केवल अपने ओएस के मौजूदा एपीआई संस्करण (जहां तक ​​Google Play का संबंध है) द्वारा समर्थित ऐप्स डाउनलोड कर सकते हैं और आप अपने ऐप के स्वरूप और अनुभव को बनाए रखने के लिए समर्थन पुस्तकालयों को शामिल करना चुन सकते हैं पुराने एपीआई, जिनके पास अभी तक ऐसी विशेषताएं नहीं हैं जिन्हें आपने नए उपयोगकर्ताओं पर उन उपयोगकर्ताओं के लिए उपलब्ध कराया है। यह वास्तव में एक नज़र है और किसी और चीज से ज्यादा विचार करता है।

उम्मीद है कि चीजों को साफ़ करता है :)