చాలా సాధారణ Android ఆప్టిమైజేషన్ అపోహలు తొలగించబడ్డాయి

అందువల్ల, ఆల్ ఇన్ వన్ ఆప్టిమైజేషన్ స్క్రిప్ట్‌లు చాలావరకు ఒకే పద్ధతులను ఉపయోగిస్తున్నాయి, వాటిలో కొన్ని పూర్తిగా పాతవి లేదా దీర్ఘకాలంలో హానికరం. సారాంశంలో, మెజారిటీ “ఆల్ ఇన్ వన్” ఆప్టిమైజేషన్ స్క్రిప్ట్‌లు చెంపదెబ్బతో కూడిన సిఫారసు చేయబడిన ట్యూనింగ్‌లు తప్ప మరొకటి కాదు, ఈ ఆప్టిమైజేషన్‌లు “ఎలా పనిచేస్తాయి లేదా ఎందుకు పని చేస్తాయి - వినియోగదారులు అప్పుడు స్క్రిప్ట్‌లను ఫ్లాష్ చేస్తారు మరియు వారి పనితీరు అకస్మాత్తుగా వేగంగా ఉందని పేర్కొన్నారు ( వాస్తవానికి, పనితీరు పెరుగుదలకు కారణమైన వారి పరికరాన్ని రీబూట్ చేయడం చాలా సులభమైన చర్య , పరికరం యొక్క RAM లోని ప్రతిదీ శుభ్రం అవుతుంది కాబట్టి) .

ఈ యాప్యువల్స్ ప్రత్యేకమైన కథనంలో, “కోసం మేము చాలా సాధారణ సిఫార్సులను హైలైట్ చేస్తాము. ఆప్టిమైజ్ చేస్తోంది ” Android పనితీరు మరియు అవి కేవలం పురాణమా, లేదా పరికర పనితీరు కోసం చట్టబద్ధమైన సర్దుబాటు అయినా.

స్వాప్ చేయండి

పురాణ జాబితాలో అగ్రస్థానంలో ఆండ్రాయిడ్ స్వాప్ ఉంది - ఇది ఆండ్రాయిడ్ ఆప్టిమైజేషన్‌గా భావించే విషయంలో చాలా అసంబద్ధం. స్వాప్స్ ప్రధాన ఉద్దేశ్యం పేజింగ్ ఫైల్‌ను సృష్టించడం మరియు కనెక్ట్ చేయడం, ఇది మెమరీలో నిల్వ స్థలాన్ని ఖాళీ చేస్తుంది. ఇది సరైనదిగా అనిపిస్తుంది కాగితంపై , కానీ ఇది నిజంగా వర్తిస్తుంది a సర్వర్ , ఇది దాదాపు ఇంటరాక్టివిటీని కలిగి లేదు.

మీరు మీ Android ఫోన్ స్వాప్‌ను క్రమం తప్పకుండా ఉపయోగించినప్పుడు, ఇది కాష్ దాటిపోయే విషయాల నుండి ఉత్పన్నమయ్యే తీవ్రమైన లాగ్‌లకు దారితీస్తుంది. ఉదాహరణకు, ఒక అనువర్తనం గ్రాఫిక్‌ను ప్రదర్శించడానికి ప్రయత్నిస్తే, అది స్వాప్‌లో నిల్వ చేయబడుతుంది, ఇది ఇప్పుడు మరొక అనువర్తనంతో డేటా స్వాప్‌ను ఉంచడం ద్వారా స్థలాన్ని ఖాళీ చేసిన తర్వాత డిస్క్‌ను తిరిగి లోడ్ చేయాల్సి ఉంటుంది. ఇది నిజంగా గజిబిజి.

కొంతమంది ఆప్టిమైజేషన్ ts త్సాహికులు స్వాప్ ఎటువంటి సమస్యలను ఇవ్వలేదని చెప్పవచ్చు, కానీ ఇది పనితీరును పెంచే స్వాప్ కాదు - ఇది అంతర్నిర్మిత Android విధానం lowmemorykiller , ఇది ఉపయోగించని ఉబ్బిన, అధిక-ప్రాధాన్యత ప్రక్రియలను క్రమం తప్పకుండా చంపుతుంది. తక్కువ-మెమరీ పరిస్థితులను నిర్వహించడానికి LMK ప్రత్యేకంగా రూపొందించబడింది, దీని నుండి ఉపయోగించబడుతుంది kswapd ప్రాసెస్, మరియు సాధారణంగా యూజర్ స్పేస్ ప్రాసెస్‌లను చంపుతుంది. ఇది భిన్నంగా ఉంటుంది OOM కిల్లర్ (మెమరీ వెలుపల కిల్లర్), కానీ ఇది పూర్తిగా వేరే అంశం.

