Android कर्नेल सुविधाएँ अवलोकन

"और मैं ... कार्बोरेटर धो लो!"
उपाख्यान

परिचय

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

Android स्रोत कोड ने आपको कितनी बार मदद की है? मैं भी मेरी गिनती नहीं कर सकता Android एक खुली परियोजना है, लेकिन, दुर्भाग्य से, हमारे पास केवल पढ़ने की क्षमता है; Google कर्मचारी के बिना Android कोड संपादित करना लगभग असंभव है। हम इस पल पर दुखी होंगे और भंडार को लोड करेंगे। यह कैसे करना है यह आधिकारिक वेबसाइट पर अच्छी तरह से वर्णित है।



सामान्य वास्तुकला

एंड्रॉइड की वास्तुकला को निम्नानुसार योजनाबद्ध रूप से चित्रित किया जा सकता है:



मूल योजना में कर्नेल की विशेषताओं के बारे में जानकारी नहीं है और यह बाइंडर और सिस्टम सेवाओं पर ध्यान केंद्रित नहीं करता है। लेकिन बाइंडर "गोंद" है जो सिस्टम के सभी घटकों को बांधता है।

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

कोर

कर्नेल किसी भी वितरण का केंद्रीय हिस्सा है जिसे लिनक्स कहा जाता है। " क्लीन " कर्नेल की उपलब्धता के बावजूद, कई डेवलपर्स (Ubuntu, Fedora, SuSe, आदि) वितरण में शामिल होने से पहले अपने पैच को इसमें जोड़ते हैं। एंड्रॉइड उसी तरह से जाता है, केवल प्रत्यक्ष संगतता खोने की कीमत पर: यह "क्लीन" कर्नेल पर शुरू नहीं होगा। वर्तमान में, कर्नेल के मुख्य संस्करण में "एंड्रॉइडिज़्म" को शामिल करने का इरादा है, 2011 में, लिनस टॉर्वाल्ड्स ने इस प्रक्रिया को 4-5 साल दिया। कर्नेल संस्करण 3.5 में wakelocks तंत्र को शामिल करके सफलता पहले ही प्राप्त कर ली गई है।

आइए "एंड्रॉइडिज़्म" पर अधिक विस्तार से विचार करें।

wakelocks

इस तंत्र का इतिहास महाकाव्य है, यह लेखों के संग्रह पर आकर्षित करेगा "लिनक्स के लिए वेक्लोक्स का रास्ता": एलकेएमएल मेलिंग सूची में उनकी चर्चा में लगभग 2000 पत्र थे।

डेस्कटॉप कंप्यूटर और लैपटॉप में ऊर्जा मोड की एक स्थापित प्रणाली होती है (x86 प्रोसेसर में कई होते हैं): कंप्यूटर "पूर्ण गति" पर चलता है जब कुछ किया जाता है, और सिस्टम निष्क्रिय होने पर ऊर्जा-कुशल मोड में चला जाता है। "स्लीप" मोड में जाना या तो निष्क्रियता की लंबी अवधि के बाद होता है, या मैन्युअल रूप से, उदाहरण के लिए, जब लैपटॉप के ढक्कन को बंद करना।

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

कई डेवलपर्स से प्रतिरोध के कारण कर्नेल के लिए वैकलॉक तंत्र को पोर्ट करने का प्रयास। एंड्रॉइड प्रोग्रामर्स ने एक विशिष्ट समस्या हल की, जिसका समाधान एक निश्चित तंत्र था। समस्या की स्थितियाँ बहुत संकीर्ण थीं। लक्ष्य मंच एआरएम है, इसलिए इसकी विशेषताओं का उपयोग किया गया था: एआरएम प्रोसेसर ने शुरू में x86 के विपरीत, "स्लीप" और "वेक" ऑपरेटिंग मोड में लगातार परिवर्तन माना। एंड्रॉइड में, एप्लिकेशन पावर मैनजर के माध्यम से पावर मैनेजमेंट सिस्टम के साथ संवाद करते हैं, और लिनक्स क्लाइंट अनुप्रयोगों को क्या करना चाहिए?

एंड्रॉइड डेवलपर्स ने "भविष्य के लिए" एक सामान्य समाधान खोजने की कोशिश भी नहीं की, जो तब मूल रूप से मुख्य कोर में बह जाएगा, इस मुद्दे पर लिनक्स कर्नेल समुदाय से परामर्श नहीं किया। क्या आप उन्हें दोष दे सकते हैं? सभी समस्याओं और चर्चाओं के बावजूद, जैसा कि ऊपर उल्लेख किया गया है, कर्नेल में समान ऑटोसलेप कार्यक्षमता वाला एक एपीआई दिखाई दिया है।

एंड्रॉइड एप्लिकेशन प्रोग्रामर्स को शायद ही कभी वैकलॉक-एस से निपटना पड़ता है, क्योंकि प्लेटफॉर्म और ड्राइवर अपने दायित्वों को "नींद" मोड में लेते हैं। हालांकि, परिचित पावरमैन इस प्रक्रिया में हस्तक्षेप करने में मदद करेगा। वैसे, लेखक केवल एक परिदृश्य के साथ आता है: ब्रॉडकास्टसीवर से सेवा शुरू करते समय फोन को गिरने से रोकने के लिए, जो कि एंड्रॉइड सपोर्ट लाइब्रेरी WakefulBroadcastReceiver से सहायक वर्ग द्वारा तय किया गया है।

कम स्मृति हत्यारा

मानक लिनक्स कर्नेल में आउट ऑफ मेमोरी किलर होता है , जो बैड पैरामीटर के आधार पर, मारने की प्रक्रिया को निर्धारित करता है:

badness_for_task = total_vm_for_task / (sqrt(cpu_time_in_seconds) *
sqrt(sqrt(cpu_time_in_minutes)))

इस प्रकार, प्रक्रिया जितनी अधिक स्मृति का उपभोग करती है और जितनी कम रहती है, उतनी ही कम भाग्यशाली होती है।

सभी प्रोग्रामर जो प्रलेखन पढ़ते हैं या साक्षात्कार में उत्तीर्ण होते हैं, वे जानते हैं कि, सबसे पहले, प्रक्रिया को "मार डाला" जा सकता है और यदि नि: शुल्क संसाधन हैं, तो दूसरी बात, बाहर भीड़ के लिए उम्मीदवार को अन्य मानदंडों के अनुसार चुना जाता है: "लाइव" एंड्रॉइड घटक की उपस्थिति, दृश्यता उपयोगकर्ता और इतने पर।

तंत्र काफी सरल है: प्रत्येक प्रक्रिया को -17 से 16 तक प्राथमिकता दी जाती है, जबकि उच्च प्राथमिकता, प्रक्रिया को मारने की संभावना अधिक होती है, और, मुफ्त मेमोरी की मात्रा के आधार पर, प्राथमिकता का चयन किया जाता है, जिसमें से प्रक्रियाएं पूरी हो जाएंगी। ProcessList.java में प्राथमिकताएँ वर्णित हैं। दिलचस्प बात यह है कि, HOME_APP_ADJ होम स्क्रीन एप्लिकेशन की प्राथमिकता काफी अधिक है, लेकिन मैंने सोचा: यह लगातार क्यों शुरू होता है?

सरणियाँ mOomAdj और mOomMinFreeLow / mOomMinFreeHigh सिर्फ "जब क्या साफ़ करें" नियम सेट करें:

 private final int[] mOomAdj = new int[] {FOREGROUND_APP_ADJ, VISIBLE_APP_ADJ, PERCEPTIBLE_APP_ADJ, BACKUP_APP_ADJ, CACHED_APP_MIN_ADJ, CACHED_APP_MAX_ADJ}; private final long[] mOomMinFreeHigh = new long[] {49152, 61440, 73728,86016, 98304, 122880}; 

इस प्रकार, होम स्क्रीन एप्लिकेशन को 1280x800 की स्क्रीन और 700 एमबी की रैम के साथ फोन पर 73728 केबी की शेष मुफ्त मेमोरी के साथ मजबूर किया जाता है।
ProcessList कर्नेल के लिए संबंधित मानों को पारित करता है, जैसा कि इसके अपडेटऑमवेल विधि में देखा जा सकता है।

