इस लेख में, हम एंड्रॉइड एप्लिकेशन की वास्तुकला को देखेंगे।
सच कहूं, तो मुझे इस विषय पर Google का आधिकारिक
लेख बहुत उपयोगी नहीं लगा। "कैसे," के प्रश्न का उत्तर देते हुए, वह बिल्कुल नहीं समझाती कि क्या और क्यों। तो यहाँ मेरा संस्करण है, और मुझे आशा है कि यह कुछ स्पष्टता लाता है। हां, वैसे, मैं Google लेखों को पढ़ने के लिए पूरी तरह से अनुमोदित हूं, क्योंकि उनमें उपयोगी जानकारी है, जिसे मैं दोहराने नहीं जा रहा हूं।
एंड्रॉइड ओएस आर्किटेक्चर - थोड़ा इतिहास
जैसा कि अक्सर आईटी में होता है, विशिष्ट सॉफ़्टवेयर के इतिहास से कई चीजों को अलग-थलग नहीं किया जा सकता है। इसलिए हमें Android OS की मूल बातें प्राप्त करनी होंगी
Android OS का विकास 2003 में युवा कंपनी Android इंक द्वारा शुरू किया गया था। 2005 में, इस कंपनी को Google द्वारा खरीदा गया था। मेरा मानना है कि इस अवधि में एंड्रॉइड आर्किटेक्चर की मुख्य विशेषताओं की सटीक पहचान की गई थी। यह केवल एंड्रॉइड इंक की योग्यता नहीं है; Google की वास्तुकला अवधारणाओं और वित्तीय संसाधनों का Android के वास्तुकला पर निर्णायक प्रभाव पड़ा है। मैं नीचे कुछ उदाहरण दूंगा।
यदि आपको याद है, 2003-2005 को AJAX अनुप्रयोगों पर ध्यान देकर चिह्नित किया गया था। मुझे लगता है कि इसका एंड्रॉइड आर्किटेक्चर पर एक मौलिक प्रभाव था: कई पहलुओं में, यह जावा, सी #, सी ++, वीबी, आदि में लिखे गए डेस्कटॉप जीयूआई एप्लिकेशन की तुलना में एक विशिष्ट AJAX एप्लिकेशन की वास्तुकला के करीब है।
मुझे नहीं पता कि ऐसा क्यों हुआ। मेरा अनुमान है कि Google का कोई व्यक्ति उस समय के साथ आया था जब Google डॉक्स या जीमेल की भावना से समृद्ध इंटरनेट एप्लिकेशन (रिच इंटरनेट एप्लिकेशन, आरआईए) को सभी समस्याओं का समाधान माना जाता था। मेरी राय में, इस विचार को न तो बुरा कहा जा सकता है और न ही अच्छा। बस याद रखें कि एंड्रॉइड ऐप डेस्कटॉप ऐप से बहुत अलग हैं।
जीयूआई कार्यान्वयन सिद्धांत की पसंद में ग्रहण वास्तु दर्शन का प्रभाव ध्यान देने योग्य है, जो स्विंग के रूप में स्विंग के समान है।
एंड्रॉइड कोड डिज़ाइन मानकों में एमएस की दीवारों के भीतर पैदा हुआ "हंगेरियन नोटेशन" शामिल है। यह माना जा सकता है कि इन मानकों को लिखने वाला पहले विंडोज के विकास में शामिल था।
Android वास्तुकला स्तर
एंड्रॉइड ऑपरेटिंग सिस्टम के तीन बहुत अलग और अत्यधिक अलग स्तर हैं:
- यह लिनक्स के एक संशोधित और स्ट्रिप-डाउन संस्करण पर आधारित है, जैसा कि मैंने अपने पिछले लेखों में से एक में उल्लेख किया है।
- लिनक्स स्तर से ऊपर एप्लिकेशन इन्फ्रास्ट्रक्चर लेयर है, जिसमें Dalvik वर्चुअल मशीन , वेब ब्राउजर, SQLite डेटाबेस, कुछ इन्फ्रास्ट्रक्चर बैसाखी और जावा एपीआई शामिल हैं।
- और अंत में, Google द्वारा लिखित Android एप्लिकेशन का स्तर। आमतौर पर, वे बुनियादी ढांचे के स्तर का एक विस्तार हैं, क्योंकि डेवलपर इन अनुप्रयोगों या उनके भागों का उपयोग अपने स्वयं के विकास के लिए बिल्डिंग ब्लॉक के रूप में कर सकता है।
आइए इन परतों पर एक-एक करके और अधिक विस्तार से विचार करें।
लिनक्स स्तर
कल्पना कीजिए कि आप एक युवा कंपनी में एक वास्तुकार हैं। आपको एक नए प्रकार के डिवाइस के लिए एक ओएस विकसित करना होगा। आप क्या करेंगे?
मोटे तौर पर, आपके पास दो तरीके हैं: अपने स्वयं के विचारों को लागू करने के लिए, खरोंच से शुरू करना या किसी मौजूदा ओएस का उपयोग करना और इसे अपने उपकरणों के लिए अनुकूल करना।
खरोंच से लागू करना हमेशा प्रोग्रामर को रोमांचक लगता है। इन क्षणों में, हम सभी मानते हैं कि इस बार हम दूसरों की तुलना में सब कुछ बेहतर करेंगे, और इससे भी बेहतर कि हम पहले खुद से करते थे।
हालांकि, यह हमेशा व्यावहारिक नहीं होता है। उदाहरण के लिए, लिनक्स कर्नेल के उपयोग ने विकास लागतों को कम कर दिया है (शायद कहीं पहले से ही पहले से ही बड़े पैमाने पर)। सहमत हों, अगर कोई ऐसी चीज बनाने का फैसला करता है जो अपने वर्तमान स्थिति में लिनक्स कर्नेल जैसा दिखता है, तो इसके लिए कई मिलियन डॉलर की आवश्यकता होगी।
यदि आप Android Inc चलाते हैं, तो परिभाषा के अनुसार आपके पास इतना पैसा नहीं हो सकता है। यदि आप Google चलाते हैं, तो आपके पास उस तरह का धन होगा, लेकिन आप अपना ओएस बनाने पर खर्च करने से पहले दो बार सोचेंगे। लिनक्स की वर्तमान स्थिति तक पहुँचने से पहले आप कई साल बिताएंगे; कई साल की देरी बाजार में प्रवेश करने के लिए बहुत देर हो सकती है।
इस स्थिति में, Apple ने मुफ्त BSD के आधार पर Mac OS बनाने का निर्णय लिया। एंड्रॉइड इंक ने लिनक्स को एंड्रॉइड के लिए आधार के रूप में उपयोग करने का निर्णय लिया है। फ्री बीएसडी और लिनक्स दोनों के स्रोत स्वतंत्र रूप से उपलब्ध हैं और किसी भी विकास के लिए एक अच्छी नींव प्रदान करते हैं, चाहे वह एप्पल हो या गूगल।
लेकिन उस समय एक मोबाइल डिवाइस पर मानक लिनक्स चलाना असंभव था (अब यह मामला नहीं है)। उपकरणों में बहुत कम परिचालन और गैर-वाष्पशील मेमोरी थी। कंप्यूटर प्रोसेसर जहां लिनक्स आमतौर पर उपयोग किया जाता है, उनकी तुलना में प्रोसेसर काफी धीमा था। नतीजतन, एंड्रॉइड डेवलपर्स ने लिनक्स सिस्टम आवश्यकताओं को कम करने का निर्णय लिया।
यदि आप उच्च स्तर पर लिनक्स पर विचार करते हैं, तो यह कर्नेल का संयोजन है (जो आप बिना नहीं कर सकते हैं) और कई अन्य वैकल्पिक भागों। आप एक कोर भी चला सकते हैं, बिना कुछ और। तो, Google को Android ओएस के हिस्से के रूप में लिनक्स कर्नेल का उपयोग करने के लिए किसी भी मामले में मजबूर किया जाता है। इसके अलावा, वैकल्पिक भागों पर विचार किया गया था और उनमें से सबसे आवश्यक लोगों का चयन किया गया था। उदाहरण के लिए, IPTables नेटवर्क फ़ायरवॉल और ऐश शेल जोड़ा गया है। यह उत्सुक है कि ऐश को जोड़ा गया था, और बैश नहीं, इस तथ्य के बावजूद कि उत्तरार्द्ध अधिक शक्तिशाली परिमाण का एक क्रम है; शायद यह निर्णय इस तथ्य पर आधारित था कि ऐश संसाधनों पर कम मांग करता है।
एंड्रॉइड डेवलपर्स ने लिनक्स कर्नेल को संशोधित किया, मोबाइल उपकरणों में उपयोग किए जाने वाले हार्डवेयर के लिए समर्थन और, सबसे अधिक बार, कंप्यूटर पर उपलब्ध नहीं है।
लिनक्स को फाउंडेशन के रूप में चुनना एंड्रॉइड ओएस के सभी पहलुओं पर भारी प्रभाव डालता है। एंड्रॉइड का निर्माण, वास्तव में, लिनक्स बिल्ड प्रक्रिया का एक बदलाव है। Android कोड git (लिनक्स कोड को प्रबंधित करने के लिए विकसित एक उपकरण) द्वारा चलाया जाता है। और इसी तरह।
चलो यह सब दिलचस्प है, लेकिन आप सबसे अधिक संभावना है कि इन सभी विशिष्ट बिंदुओं को कभी नहीं छू सकते हैं जब तक कि आपका लक्ष्य केवल एंड्रॉइड के लिए एप्लिकेशन विकसित करना है। एक अपवाद राख आदेशों का उपयोग करके फ़ाइल सिस्टम का अवलोकन हो सकता है। एंड्रॉइड के लिए एप्लिकेशन विकसित करते समय आपको मुख्य बात पता होनी चाहिए कि एप्लिकेशन इन्फ्रास्ट्रक्चर का स्तर क्या है।
आप पूछ सकते हैं कि यदि आपको एक देशी एंड्रॉइड एप्लिकेशन विकसित करने की आवश्यकता है, तो आपको क्या करना चाहिए? Google ऐसा करने के लिए दृढ़ता से हतोत्साहित करता है। तकनीकी रूप से, निश्चित रूप से, यह संभव है, लेकिन भविष्य में आप इस एप्लिकेशन को सामान्य तरीके से वितरित नहीं कर पाएंगे। इसलिए एंड्रॉइड के लिए मूल विकास शुरू करने से पहले दो बार सोचें, जब तक कि आप एंड्रॉइड ओपन सोर्स प्रोजेक्ट (एओएसपी) पर काम नहीं कर रहे हों, यानी Android ओएस ही।
एप्लिकेशन इन्फ्रास्ट्रक्चर स्तर
ऐप्पल आईओएस और एंड्रॉइड ओएस के बीच कुछ समानताएं होने के बावजूद, दोनों ओएस के बुनियादी ढांचे के स्तर पर वास्तुशिल्प समाधानों के बीच महत्वपूर्ण अंतर हैं।
Apple ने Objective-C को एक प्रोग्रामिंग लैंग्वेज और रनटाइम एप्लिकेशन iOS के रूप में उपयोग करने का निर्णय लिया। ऑब्जेक्टिव-सी कम से कम बीएसडी पर आधारित ओएस के लिए एक प्राकृतिक विकल्प लगता है। आप एक विशिष्ट प्रीप्रोसेसर के साथ ऑब्जेक्टिव-सी को नियमित C ++ के रूप में सोच सकते हैं जो कुछ विशिष्ट भाषाई निर्माणों को जोड़ता है। आप उस मानक C ++ का उपयोग क्यों नहीं कर सकते हैं जिसमें Free BSD लिखा गया है? मुझे लगता है कि इसका कारण यह है कि Apple अपनी "Apple" शैली में सब कुछ करने की कोशिश कर रहा है।
मुख्य विचार यह है कि आईओएस अनुप्रयोगों को कमोबेश उसी भाषा में लिखा जाता है जैसे उनके पीछे का ओएस।
एंड्रॉइड ऐप उस अर्थ में बहुत अलग हैं। वे जावा में लिखे गए हैं, और यह सी ++ की तुलना में पूरी तरह से अलग तकनीक है (हालांकि वाक्य रचना सी ++ से विरासत में मिली है)।
ऐसा क्यों है? उदाहरण के लिए, एंड्रॉइड एप्लिकेशन C ++ में क्यों नहीं लिखे गए हैं? मुझे Google से कोई स्पष्टीकरण नहीं मिला, इसलिए मैं केवल अपने विचार साझा कर सकता हूं।
मुझे लगता है कि मुख्य कारण यह है कि एक ही एप्लिकेशन को अलग-अलग हार्डवेयर पर काम करने की आवश्यकता है। यह समस्या केवल Android OS के लिए होती है; Apple लोगों को ऐसी कोई समस्या नहीं है। iOS केवल इन-हाउस उपकरण पर काम करता है, और Apple का पूरी प्रक्रिया पर पूर्ण नियंत्रण है। एंड्रॉइड के लिए, विपरीत सच है: Google हार्डवेयर निर्माताओं को नियंत्रित नहीं करता है। उदाहरण के लिए, एंड्रॉइड x86, ARM और एटम प्रोसेसर पर चलता है (टिप्पणियों से पता चलता है कि x86 में एटम शामिल है, और एंड्रॉइड x86, ARM, PPC और MIPS - एक
अनुवादक के नोट पर चलता है)। बाइनरी स्तर पर, ये आर्किटेक्चर असंगत हैं।
यदि Android OS के आर्किटेक्ट ने Apple से आर्किटेक्ट के रूप में एक ही रास्ता चुना, तो Android एप्लिकेशन डेवलपर्स को एक ही समय में एक ही एप्लिकेशन के कई संस्करण वितरित करने के लिए मजबूर किया जाएगा। यह एक गंभीर समस्या होगी जो पूरे एंड्रॉइड प्रोजेक्ट को ध्वस्त कर सकती है।
विभिन्न हार्डवेयर पर काम करने के लिए समान एप्लिकेशन के लिए, Google ने एक कंटेनर-आधारित आर्किटेक्चर का उपयोग किया। ऐसी वास्तुकला में, बाइनरी कोड को एक सॉफ्टवेयर कंटेनर द्वारा निष्पादित किया जाता है और विशिष्ट हार्डवेयर के विवरण से अलग किया जाता है। उदाहरण हर किसी के लिए परिचित हैं - जावा और सी #। दोनों भाषाओं में, बाइनरी कोड हार्डवेयर की बारीकियों से स्वतंत्र है और वर्चुअल मशीन द्वारा निष्पादित किया जाता है।
बेशक, बाइनरी स्तर पर हार्डवेयर स्वतंत्रता प्राप्त करने का एक और तरीका है। एक विकल्प के रूप में, आप एक हार्डवेयर एमुलेटर का उपयोग कर सकते हैं, जिसे
QEMU के रूप में भी जाना जाता है। यह आपको अनुकरण करने की अनुमति देता है, उदाहरण के लिए, x86 प्लेटफॉर्म पर एआरएम प्रोसेसर के साथ एक उपकरण और इसी तरह। Google, एम ++ को एमुलेटर के अंदर अनुप्रयोगों के विकास के लिए एक भाषा के रूप में उपयोग कर सकता है। दरअसल, Google अपने एंड्रॉइड एमुलेटर में इस दृष्टिकोण का उपयोग करता है, जो कि QEMU पर आधारित हैं।
यह बहुत अच्छा है कि वे इस तरह से नहीं गए, क्योंकि तब किसी को एक एमुलेटर पर ओएस चलाना होगा जिसके लिए बहुत अधिक संसाधनों की आवश्यकता होती है, और, परिणामस्वरूप, काम की गति कम हो जाएगी। सबसे अच्छा प्रदर्शन प्राप्त करने के लिए, उत्सर्जन को केवल वहीं छोड़ दिया गया था जहां इसे टाला नहीं जा सकता था, हमारे मामले में, एंड्रॉइड अनुप्रयोगों में।
जैसा कि हो सकता है, Google ने एप्लिकेशन और उनके रनटाइम को विकसित करने के लिए जावा को मुख्य भाषा के रूप में उपयोग करने का निर्णय लिया है।
मुझे लगता है कि यह एक महत्वपूर्ण वास्तुशिल्प निर्णय था जिसने वर्तमान में प्रस्तुत लिनक्स-आधारित मोबाइल ओएस के बाकी हिस्सों से एंड्रॉइड को अलग रखा। जहां तक मुझे पता है, उनमें से किसी के पास आवेदन स्तर पर द्विआधारी संगतता नहीं है। उदाहरण के लिए
MeeGo को लें। यह C ++ और
Qt फ्रेमवर्क का उपयोग करता है; इस तथ्य के बावजूद कि क्यूटी क्रॉस-प्लेटफॉर्म है, विभिन्न प्लेटफार्मों के लिए अलग-अलग विधानसभाओं को बनाने की आवश्यकता गायब नहीं होती है।
जावा को चुनना, यह तय करना आवश्यक था कि किस वर्चुअल मशीन (जेवीएम) का उपयोग करना है। सीमित संसाधनों के कारण, मानक JVM का उपयोग करना मुश्किल था। मोबाइल उपकरणों के लिए डिज़ाइन किए गए
जावा एमई जेवीएम का उपयोग करने का एकमात्र संभव विकल्प था। हालाँकि, Google की खुशी अपनी खुद की वर्चुअल मशीन विकसित किए बिना पूरी नहीं होगी, और
Dalvik VM दिखाई दिया।
Dalvik VM निम्नलिखित में अन्य जावा आभासी मशीनों से भिन्न है:
- यह JAR और Pack200 प्रारूपों के विपरीत, बाइनरी कोड को संग्रहीत करने के लिए एक विशेष DEX प्रारूप का उपयोग करता है, जो अन्य वर्चुअल वर्चुअल मशीनों के लिए मानक हैं। Google ने कहा कि DEX बायनेरी JAR से छोटे हैं। मुझे लगता है कि वे एक ही सफलता के साथ Pack200 का उपयोग कर सकते हैं, लेकिन उन्होंने अपने तरीके से जाने का फैसला किया।
- Dalvik VM कई प्रक्रियाओं को एक साथ चलाने के लिए अनुकूलित है।
- Dalvik VM अन्य JVM में स्टैक आर्किटेक्चर के खिलाफ एक रजिस्टर-आधारित आर्किटेक्चर का उपयोग करता है, जो निष्पादन की गति को बढ़ाता है और बाइनरी आकार को कम करता है।
- यह निर्देशों के अपने स्वयं के सेट का उपयोग करता है (और मानक JVM बायटेकोड नहीं)
- एक प्रक्रिया में कई स्वतंत्र एंड्रॉइड एप्लिकेशन चलाना (यदि आवश्यक हो) संभव है
- एप्लिकेशन निष्पादन कई Dalvik VM प्रक्रियाओं को "प्राकृतिक तरीके" से जोड़ सकता है (हम बाद में चर्चा करेंगे कि इसका क्या मतलब है)। इस जोड़े का समर्थन करने के लिए:
- पार्सल और पार्सलेबल कक्षाओं के आधार पर वस्तुओं को क्रमबद्ध करने के लिए एक विशेष तंत्र। कार्यात्मक रूप से, Java Serializable के समान लक्ष्यों का पीछा किया जाता है, लेकिन इसके परिणामस्वरूप, डेटा छोटे और संभावित रूप से वर्जन वर्ग परिवर्तनों के प्रति अधिक सहनशील होता है।
- Android इंटरफ़ेस परिभाषा भाषा (AIDL) पर आधारित प्रक्रियाओं (अंतर प्रक्रिया कॉल, IPC) के बीच कॉल करने का एक विशेष तरीका।
- Android 2.2 से पहले, Dalvik VM ने JIT संकलन का समर्थन नहीं किया था, जो प्रदर्शन के लिए एक गंभीर झटका था। संस्करण 2.2 से शुरू, अक्सर उपयोग किए जाने वाले अनुप्रयोगों की निष्पादन गति में स्पष्ट रूप से वृद्धि हुई है ।
Google के लोगों ने भी मानक जावा JDK एपीआई संकुल को संशोधित किया। उन्होंने उनमें से कुछ को हटा दिया (उदाहरण के लिए, स्विंग से संबंधित सब कुछ) और अपने स्वयं के कई जोड़े - उनका नाम "एंड्रॉइड" से शुरू होता है।
उन्होंने कई खुले स्रोत पैकेज भी जोड़े जो कि मानक JDK का हिस्सा नहीं हैं:
बाउंसी कैसल क्रिप्टो एपीआई, HTTP क्लाइंट के लिए HTTP / HTTPS पृथक्करण के समर्थन के साथ
HTTPClient ।
Google ने एप्लिकेशन इन्फ्रास्ट्रक्चर लेयर में एक वेब ब्राउज़र भी जोड़ा है। यह मोबाइल उपकरणों के लिए पूर्ण Google
Chrome नहीं है, लेकिन यह इसके बहुत करीब है क्योंकि यह एक ही
WebKit इंजन पर आधारित है और क्रोम से JavaScript
V8 इंजन का उपयोग करता है। अंत में, यह एक अत्यंत आधुनिक और उच्च तकनीक वाला ब्राउज़र है। इसे किसी भी Android एप्लिकेशन में एकीकृत किया जा सकता है।
आज के लिए बस इतना ही। अगले लेख में, हम एंड्रॉइड एप्लिकेशन की वास्तुकला पर ध्यान केंद्रित करेंगे।
अनुवादक से अद्यतन। मूल ने एक गलत शब्दावली का इस्तेमाल किया। उन सभी के लिए धन्यवाद, जिन्होंने इन त्रुटियों को इंगित किया।
निम्नलिखित लेख: