सबसे आम Android ऑप्टिमाइज़ेशन मिथक का पर्दाफाश

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

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

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

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

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

Swap

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

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

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

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

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

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

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

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

Seeder - Android 3.0 के बाद से पुराना

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

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

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

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

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

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

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

Odex

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

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

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

Lowmemorykiller ट्विक्स

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

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

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

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

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

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

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

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

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

I/O ट्विक्स

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

echo 0 > $i/queue/rotational; echo 1024 > $i/queue/nr_requests;

पहली पंक्ति I/O शेड्यूलर को SSD से निपटने में निर्देश देगी, और दूसरी 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;

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

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

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

एक Android डिवाइस के लिए, इनपुट-आउटपुट में वस्तुतः कोई एप्लिकेशन प्राथमिकता नहीं है और कोई मैकेनिकल ड्राइवर नहीं है, इसलिए सबसे अच्छा प्लानर noop / FIFO-कतार है, इसलिए इस प्रकार का शेड्यूलर "ट्विक" 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 ट्विक SD कार्ड्स के लिए बढ़े हुए रीड-अहेड मान 2MB तक हैं। रीड-अहेड तंत्र मीडिया से शुरुआती डेटा रीड के लिए है, इससे पहले कि ऐप उस डेटा तक पहुंच का अनुरोध करे। तो मूल रूप से, कर्नेल यह पता लगाने की कोशिश करेगा कि भविष्य में किस डेटा की आवश्यकता होगी, और इसे RAM में प्री-लोड करेगा, जिससे रिटर्न समय कम होना चाहिए। यह कागज पर बहुत अच्छा लगता है, लेकिन रीड-अहेड एल्गोरिथ्म अधिक बार गलत होता है, जो पूरी तरह से अनावश्यक इनपुट-आउटपुट ऑपरेशन की ओर ले जाता है, न कि उच्च RAM खपत का उल्लेख करने के लिए।

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

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

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

Linux डिस्ट्रोस और Android दोनों में VM मैनेजमेंट सबसिस्टम के लिए सामान्य ट्विक मान इस तरह होंगे:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

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

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

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

sysctl -w vm.dirty_background_ratio=50 sysctl -w vm.dirty_ratio=90

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

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

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 MB RAM वाले स्मार्टफोन पर चलते हैं, दूसरा - 1 GB के साथ, और अन्य - 1 GB से अधिक के साथ। लेकिन वास्तव में डिफ़ॉल्ट सेटिंग्स को बदलने का केवल एक कारण है - बहुत धीमी आंतरिक मेमोरी या मेमोरी कार्ड वाला डिवाइस। इस मामले में चर के मूल्यों को फैलाना उचित है, यानी ऐसा कुछ बनाना:

sysctl -w vm.dirty_background_ratio=10 sysctl -w vm.dirty_ratio=60

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

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

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

यहां कुछ अतिरिक्त लोकप्रिय ऑप्टिमाइज़ेशन हैं जो Android सिस्टम और डिवाइस के आधार पर उपयोगी हो सकते हैं या नहीं:

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

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

XDA डेवलपर्स फोरम के 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