सबसे आम एंड्रॉइड ऑप्टिमाइज़ेशन मिथक डिबंक किए गए

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

यहां तक ​​​​कि "ऑप्टिमाइज़ेशन स्क्रिप्ट्स" का एक टन भी है, सभी में एक फ्लैश करने योग्य .zip जो प्रदर्शन, बैटरी जीवन और अन्य चीजों को उल्लेखनीय रूप से बढ़ाने का वादा करता है। कुछ बदलाव वास्तव में काम कर सकते हैं, लेकिन अधिकांश केवल एक प्लेसबो प्रभाव हैं, या इससे भी बदतर, वास्तव में आपके डिवाइस पर नकारात्मक प्रभाव डालते हैं।

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

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

इस Appuals विशेष लेख में, हम "अनुकूलन" के लिए कुछ सबसे सामान्य अनुशंसाओं पर प्रकाश डालेंगे। Android प्रदर्शन, और क्या वे केवल एक मिथक हैं, या डिवाइस के प्रदर्शन के लिए एक वैध ट्विक हैं।

स्वैप करें

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

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

कुछ अनुकूलन उत्साही कह सकते हैं कि स्वैप ने कोई समस्या नहीं दी, लेकिन यह प्रदर्शन को बढ़ावा देने के लिए स्वैप नहीं है - यह अंतर्निहित Android तंत्र है lowmemorykiller , जो नियमित रूप से फूली हुई, उच्च-प्राथमिकता वाली प्रक्रियाओं को नष्ट कर देगा जिनका उपयोग नहीं किया जा रहा है। LMK को विशेष रूप से कम-स्मृति स्थितियों को संभालने के लिए डिज़ाइन किया गया था, जिसे kswapd से लागू किया गया है। प्रक्रिया, और आम तौर पर उपयोगकर्ता अंतरिक्ष प्रक्रियाओं को मारता है। यह OOMkiller (आउट-ऑफ-मेमोरी किलर) से अलग है, लेकिन यह पूरी तरह से एक अलग विषय है।

मुद्दा यह है कि, उदाहरण के लिए, 1GB RAM वाला उपकरण स्वैप में आवश्यक प्रदर्शन डेटा तक कभी नहीं पहुंच सकता है, और इसलिए Android में स्वैप की बिल्कुल आवश्यकता नहीं है। इसका कार्यान्वयन केवल अंतराल से भरा है और एक गिरावट . की ओर ले जाता है प्रदर्शन में, इसे अनुकूलित करने के बजाय।

zRAM - पुराना हो चुका है और अब कुशल नहीं है

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

zRAM का उद्देश्य एंट्री-लेवल बजट-रेंज मल्टी-कोर SoCs के लिए था, जैसे कि MTK चिपसेट और 512 MB RAM का उपयोग करने वाले डिवाइस। बहुत सस्ते चीनी फोन, मूल रूप से। मूल रूप से जो zRAM करता है वह एन्क्रिप्शन स्ट्रीम के माध्यम से कर्नेल को अलग करता है।

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

सीडर - Android 3.0 से पुराना हो चुका है

Android डेवलपरों के बीच सबसे चर्चित अनुकूलन युक्तियों में से एक है seeder , और हमें यकीन है कि कोई इस विषय पर हमें गलत साबित करने का प्रयास कर सकता है - लेकिन पहले हमें सीडर के इतिहास की जांच करने की आवश्यकता है।

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

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

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

Google ने Android 3.0 के बाद इस बग को मिटा दिया, फिर भी किसी कारण से, Seeder अभी भी “अनुशंसित बदलाव” पर पॉप अप करता है Android प्रदर्शन अनुकूलन के लिए सूचियाँ। इसके अलावा, सीडर ऐप में एसईफिक्स जैसे कुछ एनालॉग हैं जिनमें सीडर की कार्यक्षमता शामिल है, चाहे वह उसी rngd का उपयोग कर रहा हो या वैकल्पिक हैव्ड , या यहां तक ​​​​कि /dev/urandom और /dev/random के बीच सिर्फ एक सिम्लिंक। यह आधुनिक Android सिस्टम के लिए बिल्कुल व्यर्थ है।

इसके व्यर्थ होने का कारण यह है कि नए Android संस्करण तीन मुख्य घटकों में /dev/random/ का उपयोग करते हैं - libcrypto , एसएसएल कनेक्शनों के एन्क्रिप्शन के लिए, एसएसएच कुंजी उत्पन्न करना, आदि। WPA_supplication/hostapd जो WEP/WPA कुंजी उत्पन्न करता है, और अंत में, EXT2/EXT3/EXT4 फ़ाइल सिस्टम बनाने में आईडी उत्पन्न करने के लिए कुछ हद तक पुस्तकालय।