प्रक्रियाओं के लिए प्राथमिकताएँ गतिविधि प्रबंधक सेवा द्वारा निर्धारित की जाती हैं, जो कि कई सिस्टम सेवाओं में से एक है जिसे गतिविधि प्रबंधक के माध्यम से संचारित किया जा सकता है।

बाइंडर

बाइंडर , अन्य समाधानों (फाइल, सिग्मल्स, सॉकेट्स, पाइप्स, सेमाफोरस, शेयर्ड मेमोरी आदि) के साथ इंटरप्रोसेस संचार की समस्या को हल करता है। इस समाधान के पैर OpenBinder परियोजना से बढ़ते हैं, जिसके डेवलपर्स ने एक समय में एंड्रॉइड टीम में स्विच किया था।

बायोनिक (libc कार्यान्वयन) सिस्टम V IPC का उपयोग नहीं करता है, क्योंकि Android वातावरण में, मानक उपकरण संसाधन लीक को जन्म देंगे।

विशेषताएं:

1. प्रवाह नियंत्रण (हम सभी को याद है कि AIDL का समर्थन करने वाली सेवा को बहु-थ्रेडेड वातावरण में काम करना चाहिए)। थ्रेड्स की अधिकतम संख्या 15 है ( ProcessState.c , open_driver विधि), इसलिए आपको अनावश्यक जरूरतों के बिना बड़ी संख्या में बाइंडर थ्रेड्स को ब्लॉक नहीं करना चाहिए।
2. बिंडर " डेथ से लिंक " ऑब्जेक्ट को पकड़े हुए प्रक्रिया की मृत्यु सूचना तंत्र। उदाहरण के लिए, इसके माध्यम से, विंडो मैनेजर एप्लिकेशन की मृत्यु के बारे में सीखता है और इससे जुड़ी खिड़कियों को हटा देता है। इसके अलावा, इसके सभी श्रोताओं की मृत्यु पर स्थित स्थान प्रबंधक जीपीएस रिसीवर से पूछताछ करना बंद कर देता है। लोइमोरिओकिलर संतुष्ट। :)
3. 2 कॉल मोड: ब्लॉकिंग और नॉन-ब्लॉकिंग (वनवे)। पहले मामले में, कॉलिंग थ्रेड अवरुद्ध है और हैंडलर प्रक्रिया के थ्रेड में संसाधित होने की विधि का इंतजार करता है। प्रोग्रामर बस एक बिंदु के माध्यम से तरीकों को बुलाते हैं, प्लेटफ़ॉर्म थ्रेड्स की बातचीत का ख्याल रखता है।
4. सुरक्षा के लिए यूआईडी और पीआईडी ​​पास करें। उनके माध्यम से, सिस्टम सेवाएं निर्धारित करती हैं कि कॉलिंग प्रक्रिया को अनुरोध किए गए कार्यों को करने का अधिकार है या नहीं।
5. जावा प्रोग्रामर के लिए, बाइंडर लेनदेन में जावा विधियों में कॉल को परिवर्तित करने के लिए प्रॉक्सी और स्टब्स बनाने के लिए उपकरण।

आइए देखें कि यह स्थान प्रबंधक के उदाहरण पर कैसे काम करता है।



जब हम GPS जानकारी प्राप्त करना चाहते हैं, तो निम्नलिखित होता है:

1. हमारा आवेदन स्थान प्रबंधक पर उपयुक्त विधि कहता है।
2. स्थान प्रबंधक एक प्रॉक्सी ऑब्जेक्ट के लिए एक कॉल को दर्शाता है जो जावा विधियों और वस्तुओं को एक बाइंडर लेनदेन में परिवर्तित करता है ( स्थान प्रबंधक की प्रॉक्सी वस्तु mService है)।
3. लेन-देन कर्नेल ड्राइवर को भेजा जाता है, जो उसे स्थाननिर्माता सेवा से पुनर्निर्देशित करता है, जो विरासत में मिला है।
4. .LocationManager.Stub रिवर्स करता है: जावा विधि के लिए कॉल में लेनदेन का विस्तार करता है।
5. .LocationManagerService अनुरोध को संसाधित करता है (उदाहरण के लिए, GPS ड्राइवर)।
6. स्टब ऑब्जेक्ट एक लेनदेन में प्रतिक्रिया पैक करता है, और प्रक्रिया विपरीत दिशा में जाती है।
7. ड्राइवर ने प्रतिक्रिया वापस की।
8. प्रॉक्सी ऑब्जेक्ट जावा ऑब्जेक्ट में मेथड कॉल के परिणाम को घटाता है।