విషయం ఏమిటంటే, ఉదాహరణకు, 1GB RAM ఉన్న పరికరం ఒక స్వాప్‌లో అవసరమైన పనితీరు డేటాను ఎప్పటికీ చేరుకోదు, కాబట్టి Android లో స్వాప్ ఖచ్చితంగా అవసరం లేదు. దీని అమలు కేవలం మందగింపుతో నిండి ఉంటుంది మరియు a కు దారితీస్తుంది అధోకరణం పనితీరులో, ఆప్టిమైజ్ చేయకుండా.

zRAM - పాతది మరియు ఎక్కువ సమయం లేదు

zRAM అనేది పరికర ఆప్టిమైజేషన్ కోసం నిరూపితమైన మరియు ప్రభావవంతమైన పద్ధతి పాత పరికరాలు - కిట్‌కాట్ ఆధారిత పరికరాలు 512 MB ర్యామ్‌లో మాత్రమే పనిచేస్తున్నాయని అనుకోండి. కొంతమంది ఇప్పటికీ ఆప్టిమైజేషన్ స్క్రిప్ట్స్‌లో zRAM ట్వీక్‌లను కలిగి ఉన్నారు, లేదా zRAM ను ఒకరకమైన ఆధునిక ఆప్టిమైజేషన్ సర్దుబాటుగా సిఫారసు చేస్తారు, సాధారణంగా ప్రజలు తాజా కార్యాచరణ ప్రోటోకాల్‌లను అనుసరించరు.

MTK చిప్‌సెట్లను ఉపయోగించే పరికరాలు మరియు 512 MB RAM వంటి ఎంట్రీ-లెవల్ బడ్జెట్-శ్రేణి మల్టీ-కోర్ SoC ల కోసం zRAM ఉద్దేశించబడింది. చాలా చౌకైన చైనీస్ ఫోన్లు, ప్రాథమికంగా. ZRAM ప్రాథమికంగా ఏమి చేస్తుంది, ఎన్క్రిప్షన్ స్ట్రీమ్ ద్వారా కెర్నల్ ను వేరు చేస్తుంది.

పాత పరికరాల్లో zRAM ఉపయోగించినప్పుడు a సింగిల్ కోర్ , అటువంటి పరికరాల్లో zRAM సిఫారసు చేయబడినప్పటికీ, పెద్ద మొత్తంలో లాగ్‌లు పెరుగుతాయి. ఇది KSM టెక్నాలజీతో కూడా జరుగుతుంది ( కెర్నల్ అదే పేజీ విలీనం) ఇది ఖాళీ స్థలానికి ఒకేలా మెమరీ పేజీలను మిళితం చేస్తుంది. ఇది వాస్తవానికి గూగుల్ సిఫారసు చేసింది, కాని పాత పరికరాల్లో ఎక్కువ లాగ్‌లకు దారితీస్తుంది, ఎందుకంటే నకిలీ పేజీల కోసం శోధించడానికి నిరంతరం క్రియాశీల కోర్ థీడ్స్ మెమరీ నుండి నిరంతరం నడుస్తున్నాయి. సాధారణంగా, ఆప్టిమైజేషన్ సర్దుబాటును అమలు చేయడానికి ప్రయత్నించడం పరికరాన్ని మరింత నెమ్మదిస్తుంది, వ్యంగ్యంగా.

సీడర్ - ఆండ్రాయిడ్ 3.0 నుండి పాతది

ఆండ్రాయిడ్ దేవ్స్‌లో అత్యంత చర్చించబడిన ఆప్టిమైజేషన్ చిట్కాలలో ఒకటి దేవదారు , మరియు ఈ అంశంపై ఎవరైనా మమ్మల్ని తప్పుగా నిరూపించడానికి ప్రయత్నించవచ్చని మేము ఖచ్చితంగా అనుకుంటున్నాము - కాని మొదట మేము సీడర్ చరిత్రను పరిశీలించాలి.

Android కోసం సీడర్ అనువర్తనం