तो जब सीडर या सीडर-आधारित एन्हांसमेंट आधुनिक एंड्रॉइड ऑप्टिमाइज़ेशन स्क्रिप्ट में शामिल हैं, जो हो रहा है वह एक गिरावट है डिवाइस के प्रदर्शन में, क्योंकि rngd डिवाइस को लगातार जगाएगा और CPU आवृत्ति में वृद्धि का कारण बनेगा, जो निश्चित रूप से, बैटरी की खपत को नकारात्मक रूप से प्रभावित करता है।

ओडेक्स

Android उपकरणों पर स्टॉक फर्मवेयर हमेशा odex. इसका मतलब है कि /system/app/ और /system/priv-app/ में पाए जाने वाले एपीके प्रारूप में एंड्रॉइड ऐप्स के लिए मानक पैकेज के साथ, .odex एक्सटेंशन के साथ एक ही फ़ाइल नाम हैं। ओडेक्स फाइलों में अनुकूलित बायटेकोड एप्लिकेशन होते हैं जो पहले से ही सत्यापनकर्ता और अनुकूलक वर्चुअल मशीन से गुजर चुके होते हैं, फिर एक अलग फाइल में रिकॉर्ड किए जाते हैं जैसे कि डेक्सॉप्ट उपकरण।

इसलिए ओडेक्स फाइलें वर्चुअल मशीन को ऑफलोड करने के लिए होती हैं और ओडेक्स किए गए एप्लिकेशन को लॉन्च करने की पेशकश करती हैं - नकारात्मक पक्ष पर, ओडीएक्स फाइलें फर्मवेयर में संशोधन को रोकती हैं, और अपडेट के साथ समस्याएं पैदा करती हैं, इसलिए इस कारण से कई कस्टम रोम जैसे वंशावली वितरित किए जाते हैं ODEX के बिना ।

ODEX फ़ाइलें बनाना कई तरीकों से किया जाता है, जैसे Odexer Tool का उपयोग करना - समस्या यह है कि इसका विशुद्ध रूप से एक प्लेसबो प्रभाव है। जब आधुनिक Android सिस्टम को /system निर्देशिका में odex फ़ाइलें नहीं मिलती हैं, तो सिस्टम वास्तव में उन्हें बनाएगा और उन्हें /system/dalvik-cache/ निर्देशिका में रखेगा। ठीक ऐसा ही तब हो रहा है जब, उदाहरण के लिए, आप एक नया Android संस्करण फ्लैश करते हैं और यह कुछ समय के लिए "व्यस्त, ऑप्टिमाइज़िंग एप्लिकेशन" संदेश देता है।

लोमेमोरीकिलर में बदलाव

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

लोमेमोरीकिलर . पर वापस जाने के लिए तंत्र, एंड्रॉइड सीमित मात्रा में स्मृति और स्वैप-विभाजन की कमी के साथ काम करना जारी रख सकता है। उपयोगकर्ता एप्लिकेशन लॉन्च करना और उनके बीच स्विच करना जारी रख सकता है, और सिस्टम सक्रिय कार्यों के लिए मेमोरी को खाली करने और कोशिश करने के लिए उपयोग न किए गए बैकग्राउंड ऐप्स को चुपचाप मार देगा।

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

वास्तव में, बड़ी मात्रा में मुफ्त RAM होना वास्तव में आपके डिवाइस के प्रदर्शन और बैटरी जीवन के लिए हानिकारक हो सकता है। जब ऐप्स एंड्रॉइड की रैम में स्टोर हो जाते हैं, तो उन्हें कॉल करना, उन्हें लॉन्च करना आदि बहुत आसान हो जाता है। एंड्रॉइड सिस्टम को ऐप पर स्विच करने के लिए ज्यादा संसाधनों को समर्पित करने की आवश्यकता नहीं होती है, क्योंकि यह पहले से ही मेमोरी में है।

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

तो उदाहरण के लिए, मानक रैम सीमाओं पर संचालित होता है - 4, 8, 12, 24, 32, और 40 एमबी, और जब 40 एमबी का मुफ्त स्टोरेज स्पेस भर जाता है, तो कैश्ड ऐप्स में से एक जो मेमोरी में लोड होता है लेकिन नहीं चल रहा है समाप्त कर दिया जाएगा।

तो मूल रूप से, एंड्रॉइड में हमेशा कम से कम 40 एमबी उपलब्ध मेमोरी होगी, जो कि lowmemorykiller से पहले एक और एप्लिकेशन को समायोजित करने के लिए पर्याप्त है। अपनी सफाई प्रक्रिया शुरू करता है - जिसका अर्थ है कि एंड्रॉइड हमेशा उपयोगकर्ता अनुभव में हस्तक्षेप किए बिना उपलब्ध रैम की अधिकतम मात्रा का उपयोग करने की पूरी कोशिश करेगा।

अफसोस की बात है कि कुछ होमब्रू उत्साही लोगों ने सिफारिश की है कि एलएमके शुरू होने से पहले मान को 100 एमबी तक बढ़ाया जाए। अब उपयोगकर्ता वास्तव में खो जाएगा RAM (100 - 40 =60), इसलिए बैक-एंड ऐप्स को स्टोर करने के लिए इस स्थान का उपयोग करने के बजाय, सिस्टम मेमोरी की इस मात्रा को मुफ़्त रखेगा। , जिसका कोई उद्देश्य नहीं है।

एलकेएम ट्यूनिंग उपयोगी हो सकती है 512 RAM वाले बहुत पुराने उपकरणों के लिए, लेकिन अब उनका मालिक कौन है? 2GB आधुनिक "बजट रेंज" है, यहां तक ​​​​कि 4GB रैम डिवाइस भी इन दिनों "मिडिल-रेंज" के रूप में देखे जा रहे हैं, इसलिए LMK ट्वीक वास्तव में पुराने और बेकार हैं।

I/O में बदलाव

Android के लिए बहुत सारी अनुकूलन स्क्रिप्ट में आपको अक्सर ऐसे बदलाव मिलेंगे जो I/O सबसिस्टम को संबोधित करते हैं। उदाहरण के लिए, थंडरबोल्ट पर एक नज़र डालते हैं! स्क्रिप्ट, जिसमें ये पंक्तियाँ हैं:

echo 0 > $i/queue/rotational;

echo 1024 > $i/queue/nr_requests;

पहली पंक्ति SSD से निपटने में I/O अनुसूचक निर्देश देगी, और दूसरी कतार I/O के अधिकतम आकार को 128 से 1024 तक बढ़ा देती है - क्योंकि $i चर में ब्लॉक उपकरणों के पेड़ के लिए पथ होता है /sys, और स्क्रिप्ट लूप में चलती है।

उसके बाद, आपको CFQ अनुसूचक से संबंधित एक पंक्ति मिलती है:

echo 1 > $i/queue/iosched/back_seek_penalty;

echo 1 > $i/queue/iosched/low_latency;

echo 1 > $i/queue/iosched/slice_idle;

इसके बाद और भी पंक्तियाँ आती हैं जो अन्य योजनाकारों से संबंधित हैं, लेकिन अंततः, पहले दो आदेश व्यर्थ हैं क्योंकि:

एक आधुनिक लिनक्स कर्नेल यह समझने में सक्षम है कि वह डिफ़ॉल्ट रूप से किस प्रकार के भंडारण माध्यम के साथ काम कर रहा है।

एक लंबी इनपुट-आउटपुट कतार (जैसे 1024) आधुनिक एंड्रॉइड डिवाइस पर बेकार है, वास्तव में डेस्कटॉप पर भी इसका कोई मतलब नहीं है - यह वास्तव में केवल हैवी ड्यूटी सर्वर पर अनुशंसित है . आपका फ़ोन भारी शुल्क वाला Linux सर्वर नहीं है.

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

for i in /sys/block/mmc*; do

echo noop > $i/queue/scheduler

echo 0 > $i/queue/iostats

done

यह I/O आँकड़ों के संचय से सभी ड्राइव के लिए noop अनुसूचक को सक्षम करेगा, जिसका प्रदर्शन पर सकारात्मक प्रभाव होना चाहिए, हालांकि एक बहुत छोटा और लगभग पूरी तरह से नगण्य।

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

RAID-सरणी में 1 - 8 एमबी के बीच के उच्च रीड-फ़ॉरवर्ड मानों की अनुशंसा की जाती है, लेकिन Android उपकरणों के लिए, 128 KB के डिफ़ॉल्ट मान को छोड़ देना ही सबसे अच्छा है।

वर्चुअल मेमोरी मैनेजमेंट सिस्टम में बदलाव

एक अन्य सामान्य "अनुकूलन" तकनीक वर्चुअल मेमोरी प्रबंधन सबसिस्टम को ट्यून कर रही है। यह आमतौर पर केवल दो कर्नेल चर, vm.dirty_background_ratio और vm.dirty_ratio को लक्षित करता है, जो "गंदे" डेटा को संग्रहीत करने के लिए बफर के आकार को समायोजित करने के लिए हैं। गंदा डेटा आमतौर पर डेटा होता है जिसे डिस्क पर लिखा गया है, लेकिन अभी भी मेमोरी में और डिस्क पर लिखे जाने की प्रतीक्षा में है।

Linux डिस्ट्रोस और Androis दोनों में VM प्रबंधन सबसिस्टम के लिए विशिष्ट ट्वीक मान इस प्रकार होंगे:

vm.dirty_background_ratio = 10

vm.dirty_ratio = 20