जैसा कि आप देख सकते हैं, कॉल टू सिस्टम सर्विस मेथड के पीछे काफी तर्क छिपे हुए हैं।

Ashmem

अनाम साझा मेमोरी (एशम) - एक साझा मेमोरी तंत्र। लिनक्स में, एक नियम के रूप में, यह तंत्र POSIX SHM के माध्यम से कार्यान्वित किया जाता है। एंड्रॉइड डेवलपर्स ने इसे अपर्याप्त रूप से संरक्षित माना, जो मैलवेयर के हाथों में खेल सकता है। एशम की विशेषताएं एक संदर्भ काउंटर हैं, जिसके रीसेट करने पर साझा मेमोरी को मुक्त किया जा सकता है (उदाहरण के लिए, मेमोरी को मुक्त कर दिया जाता है जब इसका उपयोग करने वाली सभी प्रक्रियाएं पूरी हो जाती हैं), और सिस्टम में पर्याप्त मेमोरी नहीं होने पर साझा क्षेत्र में कमी।

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

बाइंडर की ट्रांजेक्शन साइज़ लिमिट 1 MB है (अन्यथा, TransactionTooLargeException को फेंक दिया जाएगा)। अगर हमें एक प्रक्रिया से दूसरी प्रक्रिया में बड़ी मात्रा में डेटा ट्रांसफर करने की आवश्यकता है, तो हम सिर्फ एशम का उपयोग कर सकते हैं: एक मेमोरीफाइल बनाएं और फाइल डिस्क्रिप्टर को दूसरी प्रक्रिया में स्थानांतरित करें।

लकड़हारा

पारंपरिक वितरण, एक नियम के रूप में, दो लॉगिंग सिस्टम का उपयोग करते हैं: कर्नेल लॉग, जो dmesg कमांड के माध्यम से सुलभ है, और सिस्टम लॉग, आमतौर पर / var / लॉग डायरेक्टरी में स्थित है।

एंड्रॉइड सिस्टम में उपयोगकर्ता कार्यक्रमों के संदेशों को संग्रहीत करने के लिए कई चक्रीय बफ़र शामिल हैं (जो मेमोरी कार्ड के जीवनकाल का विस्तार करता है, क्योंकि पढ़ने-लिखने के चक्र बर्बाद नहीं होते हैं) और सॉकेट्स के साथ काम करने से अतिरिक्त देरी नहीं होती है, जो मानक syslog में उपयोग किए जाते हैं।



आरेख सामान्य एंड्रॉइड लॉगिंग सिस्टम को दिखाता है। लॉगिंग ड्राइवर प्रत्येक बफर को / dev / log / * के माध्यम से एक्सेस प्रदान करता है। अनुप्रयोग सीधे उनके पास नहीं हैं, लेकिन परिवाद पुस्तकालय के माध्यम से। Liblog लाइब्रेरी लॉग , स्लॉग और EventLog कक्षाओं के साथ संचार करती है। Adb logcat कमांड "मुख्य" बफर की सामग्री को दिखाता है।

निष्कर्ष

इस लेख में, हमने लिनक्स सिस्टम के रूप में एंड्रॉइड की कुछ विशेषताओं की संक्षिप्त जांच की। कुछ अन्य भागों (pmem, RAM कंसोल, आदि) कोष्ठक के बाहर बने रहे, साथ ही साथ प्लेटफॉर्म के ऐसे महत्वपूर्ण पहलू जैसे कि सिस्टम सेवा, सिस्टम स्टार्टअप प्रक्रिया और अन्य। यदि यह विषय दिलचस्प है, तो निम्नलिखित लेखों में हम उन पर विचार करेंगे।