అవును, ఇన్‌స్టాలేషన్ తర్వాత మెరుగైన Android పనితీరును ప్రకటించే పెద్ద సంఖ్యలో నివేదికలు ఉన్నాయి చాలా పాత Android పరికరాలు . ఏదేమైనా, ప్రజలు ఏ కారణం చేతనైనా నమ్ముతారు అంటే ఇది కూడా వర్తించే ఆప్టిమైజేషన్ ఆధునిక Android పరికరాలు , ఇది ఖచ్చితంగా అసంబద్ధం. సీడర్ ఇప్పటికీ నిర్వహించబడుతోంది మరియు ' ఆధునిక ” లాగ్ రిడక్షన్ సాధనం తప్పుడు సమాచారానికి ఒక ఉదాహరణ - ఇది సీడర్ యొక్క డెవలపర్ యొక్క తప్పు కానప్పటికీ, వారి ప్లే స్టోర్ పేజీ కూడా ఆండ్రాయిడ్ 4.0+ తర్వాత సీడర్ తక్కువ ప్రభావవంతంగా ఉంటుందని పేర్కొంది. ఇంకా ఏ కారణం చేతనైనా, ఆధునిక ఆండ్రాయిడ్ సిస్టమ్స్ కోసం ఆప్టిమైజేషన్ చర్చలలో సీడర్ ఇంకా ముందుకు వస్తుంది.

ఆండ్రాయిడ్ 3.0 కోసం సీడర్ ప్రాథమికంగా ఏమి చేస్తుంది అంటే ఎంట్రోపీని సంపాదించడానికి ఆండ్రాయిడ్ రన్‌టైమ్ చురుకుగా / dev / random / file ని ఉపయోగిస్తుంది. / Dev / random / buffer అస్థిరంగా మారుతుంది మరియు అవసరమైన డేటాను నింపే వరకు సిస్టమ్ నిరోధించబడుతుంది - Android పరికరంలోని వివిధ సెన్సార్లు మరియు బటన్ల వంటి చిన్న విషయాలను ఆలోచించండి.

సీడర్ రచయిత లైనక్స్-దెయ్యాన్ని తీసుకున్నాడు rngd , మరియు Android యొక్క inastroil కోసం సంకలనం చేయబడింది, తద్వారా ఇది యాదృచ్ఛిక డేటాను చాలా వేగంగా మరియు మరింత able హించదగిన / dev / urandom మార్గం నుండి తీసుకుంటుంది మరియు / dev / random / అయిపోయినట్లు అనుమతించకుండా వాటిని ప్రతి సెకనులో dev / random / లో విలీనం చేస్తుంది. దీని ఫలితంగా ఆండ్రాయిడ్ సిస్టమ్ ఎంట్రోపీ లేకపోవడాన్ని అనుభవించలేదు మరియు చాలా సున్నితంగా ప్రదర్శించింది.

ఆండ్రాయిడ్ 3.0 తర్వాత గూగుల్ ఈ బగ్‌ను పగులగొట్టింది, ఇంకా కొన్ని కారణాల వల్ల, సీడర్ ఇంకా పుంజుకుంటుంది “సిఫార్సు చేసిన ట్వీక్స్” Android పనితీరు ఆప్టిమైజేషన్ కోసం జాబితాలు. ఇంకా, సీడర్ అనువర్తనం sEFix వంటి కొన్ని అనలాగ్‌లను కలిగి ఉంది, వీటిలో సీడర్ యొక్క కార్యాచరణ కూడా ఉంది rngd లేదా ప్రత్యామ్నాయం హాగ్డ్ , లేదా / dev / urandom మరియు / dev / random మధ్య సిమ్‌లింక్ కూడా. ఆధునిక ఆండ్రాయిడ్ సిస్టమ్‌లకు ఇది ఖచ్చితంగా అర్ధం కాదు.

దీని అర్ధం ఏమిటంటే, క్రొత్త Android సంస్కరణలు / dev / random / ను మూడు ప్రధాన భాగాలలో ఉపయోగిస్తాయి - లిబ్క్రిప్టో , SSL కనెక్షన్ల గుప్తీకరణ కొరకు, SSH కీలను ఉత్పత్తి చేయటం మొదలైనవి. WEP / WPA కీలను ఉత్పత్తి చేసే WPA_supplication / hostapd, చివరకు, EXT2 / EXT3 / EXT4 ఫైల్ సిస్టమ్‌లను సృష్టించడంలో ID ని ఉత్పత్తి చేయడానికి కొన్ని లైబ్రరీలు.

అయితే ఎప్పుడు సీడర్ లేదా సీడర్-ఆధారిత మెరుగుదలలు ఆధునిక ఆండ్రాయిడ్ ఆప్టిమైజేషన్ స్క్రిప్ట్స్‌లో చేర్చబడ్డాయి, ఏమి జరుగుతుందో a అధోకరణం పరికర పనితీరులో, ఎందుకంటే rngd పరికరాన్ని నిరంతరం మేల్కొల్పుతుంది మరియు CPU ఫ్రీక్వెన్సీ పెరుగుదలకు కారణమవుతుంది, ఇది బ్యాటరీ వినియోగాన్ని ప్రతికూలంగా ప్రభావితం చేస్తుంది.

ఓడెక్స్

