नया जिंजरब्रेड एपीआई स्ट्रिक्टमोड है। या हम एएनआर-संवाद के साथ लड़ते हैं

मैंने हाल ही में एंड्रॉइड डेवलपर्स ब्लॉग पर एक लेख पढ़कर स्ट्रिक्टमोड की खोज की। नीचे मैं आपको उसका अनुवाद प्रस्तुत करता हूं।

पर्दे के पीछे

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

मैं एक सक्रिय एसएमएस उपयोगकर्ता हूं और कपकेक रिलीज (एंड्रॉइड 1.5) की तैयारी के दौरान मेरी 20% परियोजनाओं में से एक मैसेजिंग एप्लिकेशन का अनुकूलन था। मैंने इसे ऑप्टिमाइज़ किया और इसे सुचारू बनाया, और फिर अपने अन्य 20% प्रोजेक्ट्स के बारे में बताया। डोनट (एंड्रॉइड 1.6) की रिहाई के बाद, मैंने देखा कि मेरी कुछ अनुकूलन गलती से टूट गई। मैं थोड़ा नाराज था, लेकिन फिर मुझे एहसास हुआ कि एंड्रॉइड में वास्तव में हमेशा कमी थी, इसलिए यह एक रेडी-टू-यूज, बिल्ट-इन, ऑल-परवेज प्रदर्शन मॉनिटरिंग टूल है।

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

StrictMode

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

डिफ़ॉल्ट रूप से, सभी ऑपरेशनों की अनुमति है, और जब तक आप इसे नहीं चाहते तब तक कुछ भी आपके रास्ते में नहीं खड़ा है। झंडे जो आप नीतियों के माध्यम से प्रबंधित कर सकते हैं, उनमें शामिल हैं:

• डिस्क लेखन का पता लगाने
• डिस्क रीड डिटेक्शन
• नेटवर्क की खोज
• पता लगाने पर: लॉगिंग
• पता लगाने पर: आवेदन बंद
• पता लगाने पर: ड्रॉपबॉक्स प्रविष्टि
• पता लगाने पर: ANR डायलॉग दिखाएं

इसके अतिरिक्त, स्ट्रिक्टमोड में अधिकांश स्थानों पर कई हुक होते हैं जो डिस्क तक पहुँचते हैं ( java.io.* , android.database.sqlite.* , Etc.) और नेटवर्क ( java.net.* ) जो अनुपालन की जाँच करते हैं। वर्तमान नीतियों का प्रवाह, तदनुसार प्रतिक्रिया करना।

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

कोई भी धीमा नहीं होना चाहता है

आप उन सभी स्थानों को जान सकते हैं जहां आपका एप्लिकेशन डिस्क I / O करता है, लेकिन क्या आप उन सभी स्थानों को जानते हैं जहां सिस्टम सेवाएं और प्रदाता इसे करते हैं? मैं नहीं करता। मैं ऐसे स्थानों को खोजने की कोशिश करता हूं, लेकिन मंच स्रोत कोड की मात्रा बहुत बड़ी है। हम एसडीके के लिए दस्तावेज़ीकरण में सुधार करने के लिए लगातार काम कर रहे हैं, इसमें प्रदर्शन युक्तियाँ जोड़ रहे हैं, लेकिन मैं आमतौर पर कोड में कोड तक रैंडम एक्सेस खोजने के लिए स्ट्रिक्टमोड पर भरोसा करता हूं।

मोबाइल उपकरणों पर डिस्क का उपयोग

बस एक पल! डिस्क एक्सेस के साथ क्या गलत हो सकता है? आखिरकार, सभी एंड्रॉइड डिवाइस फ्लैश मेमोरी का उपयोग करते हैं। क्या यह लगभग सुपर-फास्ट एसएसडी है जिसमें कोई हिलने वाला भाग नहीं है? क्या मुझे इसकी चिंता नहीं करनी चाहिए? दुर्भाग्य से, नहीं।

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

उपरोक्त सभी से निष्कर्ष यह है: इस तथ्य के बावजूद कि मोबाइल उपकरणों पर फ़ाइल सिस्टम आमतौर पर तेज है, फिर भी 90% मामलों में, जब देरी होती है तो यह बहुत बड़ी होगी। इसके अलावा, अधिकांश फ़ाइल सिस्टम का प्रदर्शन मुक्त डिस्क स्थान की मात्रा में कमी के साथ घटता है। (Google I / O Zippy Android ऐप से स्लाइड देखें)

आवेदन मुख्य धागा

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

यदि आप 60 एफपीएस पर एनीमेशन शुरू करना चाहते हैं और घटना अचानक आग लग जाती है (मुख्य धागे में भी), तो आपके पास इस घटना पर प्रतिक्रिया देने वाले कोड को चलाने के लिए 16 एमएस है। यदि आप 16 से अधिक एमएस खर्च करते हैं, उदाहरण के लिए, डिस्क पर लिखने के ऑपरेशन के कारण, आपको एक लटका मिलेगा। आमतौर पर, डिस्क एक्सेस में 16 एमएस की तुलना में काफी कम समय लगता है, लेकिन कभी-कभी यह मामला नहीं हो सकता है। उदाहरण के लिए, YAFFS फ़ाइल सिस्टम के मामले में, यदि आप प्रतीक्षा करते हैं, तो फ़ाइल सिस्टम संसाधन को किसी अन्य प्रक्रिया से मुक्त किया जाता है जो वर्तमान में लिखने की प्रक्रिया के बीच में है।

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

स्ट्रिक्टमोड चालू करें

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

उदाहरण के लिए, आप इसे onCreate() एप्लिकेशन या घटक के onCreate() में शामिल कर सकते हैं:

  public void onCreate() { if (DEVELOPER_MODE) { StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectDiskReads() .detectDiskWrites() .detectNetwork() .penaltyLog() .build()); } super.onCreate(); } 

या बस:

  public void onCreate() { if (DEVELOPER_MODE) { StrictMode.enableDefaults(); } super.onCreate(); } 

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

स्ट्रिक्टमोड विश्लेषण

यदि आप डिफ़ॉल्ट रूप से penaltyLog() उपयोग करते हैं, तो बस adb logcat चलाएं और टर्मिनल आउटपुट पढ़ें। किसी भी नीति का उल्लंघन आपके कंसोल में हो जाएगा।

यदि आप कोड में संदेहास्पद स्थानों को ढूंढना चाहते हैं, तो penaltyDropbox () सक्षम करें, और वे स्ट्रिक्टमोड ड्रॉपबॉक्समैनगर को अपना आउटपुट DropBoxManager , जहां से बाद में आप इसे adb shell dumpsys dropbox data_app_strictmode --print का उपयोग करके निकाल सकते हैं

चिकनाई बढ़ाएं

स्ट्रीम और j ava.util.concurrent.* , आपके पास कुछ Android API, जैसे Handler , AsyncTask , AsyncQueryHandler और IntentService का उपयोग करने का विकल्प है।

हमारा अनुभव

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

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

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

जिन उपयोगकर्ताओं ने Froyo से जिंजरब्रेड में स्विच किया, वे हैरान थे कि उनका सिस्टम कितना तेज़ हो गया है। Chrome टीम के हमारे मित्रों ने भी हाल ही में कुछ इसी तरह का जोड़ा है। बेशक, स्ट्रिक्टमोड सिस्टम को गति देने से जुड़े सभी गौरव को नहीं ले सकता है, नए कचरा कलेक्टर ने भी इसमें एक बड़ी भूमिका निभाई है।

आगे क्या है?

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