तो यह क्या करने की कोशिश करता है कि जब गंदा डेटा बफर रैम की कुल मात्रा का 10% होता है, तो यह जागता है pdflush प्रवाह और डिस्क पर डेटा लिखना शुरू कर देता है - यदि डिस्क पर डेटा रिकॉर्ड करने का कार्य बहुत तीव्र होगा , बफ़र बढ़ता रहेगा, और जब यह उपलब्ध RAM के 20% तक पहुँच जाता है, तो सिस्टम बिना प्री-बफ़र के - सिंक्रोनस मोड में बाद के राइट ऑपरेशन पर स्विच हो जाएगा। इसका मतलब है कि डिस्क पर लिखने का काम ब्लॉक किया जाएगा, जब तक कि डिस्क पर डेटा नहीं लिखा जाता (उर्फ 'लैग')।

आपको जो समझना चाहिए वह यह है कि भले ही बफर आकार 100% तक न पहुंचे , सिस्टम स्वचालित रूप से 30 सेकंड के बाद pdflush में किक करेगा। 10/20 का संयोजन काफी उचित है, उदाहरण के लिए 1GB RAM वाले डिवाइस पर यह 100/200MB RAM के बराबर होगा, जो बर्स्ट रिकॉर्ड के मामले में पर्याप्त से अधिक है जहां गति अक्सर सिस्टम NAND में स्पीड रिकॉर्ड से कम होती है। -मेमोरी, या एसडी-कार्ड, जैसे ऐप्स इंस्टॉल करते समय या कंप्यूटर से फाइल कॉपी करते समय।

किसी कारण से, स्क्रिप्ट लेखक इस मूल्य को बेतुके दरों पर और भी अधिक बढ़ाने की कोशिश करते हैं। उदाहरण के लिए हम Xplix . में पा सकते हैं ऑप्टिमाइज़ेशन स्क्रिप्ट की दर 50/90 जितनी अधिक है।

sysctl -w vm.dirty_background_ratio=50

sysctl -w vm.dirty_ratio=90

1 जीबी मेमोरी वाले डिवाइस पर, यह गंदे बफर पर 500/900 एमबी तक की सीमा निर्धारित करता है, जो एंड्रॉइड डिवाइस के लिए पूरी तरह से बेकार है, क्योंकि यह केवल डिस्क पर लगातार रिकॉर्डिंग के तहत काम करेगा। - कुछ ऐसा जो केवल भारी Linux सर्वर पर होता है।

थंडरबोल्ट! स्क्रिप्ट अधिक उचित मूल्य का उपयोग करती है, लेकिन कुल मिलाकर, यह अभी भी काफी अर्थहीन है:

if [ "$mem" -lt 524288 ];then

sysctl -w vm.dirty_background_ratio=15;

sysctl -w vm.dirty_ratio=30;

elif [ "$mem" -lt 1049776 ];then

sysctl -w vm.dirty_background_ratio=10;

sysctl -w vm.dirty_ratio=20;

else

sysctl -w vm.dirty_background_ratio=5;

sysctl -w vm.dirty_ratio=10;

fi;

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

sysctl -w vm.dirty_background_ratio=10

sysctl -w vm.dirty_ratio=60

फिर, जब कोई सर्ज सिस्टम डिस्क पर डेटा रिकॉर्ड किए बिना ऑपरेशन लिखता है, तो आखिरी तक सिंक्रोनस मोड पर स्विच नहीं होगा, जो रिकॉर्डिंग के दौरान अनुप्रयोगों को अंतराल को कम करने की अनुमति देगा।

अतिरिक्त बेकार बदलाव और प्रदर्शन ट्यूनिंग

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

यहां कुछ अतिरिक्त लोकप्रिय अनुकूलन दिए गए हैं जो Android सिस्टम और डिवाइस के आधार पर उपयोगी हो भी सकते हैं और नहीं भी।

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

बेकार सेटिंग build.prop

XDA Developers फोरम से LaraCraft304 ने एक अध्ययन किया और पाया कि "विशेषज्ञों" के उपयोग के लिए अनुशंसित /system/build.prop सेटिंग्स की एक प्रभावशाली संख्या स्रोत AOSP और CyanogenMod में मौजूद नहीं है। ये रही सूची:

ro.ril.disable.power.collapse

ro.mot.eri.losalert.delay

ro.config.hw_fast_dormancy

ro.config.hw_power_saving

windowsmgr.max_events_per_sec

persist.cust.tel.eons

ro.max.fling_velocity

ro.min.fling_velocity

ro.kernel.checkjni

dalvik.vm.verify-bytecode

debug.performance.tuning

video.accelerate.hw

ro.media.dec.jpeg.memcap

ro.config.nocheckin

profiler.force_disable_ulog

profiler.force_disable_err_rpt

ersist.sys.shutdown.mode

ro.HOME_APP_ADJ