ఆండ్రాయిడ్ పరికరాల్లోని స్టాక్ ఫర్మ్‌వేర్ చాలా చక్కని ఎల్లప్పుడూ ఓడెక్స్. దీని అర్థం / సిస్టమ్ / అనువర్తనం / మరియు / సిస్టమ్ / ప్రైవేట్-అనువర్తనం / లో కనిపించే APK ఆకృతిలో Android అనువర్తనాల ప్రామాణిక ప్యాకేజీతో పాటు .odex పొడిగింపుతో ఒకే ఫైల్ పేర్లు ఉంటాయి. ఓడెక్స్ ఫైళ్ళలో ఆప్టిమైజ్ చేయబడిన బైట్‌కోడ్ అనువర్తనాలు ఉన్నాయి, ఇవి ఇప్పటికే వాలిడేటర్ మరియు ఆప్టిమైజర్ వర్చువల్ మెషీన్ గుండా వెళ్ళాయి, తరువాత వేరే ఫైల్‌లో రికార్డ్ చేయబడతాయి డెక్సాప్ట్ సాధనం.

కాబట్టి ఓడెక్స్ ఫైల్స్ వర్చువల్ మెషీన్ను ఆఫ్‌లోడ్ చేయడానికి మరియు ఓడెక్స్డ్ అప్లికేషన్ యొక్క వేగవంతమైన లాంచ్‌ను అందించడానికి ఉద్దేశించినవి - ఇబ్బందిలో, ఒడెక్స్ ఫైల్స్ ఫర్మ్‌వేర్‌లో మార్పులను నిరోధిస్తాయి మరియు నవీకరణలతో సమస్యలను సృష్టిస్తాయి, కాబట్టి ఈ కారణంగా లినేజిఓఎస్ వంటి అనేక కస్టమ్ ROM లు పంపిణీ చేయబడతాయి ODEX లేకుండా .

ఒడెక్స్ ఫైళ్ళను రూపొందించడం ఒడెక్సర్ సాధనాన్ని ఉపయోగించడం వంటి అనేక విధాలుగా జరుగుతుంది - సమస్య ఏమిటంటే ఇది పూర్తిగా ప్లేసిబో ప్రభావం. ఆధునిక ఆండ్రాయిడ్ సిస్టమ్ / సిస్టమ్ డైరెక్టరీలో ఓడెక్స్ ఫైళ్ళను కనుగొననప్పుడు, సిస్టమ్ వాస్తవానికి వాటిని సృష్టించి / సిస్టమ్ / డాల్విక్-కాష్ / డైరెక్టరీలో ఉంచుతుంది. ఉదాహరణకు, మీరు క్రొత్త Android సంస్కరణను ఫ్లాష్ చేసినప్పుడు ఇది ఖచ్చితంగా జరుగుతోంది మరియు ఇది కొంతకాలం “బిజీ, ఆప్టిమైజింగ్ అప్లికేషన్స్” సందేశాన్ని ఇస్తుంది.

లోమెమోరికిల్లర్ ట్వీక్స్

Android లో మల్టీ టాస్కింగ్ ఇతర మొబైల్ ఆపరేటింగ్ సిస్టమ్‌ల నుండి భిన్నంగా ఉంటుంది, ఇది క్లాసికల్ మోడల్‌పై ఆధారపడి ఉంటుంది, ఇక్కడ అనువర్తనాలు నేపథ్యంలో నిశ్శబ్దంగా పనిచేస్తాయి మరియు నేపథ్య అనువర్తనాల సంఖ్యపై ఎటువంటి పరిమితులు లేవు ( డెవలపర్ ఎంపికలలో ఒకటి సెట్ చేయకపోతే, ఇది సాధారణంగా దీనికి వ్యతిరేకంగా సిఫార్సు చేయబడింది) - ఇంకా, నేపథ్య అమలుకు పరివర్తన యొక్క కార్యాచరణ ఆపివేయబడదు, అయినప్పటికీ తక్కువ మెమరీ పరిస్థితులలో నేపథ్య అనువర్తనాలను చంపే హక్కు సిస్టమ్‌కు ఉంది ( ఈ గైడ్‌లో ఇంతకు ముందు లోమెమోరీకిల్లర్ మరియు అవుట్-మెమరీ కిల్లర్ గురించి మేము ఎక్కడ మాట్లాడామో చూడండి) .

తిరిగి వెళ్ళడానికి lowmemorykiller యంత్రాంగం, ఆండ్రాయిడ్ పరిమిత మెమరీ మరియు స్వాప్-విభజన లేకపోవడంతో పనిచేయడం కొనసాగించవచ్చు. వినియోగదారు అనువర్తనాలను ప్రారంభించడం మరియు వాటి మధ్య మారడం కొనసాగించవచ్చు మరియు క్రియాశీల పనుల కోసం మెమరీని ఖాళీ చేయడానికి సిస్టమ్ ఉపయోగించని నేపథ్య అనువర్తనాలను నిశ్శబ్దంగా చంపుతుంది.

