एक गैर-एंड्रॉइड डेवलपर की आंखों के माध्यम से एंड्रॉइड आर्किटेक्चर की सुविधाओं के बारे में

हाल ही में, हमने एंड्रॉइड के लिए पाइरस ऐप को पूरी तरह से फिर से डिज़ाइन किया है। एप्लिकेशन का पहला संस्करण पहले से ही एंड्रॉइड 2.2 के तहत काम करता था। 4.1 से नीचे एंड्रॉइड का समर्थन करने से इनकार करते हुए, हम संचित तकनीकी ऋण का भुगतान करने में सक्षम थे और स्रोत कोड को काफी सरल बनाया। हां, हमने उपयोगकर्ताओं का एक हिस्सा खो दिया (1% से कम), लेकिन दूसरी ओर, हमने डेवलपर्स को दुर्लभ कीड़े को ठीक करने के लिए समय बचाया। हम इसे सभी वर्तमान और नए उपयोगकर्ताओं के लिए कार्यक्षमता के विकास में निवेश करने में सक्षम होंगे। लंबे समय में, यह बहुत अधिक महत्वपूर्ण है।

यहां हम उन अनुभवों को साझा करते हैं जो उन लोगों के लिए उपयोगी हो सकते हैं जो एंड्रॉइड प्लेटफॉर्म के लिए विकास शुरू करने पर विचार कर रहे हैं।

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

मरना और राख से उठना

Android में इंटरफ़ेस गतिविधि पर बनाया गया है। यह एक कंटेनर है जो आमतौर पर डिवाइस की पूरी स्क्रीन पर कब्जा कर लेता है, अन्य विगेट्स इसमें रहते हैं और यह उपयोगकर्ता इंटरैक्शन के बारे में घटनाओं को प्राप्त करता है।

जब उपयोगकर्ता अनुप्रयोग को सक्रिय करता है, तो गतिविधि में एक onResume घटना डाली जाती है। होम बटन दबाया - गतिविधि गायब हो गई, लेकिन इससे पहले कि वह ऑनपॉइंट घटना प्राप्त करता है। अब तक, सब कुछ तार्किक है। जब उपयोगकर्ता डिवाइस स्क्रीन 90 डिग्री घुमाता है तो क्या होता है? आप कभी भी अनुमान नहीं लगाएंगे: OS गतिविधि को मारता है और फिर से बनाता है! जब आप किसी गतिविधि की स्थापना रद्द करते हैं, तो इसमें शामिल सभी घटक हटा दिए जाते हैं। इसका मतलब है कि आपको विशेष कोड लिखना होगा जो गतिविधि के अंदर विजेट्स की स्थिति (स्क्रॉल स्थिति, पाठ का चयनित टुकड़ा, चेकबॉक्स की स्थिति) को बचाता है और माता-पिता के फिर से तैयार होने के बाद उन्हें पुनर्स्थापित करता है। Android आपके लिए यह काम करता है, लेकिन सभी नहीं।

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

खंडित टुकड़े

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

परिभाषा के अनुसार , एक टुकड़ा एक गतिविधि में एक उपयोगकर्ता इंटरफ़ेस के व्यवहार या भाग का प्रतिनिधित्व करता है। सब कुछ स्पष्ट है। हालाँकि, खंडों का उपयोग करने के निर्देशों में हम "उपयोगकर्ता इंटरफ़ेस नहीं है जो एक खंड जोड़ना" खंड पाते हैं। CHTOA? यह पता चला है कि प्रतिपादन के लिए एक टुकड़े की अपनी खिड़की नहीं हो सकती है!

लेकिन स्क्रीन को मोड़ते समय टुकड़ों का क्या होता है? एंड्रॉइड डेवलपर्स ने इस बारे में सोचा - जब आप किसी गतिविधि को फिर से बनाते हैं, तो इसके सभी टुकड़े भी स्वचालित रूप से फिर से बनाए जाते हैं। हालाँकि, सावधानी से विचार करने पर, इस खंड में "setRetainInstance" विधि है, यदि आप इसे कॉल करते हैं, तो यह टुकड़ा नष्ट नहीं होगा और घुमावों के दौरान बहाल हो जाएगा।

पतला और सुसंगत इस अवधारणा को नहीं कहा जा सकता है।

अतुल्यकालिक ऑपरेशन

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

यह कई पुस्तकालयों की उपस्थिति स्पष्ट हो जाता है - एक Android अनुप्रयोग के अंदर अतुल्यकालिक काम के आयोजन के लिए डेटा बसें।

OOM के बाद एप्लिकेशन को पुनरारंभ करना

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

व्यवहार में स्मृति से बाहर चलने की कितनी संभावना है? आमतौर पर, उच्च-रिज़ॉल्यूशन छवियों को संसाधित करते समय यह स्थिति होती है। उदाहरण के लिए, 2048x1536 की तस्वीर बिटमैप ऑब्जेक्ट की मेमोरी में 12Mb पर रहती है। आवेदन के लिए उपलब्ध मेमोरी की मात्रा विशिष्ट डिवाइस मॉडल पर निर्भर करती है और कभी-कभी बहुत छोटी (64Mb या 128Mb) होती है। चूंकि 8.0 से पहले एंड्रॉइड के सभी संस्करणों में कचरा संग्रहकर्ता कॉम्पैक्ट नहीं था, भले ही आपके पास 100Mb मुक्त मेमोरी हो, लेकिन यह 10Mb के ब्लॉक में विभाजित है, इस तरह की तस्वीर के लिए मेमोरी आवंटित करने के प्रयास से एप्लिकेशन क्रैश हो गया।

अनन्त कचरा संग्रह

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

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

दस्तावेज़ देखें

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

आगे क्या है

कुछ अध्ययनों का दावा है कि एंड्रॉइड विकास की जटिलता अपेक्षाकृत अधिक है । हमारा अनुभव बताता है कि एक सक्षम डेवलपर के लिए इस प्लेटफ़ॉर्म की सुविधाओं के लिए उपयोग करना आसान है। और यद्यपि आज एंड्रॉइड दुनिया में सबसे लोकप्रिय मोबाइल ओएस है , 5-10 वर्षों में स्थिति मौलिक रूप से बदल सकती है।

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