ప్రారంభ రోజుల్లో ఇది ఆండ్రాయిడ్‌కు బాగా ఉపయోగపడింది, అయితే కొన్ని కారణాల వల్ల ఇది టాస్క్-కిల్లర్ అనువర్తనాల రూపంలో ప్రాచుర్యం పొందింది, ఇవి సాధారణంగా ప్రయోజనకరమైన వాటి కంటే ఎక్కువ హానికరం. టాస్క్-కిల్లర్ అనువర్తనాలు సెట్ వ్యవధిలో మేల్కొంటాయి, లేదా వినియోగదారు చేత నడుపబడుతున్నాయి మరియు పెద్ద మొత్తంలో ర్యామ్‌ను విడిపించేలా కనిపిస్తాయి, ఇది సానుకూలంగా కనిపిస్తుంది - మరింత ఉచిత RAM అంటే వేగవంతమైన పరికరం, సరియైనదేనా? ఏదేమైనా, Android విషయంలో ఇది సరిగ్గా లేదు.

వాస్తవానికి, పెద్ద మొత్తంలో ఉచిత RAM కలిగి ఉండటం మీ పరికర పనితీరు మరియు బ్యాటరీ జీవితానికి హానికరం. అనువర్తనాలు Android యొక్క RAM లో నిల్వ చేయబడినప్పుడు, వాటిని పిలవడం, వాటిని ప్రారంభించడం చాలా సులభం. Android సిస్టమ్ అనువర్తనానికి మారడానికి ఎక్కువ వనరులను కేటాయించాల్సిన అవసరం లేదు, ఎందుకంటే ఇది ఇప్పటికే మెమరీలో ఉంది.

ఈ కారణంగా, టాస్క్-కిల్లర్స్ ఒకప్పుడు ఉన్నంత ప్రజాదరణ పొందలేదు, అయినప్పటికీ ఆండ్రాయిడ్ ఆరంభకులు కొన్ని కారణాల వల్ల వారిపై ఆధారపడతారు ( సమాచారం లేకపోవడం, పాపం) . దురదృష్టవశాత్తు, కొత్త ధోరణి టాస్క్-కిల్లర్లను భర్తీ చేసింది, యొక్క ధోరణి lowmemorykiller మెకానిజం ట్యూనింగ్స్. ఇది ఉదాహరణకు ఉంటుంది MinFreeManager అనువర్తనం, మరియు సిస్టమ్ నేపథ్య అనువర్తనాలను చంపడం ప్రారంభించడానికి ముందు RAM ఓవర్‌హెడ్‌ను పెంచడం ప్రధాన ఆలోచన.

ఉదాహరణకు, ప్రామాణిక RAM సరిహద్దుల వద్ద పనిచేస్తుంది - 4, 8, 12, 24, 32, మరియు 40 Mb, మరియు 40 MB యొక్క ఉచిత నిల్వ స్థలం నిండినప్పుడు, మెమరీలోకి లోడ్ చేయబడిన కాష్ చేసిన అనువర్తనాల్లో ఒకటి కానీ అమలులో లేదు రద్దు చేయబడుతుంది.

కాబట్టి ప్రాథమికంగా, Android ఎల్లప్పుడూ కనీసం 40 MB అందుబాటులో ఉన్న మెమరీని కలిగి ఉంటుంది, ఇది ముందు మరో అనువర్తనానికి అనుగుణంగా సరిపోతుంది lowmemorykiller దాని శుభ్రపరిచే ప్రక్రియను ప్రారంభిస్తుంది - అంటే వినియోగదారు అనుభవంతో జోక్యం చేసుకోకుండా అందుబాటులో ఉన్న RAM యొక్క గరిష్ట మొత్తాన్ని ఉపయోగించడానికి Android ఎల్లప్పుడూ ఉత్తమంగా చేస్తుంది.

పాపం, కొంతమంది హోమ్‌బ్రూ ts త్సాహికులు సిఫారసు చేయడం ప్రారంభించినది ఏమిటంటే, విలువను LMK కిక్ చేయడానికి ముందు 100 MB కి పెంచాలి. ఇప్పుడు వినియోగదారు వాస్తవానికి కోల్పోతారు RAM (100 - 40 = 60), కాబట్టి బ్యాక్ ఎండ్ అనువర్తనాలను నిల్వ చేయడానికి ఈ స్థలాన్ని ఉపయోగించకుండా, సిస్టమ్ ఈ మెమరీని ఉంచుతుంది ఉచితం , దాని కోసం ఎటువంటి ప్రయోజనం లేకుండా.

LKM ట్యూనింగ్ ఉపయోగకరంగా ఉంటుంది 512 RAM ఉన్న చాలా పాత పరికరాల కోసం, కానీ ఇకపై ఎవరు కలిగి ఉంటారు? 2GB అనేది ఆధునిక “బడ్జెట్ పరిధి”, 4GB RAM పరికరాలు కూడా ఈ రోజుల్లో “మధ్య-శ్రేణి” గా చూస్తున్నాయి, కాబట్టి LMK ట్వీక్‌లు నిజంగా పాతవి మరియు పనికిరానివి.

I / O ట్వీక్స్

Android కోసం చాలా ఆప్టిమైజేషన్ స్క్రిప్ట్‌లలో, మీరు తరచుగా I / O ఉపవ్యవస్థను పరిష్కరించే ట్వీక్‌లను కనుగొంటారు. ఉదాహరణకు, పరిశీలించండి పిడుగు! స్క్రిప్ట్, ఈ పంక్తులను కలిగి ఉంది:

echo 0> $ i / క్యూ / భ్రమణ; echo 1024> $ i / queue / nr_requests;

మొదటి పంక్తి ఒక SSD తో వ్యవహరించడంలో I / O షెడ్యూలర్ సూచనలను ఇస్తుంది, మరియు రెండవది క్యూ I / O యొక్క గరిష్ట పరిమాణాన్ని 128 నుండి 1024 కు పెంచుతుంది - ఎందుకంటే variable 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 వంటివి) ఆధునిక Android పరికరంలో పనికిరానిది, వాస్తవానికి డెస్క్‌టాప్‌లో కూడా ఇది అర్థరహితం - ఇది నిజంగా మాత్రమే సిఫార్సు చేయబడింది హెవీ డ్యూటీ సర్వర్లు . మీ ఫోన్ హెవీ డ్యూటీ లైనక్స్ సర్వర్ కాదు.

Android పరికరం కోసం, ఇన్‌పుట్-అవుట్‌పుట్‌లో వాస్తవంగా ఎటువంటి అనువర్తనాలు లేవు మరియు మెకానికల్ డ్రైవర్ లేదు, కాబట్టి ఉత్తమ ప్లానర్ నూప్ / ఫిఫో-క్యూ, కాబట్టి ఈ రకమైన షెడ్యూలర్ “ సర్దుబాటు' I / O ఉపవ్యవస్థకు ప్రత్యేకమైన లేదా అర్ధవంతమైన ఏదైనా చేయడం లేదు. వాస్తవానికి, ఆ బహుళ-స్క్రీన్ జాబితా ఆదేశాలన్నీ సాధారణ చక్రంతో భర్తీ చేయబడతాయి:

నేను / sys / block / mmc * లో; do echo noop> $ i / queue / షెడ్యూలర్ echo 0> $ i / queue / iostats పూర్తయ్యాయి

ఇది I / O గణాంకాల చేరడం నుండి అన్ని డ్రైవ్‌లకు నూప్ షెడ్యూలర్‌ను అనుమతిస్తుంది, ఇది పనితీరుపై సానుకూల ప్రభావాన్ని కలిగి ఉండాలి, అయినప్పటికీ చాలా చిన్నది మరియు పూర్తిగా నిర్లక్ష్యం.

పనితీరు స్క్రిప్ట్స్‌లో తరచుగా కనిపించే మరొక పనికిరాని I / O సర్దుబాటు 2MB వరకు SD కార్డుల కోసం పెరిగిన రీడ్-ఫార్వర్డ్ విలువలు. అనువర్తనం ఆ డేటాకు ప్రాప్యతను అభ్యర్థించే ముందు, మీడియా నుండి ప్రారంభ డేటా చదవడానికి రీడ్-ఫార్వర్డ్ విధానం. కాబట్టి ప్రాథమికంగా, కెర్నల్ భవిష్యత్తులో ఏ డేటా అవసరమో గుర్తించడానికి ప్రయత్నిస్తుంది మరియు దానిని RAM లోకి ముందే లోడ్ చేస్తుంది, తద్వారా తిరిగి వచ్చే సమయాన్ని తగ్గించాలి. ఇది కాగితంపై చాలా బాగుంది, కాని రీడ్-ఫార్వర్డ్ అల్గోరిథం చాలా తరచుగా ఉంటుంది తప్పు , ఇది ఇన్పుట్-అవుట్పుట్ యొక్క పూర్తిగా అనవసరమైన ఆపరేషన్లకు దారితీస్తుంది, అధిక RAM వినియోగం గురించి చెప్పలేదు.

1 - 8 MB మధ్య అధిక రీడ్-ఫార్వర్డ్ విలువలు RAID- శ్రేణులలో సిఫార్సు చేయబడ్డాయి, కానీ Android పరికరాల కోసం, 128 KB యొక్క డిఫాల్ట్ విలువను వదిలివేయడం మంచిది.

వర్చువల్ మెమరీ మేనేజ్‌మెంట్ సిస్టమ్ సర్దుబాటు

వర్చువల్ మెమరీ నిర్వహణ ఉపవ్యవస్థను ట్యూన్ చేయడం మరొక సాధారణ “ఆప్టిమైజేషన్” టెక్నిక్. ఇది సాధారణంగా రెండు కెర్నల్ వేరియబుల్స్‌ను మాత్రమే లక్ష్యంగా చేసుకుంటుంది, vm.dirty_background_ratio మరియు vm.dirty_ratio, ఇవి “మురికి” డేటాను నిల్వ చేయడానికి బఫర్ పరిమాణాన్ని సర్దుబాటు చేయడానికి. డర్టీ డేటా సాధారణంగా డిస్క్‌కు వ్రాయబడిన డేటా, కానీ ఇంకా చాలా మెమరీలో ఉంది మరియు డిస్క్‌కు వ్రాయడానికి వేచి ఉంది.

VM నిర్వహణ ఉపవ్యవస్థకు లైనక్స్ డిస్ట్రోస్ మరియు ఆండ్రోయిస్ రెండింటిలో సాధారణ సర్దుబాటు విలువలు ఇలా ఉంటాయి:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

కాబట్టి ఇది చేయడానికి ప్రయత్నిస్తున్నది ఏమిటంటే, డర్టీ డేటా బఫర్ మొత్తం RAM మొత్తంలో 10% ఉన్నప్పుడు, అది మేల్కొంటుంది pdflush ప్రవాహం మరియు డిస్కుకు డేటాను వ్రాయడం ప్రారంభిస్తుంది - డిస్క్‌లో డేటాను రికార్డ్ చేసే ఆపరేషన్ ఉంటే చాలా తీవ్రమైనది , బఫర్ పెరుగుతూనే ఉంటుంది మరియు ఇది అందుబాటులో ఉన్న RAM లో 20% కి చేరుకున్నప్పుడు, సిస్టమ్ తదుపరి బఫర్ లేకుండా సింక్రోనస్ మోడ్‌లో తదుపరి వ్రాత ఆపరేషన్‌కు మారుతుంది. దీనర్థం డిస్క్ అప్లికేషన్‌కు వ్రాసే పని ఉంటుంది డేటా డిస్క్‌కు వ్రాయబడే వరకు నిరోధించబడింది (AKA ‘లాగ్’).

మీరు అర్థం చేసుకోవలసినది ఏమిటంటే బఫర్ పరిమాణం అయినా 10% కి చేరదు , సిస్టమ్ 30 సెకన్ల తర్వాత స్వయంచాలకంగా పిడిఫ్లష్‌లో కిక్ అవుతుంది. 10/20 కలయిక చాలా సహేతుకమైనది, ఉదాహరణకు 1GB RAM ఉన్న పరికరంలో ఇది 100 / 200MB ర్యామ్‌కు సమానం, ఇది పేలుడు రికార్డుల పరంగా సరిపోతుంది, ఇక్కడ వేగం తరచుగా సిస్టమ్ NAND లో స్పీడ్ రికార్డ్ కంటే తక్కువగా ఉంటుంది అనువర్తనాలను ఇన్‌స్టాల్ చేసేటప్పుడు లేదా కంప్యూటర్ నుండి ఫైల్‌లను కాపీ చేసేటప్పుడు -మెమోరీ లేదా SD- కార్డ్.

కొన్ని కారణాల వల్ల, స్క్రిప్ట్ రచయితలు ఈ విలువను మరింత అసంబద్ధమైన రేట్లకు పెంచడానికి ప్రయత్నిస్తారు. ఉదాహరణకు మనం ఎక్స్‌ప్లిక్స్ ఆప్టిమైజేషన్ స్క్రిప్ట్ 50/90 కంటే ఎక్కువ రేటు.

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

1 GB మెమరీ ఉన్న పరికరంలో, ఇది డర్టీ బఫర్‌పై 500/900 MB కి పరిమితిని సెట్ చేస్తుంది, ఇది Android పరికరానికి పూర్తిగా పనికిరానిది, ఎందుకంటే ఇది కింద మాత్రమే పనిచేస్తుంది డిస్క్‌లో స్థిరమైన రికార్డింగ్ - భారీ లైనక్స్ సర్వర్‌లో మాత్రమే జరిగేది.

పిడుగు! స్క్రిప్ట్ మరింత సహేతుకమైన విలువను ఉపయోగిస్తుంది, కానీ మొత్తంమీద, ఇది ఇప్పటికీ చాలా అర్థరహితం:

['$ mem' -lt 524288]; అప్పుడు sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; అప్పుడు 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 ర్యామ్‌తో స్మార్ట్‌ఫోన్‌లలో నడుస్తాయి, రెండవది - 1 GB తో మరియు ఇతరులు - 1 GB కన్నా ఎక్కువ. వాస్తవానికి డిఫాల్ట్ సెట్టింగులను మార్చడానికి ఒకే ఒక కారణం ఉంది - చాలా నెమ్మదిగా అంతర్గత మెమరీ లేదా మెమరీ కార్డ్ ఉన్న పరికరం. ఈ సందర్భంలో వేరియబుల్స్ యొక్క విలువలను వ్యాప్తి చేయడం సహేతుకమైనది, అనగా, ఇలాంటివి చేయడానికి:

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

అప్పుడు, ఒక ఉప్పెన వ్యవస్థ ఆపరేషన్లను వ్రాసేటప్పుడు, డిస్క్‌లో డేటాను రికార్డ్ చేయకుండా, చివరి వరకు సింక్రోనస్ మోడ్‌కు మారదు, ఇది రికార్డింగ్ చేసేటప్పుడు అనువర్తనాలను మందగించడానికి అనుమతిస్తుంది.

అదనపు పనికిరాని ట్వీక్స్ మరియు పనితీరు ట్యూనింగ్

నిజంగా ఏమీ చేయని చాలా ఎక్కువ “ఆప్టిమైజేషన్లు” ఉన్నాయి. వాటిలో చాలావరకు ఎటువంటి ప్రభావం చూపవు, ఇతరులు మెరుగుపడవచ్చు కొన్ని పనితీరు యొక్క అంశం, పరికరాన్ని ఇతర మార్గాల్లో దిగజార్చేటప్పుడు ( సాధారణంగా ఇది పనితీరు vs బ్యాటరీ కాలువకు దిమ్మలు) .

Android సిస్టమ్ మరియు పరికరాన్ని బట్టి ఉపయోగకరంగా ఉండవచ్చు లేదా ఉపయోగపడని కొన్ని అదనపు జనాదరణ పొందిన ఆప్టిమైజేషన్లు ఇక్కడ ఉన్నాయి.

• త్వరణం - పనితీరు మరియు అండర్ వోల్టింగ్ మెరుగుపరచడానికి చిన్న త్వరణం - కొద్దిగా బ్యాటరీని ఆదా చేస్తుంది.
• డేటాబేస్ ఆప్టిమైజేషన్ - సిద్ధాంతంలో ఇది ఉండాలి పరికర పనితీరులో మెరుగుదల ఇవ్వండి, కానీ ఇది సందేహాస్పదంగా ఉంది.
• జిపాలిగ్న్ - హాస్యాస్పదంగా, స్టోర్‌లోని APK- ఫైల్‌లో అంతర్నిర్మిత Android SDK ఫీచర్ కంటెంట్ అలైన్‌మెంట్ ఉన్నప్పటికీ మీరు చాలా సాఫ్ట్‌వేర్‌ను జిపాలిగ్న్ ద్వారా ప్రసారం చేయలేదని కనుగొనవచ్చు.
• అనవసరమైన సిస్టమ్ సేవలను నిలిపివేయండి, ఉపయోగించని వ్యవస్థను తీసివేయడం మరియు అరుదుగా ఉపయోగించే మూడవ పక్ష అనువర్తనాలు. సాధారణంగా, బ్లోట్‌వేర్‌ను అన్‌ఇన్‌స్టాల్ చేస్తోంది.
• నిర్దిష్ట పరికరం కోసం ఆప్టిమైజేషన్లతో కూడిన కస్టమ్ కెర్నల్ (మళ్ళీ, అన్ని కేంద్రకాలు సమానంగా మంచివి కావు).
• ఇప్పటికే I / O షెడ్యూలర్ నూప్ గురించి వివరించబడింది.
• సంతృప్త అల్గోరిథం TCP వెస్ట్‌వుడ్ - వైర్‌లెస్ నెట్‌వర్క్‌ల కోసం డిఫాల్ట్ Android క్యూబిక్‌లో మరింత సమర్థవంతంగా ఉపయోగించబడుతుంది, ఇది కస్టమ్ కెర్నల్‌లలో లభిస్తుంది.

పనికిరాని సెట్టింగులు 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. 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.