Yleisimmät Android-optimointimytit ovat pilaantuneet

Siten monet all-in-one-optimointiskripteistä käyttävät samoja menetelmiä, joista osa on pitkällä aikavälillä täysin vanhentuneita tai haitallisia. Yhteenvetona voidaan todeta, että suurin osa 'kaikki yhdessä' -optimointiskripteistä on vain suositeltuja virityksiä, joilla ei ole selkeää käsitystä siitä, miten tai miksi nämä optimoinnit 'toimivat - käyttäjät sitten vilkkuvat komentosarjoilla ja väittävät, että niiden suorituskyky on yhtäkkiä nopeampaa ( tosiasiassa suorituskyvyn kasvua aiheutti todennäköisesti laitteen yksinkertainen uudelleenkäynnistys , koska kaikki laitteen RAM-muistissa olevat osat puhdistetaan) .

Tässä Appuals-artikkelissa korostamme joitain yleisimpiä suosituksia optimointi ” Android-suorituskyky ja onko kyseessä yksinkertaisesti myytti vai laillinen viritys laitteen suorituskyvylle.

Vaihtaa

Myyttiluettelon kärjessä on Android-vaihto - mikä on melko järjetöntä siltä osin kuin sitä pidetään Android-optimointina. Swapien päätarkoitus on luoda ja yhdistää sivutustiedosto, joka vapauttaa muistitilaa. Tämä kuulostaa järkevältä paperilla , mutta se soveltuu todella a palvelin , jolla ei ole juurikaan interaktiivisuutta.

Kun käytät Android-puhelimesi vaihtoa säännöllisesti, se johtaa vakaviin viiveisiin, jotka johtuvat asioiden liukastumisesta välimuistin ohi. Kuvittele esimerkiksi, jos sovellus yrittää näyttää grafiikan, joka on tallennettu vaihtoon, jonka on nyt ladattava levy uudelleen vapauttamisen jälkeen asettamalla datanvaihto toiseen sovellukseen. Se on todella sotkuista.

Jotkut optimointiharrastajat voivat sanoa, että vaihtaminen ei tarjonnut ongelmia, mutta se ei ole vaihdon tekeminen suorituskyvyn parantamiseksi - se on sisäänrakennettu Android-mekanismi pieni muistomerkki , joka tappaa säännöllisesti paisuneet, tärkeät prosessit, joita ei käytetä. LMK on suunniteltu erityisesti vähämuististen olosuhteiden käsittelemiseksi kswapd ja yleensä tappaa käyttäjäavaruusprosessit. Tämä eroaa OOMkiller (muistin ulkopuolinen tappaja), mutta se on eri asia.

Tarkoituksena on, että laite, jolla on esimerkiksi 1 Gt RAM-muistia, ei koskaan voi saavuttaa tarvittavia suorituskykytietoja vaihdossa, joten Androidissa ei ehdottomasti tarvita vaihtoa. Sen toteutus on yksinkertaisesti täynnä viivettä ja johtaa a hajoaminen suorituskyvyssä sen optimoinnin sijaan.

zRAM - vanhentunut ja ei enää tehokas

zRAM on todistettu ja tehokas menetelmä laitteen optimointiin vanhemmat laitteet - ajattele KitKat-pohjaisia ​​laitteita, jotka toimivat vain noin 512 Mt RAM-muistia. Se, että jotkut ihmiset edelleen sisällyttävät zRAM-säätöjä optimointiskripteihin tai suosittelevat zRAM: ää jonkinlaisena modernina optimointipakettina, on esimerkki ihmisistä, jotka eivät yleensä noudata uusimpia toimintaprotokollia.

zRAM oli tarkoitettu lähtötason budjettialueen monen ytimen SoC: ille, kuten MTK-piirisarjaa ja 512 Mt RAM-muistia käyttäville laitteille. Periaatteessa erittäin halvat kiinalaiset puhelimet. Mitä zRAM pohjimmiltaan tekee, on erottaa ydin salausvirran kautta.

Kun zRAM-muistia käytetään vanhemmissa laitteissa, joissa on a yksiytiminen , vaikka zRAM-muistia suositellaan tällaisille laitteille, suuret viiveiden määrät yleensä kasvavat. Tämä tapahtuu myös KSM-tekniikan kanssa ( Ytimen sama sivu sulautuu) joka yhdistää samanlaiset muistisivut tarjotakseen tilaa. Google on itse asiassa suositellut tätä, mutta se johtaa suurempiin viiveisiin vanhemmissa laitteissa, koska jatkuvasti aktiiviset ytimen kärjet juoksevat jatkuvasti muistista etsimään päällekkäisiä sivuja. Pohjimmiltaan optimoinnin säätäminen yrittää hidastaa laitetta entisestään, ironisesti.

Kylvökone - vanhentunut Android 3.0: n jälkeen

Yksi eniten keskusteltuja optimointivinkkejä Android-kehittäjien keskuudessa on setri , ja olemme varmoja, että joku voi yrittää todistaa väärin tässä asiassa - mutta ensin meidän on tutkittava kylvökoneen historia.

Seeder-sovellus Androidille

Kyllä, on olemassa useita raportteja, jotka ilmoittavat paremman Android-suorituskyvyn asennuksen jälkeen paljon vanhemmat Android-laitteet . Ihmiset mistä tahansa syystä uskovat kuitenkin, että se on myös sovellettava optimointi nykyaikaiset Android-laitteet , mikä on täysin järjetöntä. Se, että Seederia ylläpidetään ja tarjotaan edelleen moderni' viiveen vähentämistyökalu on esimerkki vääristä tiedoista - vaikka tämä ei olekaan Seederin kehittäjän vika, koska jopa heidän Play Kauppa -sivunsa mukaan Seeder on vähemmän tehokas Android 4.0+: n jälkeen. Silti jostain syystä Seeder ilmestyy edelleen optimointikeskusteluihin nykyaikaisille Android-järjestelmille.

Seeder tekee periaatteessa Android 3.0: lle virheen, jossa Android-ajonaika käyttää aktiivisesti / dev / random / tiedostoa entropian hankkimiseksi. / Dev / random / puskurista tulee epävakaa, ja järjestelmä estetään, kunnes se täyttää tarvittavan määrän tietoa - ajattele pieniä asioita, kuten erilaisia ​​Android-laitteen antureita ja painikkeita.

Seederin kirjoittaja otti Linux-demonin rngd ja koottu Androidin inastroilille siten, että se otti satunnaiset tiedot paljon nopeammalta ja ennakoitavammalta / dev / urandom-reitiltä ja sulauttaa ne dev / random / joka sekunti antamatta / dev / random / -valmis loppua. Tämä johti Android-järjestelmään, joka ei kokenut entropian puutetta ja joka toimi paljon sujuvammin.

Google mursi tämän virheen Android 3.0: n jälkeen, mutta jostain syystä Seeder ponnahtaa edelleen 'Suositellut tweaksit' luettelot Android-suorituskyvyn optimointiin. Lisäksi Seeder-sovelluksessa on muutamia analogeja, kuten sEFix, jotka sisältävät Seederin toiminnot, käyttävätkö ne samaa rngd tai vaihtoehtoinen köyhä tai jopa vain symlink / dev / urandom ja / dev / random välillä. Tämä on täysin turhaa nykyaikaisille Android-järjestelmille.

Syynä sen turhuuteen johtuu siitä, että uudemmat Android-versiot käyttävät / dev / random / kolmessa pääkomponentissa - libcrypto , SSL-yhteyksien salaamiseen, SSH-avainten luomiseen jne. WPA_supplication / hostapd, joka tuottaa WEP / WPA-avaimet, ja lopuksi kourallinen kirjastoja tunnuksen luomiseksi EXT2 / EXT3 / EXT4-tiedostojärjestelmien luomisessa.

Joten kun Kylvökone tai Seeder-pohjaiset parannukset sisältyvät moderneihin Android-optimointiohjelmiin, mikä lopulta tapahtuu hajoaminen laitteen suorituskyvyssä, koska rngd herättää laitteen jatkuvasti ja lisää prosessorin taajuutta, mikä luonnollisesti vaikuttaa negatiivisesti akun kulutukseen.

Odex

Android-laitteiden varastossa oleva laiteohjelmisto on melkein aina odex. Tämä tarkoittaa, että APK-muotoisten Android-sovellusten vakiopaketin rinnalla, jotka löytyvät tiedostoista / system / app / ja / system / priv-app /, ovat samat tiedostonimet .odex-laajennuksella. Oodex-tiedostot sisältävät optimoituja tavukoodisovelluksia, jotka ovat jo läpäisseet validoijan ja optimoijan virtuaalikoneen, ja sitten ne on tallennettu erilliseen tiedostoon, joka käyttää jotain dexopt työkalu.

Joten odex-tiedostojen on tarkoitus purkaa virtuaalikone ja tarjota nopeutettu odexed-sovelluksen käynnistys - haittapuolena ODEX-tiedostot estävät muutoksia laiteohjelmistoon ja aiheuttavat ongelmia päivitysten kanssa, joten tästä syystä jaetaan monia mukautettuja ROM-levyjä, kuten LineageOS ilman ODEX: ää .

ODEX-tiedostojen luominen tapahtuu monin tavoin, kuten Odexer Tool -työkalun avulla - ongelmana on, että se on puhtaasti lumelääke. Kun moderni Android-järjestelmä ei löydä odex-tiedostoja / system-hakemistosta, järjestelmä itse luo ne ja sijoittaa ne hakemistoon / system / dalvik-cache /. Juuri näin tapahtuu, kun esimerkiksi välähdät uutta Android-versiota ja se antaa hetkeksi viestin 'Varattu, sovellusten optimointi'.

Lowmemorykiller säätää

Androidin moniajo eroaa muista mobiilikäyttöjärjestelmistä siinä mielessä, että se perustuu klassiseen malliin, jossa sovellukset toimivat hiljaa taustalla, eikä taustasovellusten määrälle ole asetettu rajoituksia ( ellei sellaista ole määritetty Kehittäjäasetuksissa, mutta tätä suositellaan yleensä) - Lisäksi taustatoteutukseen siirtymisen toiminnallisuutta ei lopeteta, vaikka järjestelmä pidättää oikeuden tappaa taustasovellukset vähän muistia käyttävissä tilanteissa ( katso mistä puhuimme aiemmin tässä oppaassa lowmemorykilleristä ja muistin ulkopuolisesta tappajasta .

Palaa takaisin pieni muistomerkki mekanismi, Android voi jatkaa toimintaansa rajoitetulla määrällä muistia ja vaihdettavien osioiden puuttuessa. Käyttäjä voi jatkaa sovellusten käynnistämistä ja siirtymistä niiden välillä, ja järjestelmä tappaa hiljaa käyttämättömät taustasovellukset yrittäen vapauttaa muistia aktiivisiin tehtäviin.

Tämä oli erittäin hyödyllistä Androidille alkuaikoina, vaikkakin jostain syystä siitä tuli suosittu tehtävä-tappaja-sovellusten muodossa, jotka ovat yleensä enemmän haitallisia kuin hyödyllisiä. Task-tappaja -sovellukset joko heräävät määrätyin väliajoin tai ovat käyttäjän suorittamia, ja näyttävät vapauttavan suuria määriä RAM-muistia, mikä nähdään positiivisena - enemmän vapaata RAM-muistia tarkoittaa nopeampaa laitetta, eikö? Tämä ei kuitenkaan tarkoita Androidia.

Itse asiassa suuren määrän vapaan RAM-muistin saaminen voi itse asiassa olla haitallista laitteen suorituskyvylle ja akun kestolle. Kun sovellukset on tallennettu Androidin RAM-muistiin, niiden kutsuminen, käynnistäminen jne. On paljon helpompaa. Android-järjestelmän ei tarvitse käyttää paljon resursseja sovellukseen siirtymiseen, koska se on jo muistissa.

Tämän vuoksi tehtävämurhaajat eivät todellakaan ole niin suosittuja kuin ennen, vaikka Android-noviisit pyrkivät edelleen jostain syystä luottamaan niihin ( tiedon puute, valitettavasti) . Valitettavasti uusi suuntaus on korvannut tehtävän tappajat pieni muistomerkki mekanismin viritykset. Tämä olisi esimerkiksi MinFreeManager sovelluksen, ja pääidea on lisätä RAM-muistia ennen kuin järjestelmä alkaa tappaa taustasovelluksia.

Joten esimerkiksi vakiomuisti toimii rajoilla - 4, 8, 12, 24, 32 ja 40 Mt, ja kun 40 Mt vapaata tallennustilaa on täynnä, yksi välimuistissa olevista sovelluksista, joka ladataan muistiin mutta ei käynnissä lopetetaan.

Joten pohjimmiltaan Androidilla on aina vähintään 40 Mt vapaata muistia, mikä riittää vielä yhden sovelluksen sijoittamiseen pieni muistomerkki alkaa puhdistusprosessinsa - mikä tarkoittaa, että Android tekee aina parhaansa käyttääkseen käytettävissä olevan RAM-muistin enimmäismäärän häiritsemättä käyttökokemusta.

Valitettavasti jotkut homebrew-harrastajat suosittelivat, että arvo nostetaan esimerkiksi 100 Mt: ksi ennen LMK: n käynnistymistä. Nyt käyttäjä todella menettää RAM-muistia (100 - 40 = 60), joten sen sijaan, että käytettäisiin tätä tilaa taustapalvelujen tallentamiseen, järjestelmä säilyttää tämän määrän muistia vapaa , ilman mitään tarkoitusta siihen.

LKM-viritys voi olla hyödyllistä paljon vanhemmille laitteille, joissa on 512 RAM-muistia, mutta kuka omistaa ne enää? 2 Gt on moderni 'budjettialue', jopa 4 Gt: n RAM-laitteet näkevät 'keskitason' näinä päivinä, joten LMK-säätö on todella vanhentunutta ja hyödytöntä.

I / O-säätöjä

Monista Android-optimointiskripteistä löydät usein I / O-alijärjestelmään liittyviä parannuksia. Katsotaanpa esimerkiksi ThunderBolt! Script, joka sisältää nämä rivit:

kaiku 0> $ i / jono / kierto; echo 1024> $ i / jono / nr_pyynnöt;

Ensimmäinen rivi antaa I / O-ajastimelle ohjeita SSD-aseman käsittelyssä, ja toinen kasvattaa jonon I / O-maksimikokoa 128: sta 1024: een - koska muuttuja $ i sisältää polun lohkolaitteiden puuhun / sys, ja komentosarja toimii silmukassa.

Sen jälkeen löydät CFQ-ajastimeen liittyvän rivin:

kaiku 1> $ i / jono / iosched / back_seek_penalty; kaiku 1> $ i / jono / iosched / matala_latency; kaiku 1> $ i / jono / iosched / slice_idle;

Tätä seuraa lisää rivejä, jotka kuuluvat muille suunnittelijoille, mutta viime kädessä kaksi ensimmäistä komentoa ovat turhia, koska:

Moderni Linux-ydin pystyy ymmärtämään, minkä tyyppisen tallennusvälineen kanssa se toimii oletuksena.

Pitkä tulo- ja lähtöjono ( kuten 1024) on hyödytön nykyaikaisessa Android-laitteessa, itse asiassa sen merkityksetön jopa työpöydällä - sitä suositellaan vain raskaat palvelimet . Puhelimesi ei ole raskas Linux-palvelin.

Android-laitteessa ei ole käytännössä yhtään syötteessä priorisoitua sovellusta eikä mekaanista ohjainta, joten paras suunnittelija on noop / FIFO-jono, joten tämän tyyppinen ajoitin nipistää' ei tee mitään erityistä tai merkityksellistä I / O-osajärjestelmälle. Itse asiassa kaikki nämä usean näytön luettelokomennot on parempi korvata yksinkertaisella jaksolla:

i: lle / sys / lohko / mmc *; tee echo noop> $ i / jono / ajastimen kaiku 0> $ i / jono / iostats valmis

Tämä mahdollistaisi noop-ajastimen kaikille asemille I / O-tilastojen keräämisestä, jolla pitäisi olla positiivinen vaikutus suorituskykyyn, vaikkakin hyvin pienellä ja melkein mitättömällä.

Toinen hyödytön I / O-nipistys, joka usein löytyy suorituskykyskripteistä, on SDM-korttien jopa 2 Mt: n korotetut eteenpäin-arvot. Read-eteenpäin -mekanismi on tarkoitettu tietojen varhaiselle lukemiselle mediasta, ennen kuin sovellus pyytää pääsyä kyseisiin tietoihin. Pohjimmiltaan ydin yrittää selvittää, mitä tietoja tarvitaan tulevaisuudessa, ja lataa ne valmiiksi RAM-muistiin, mikä lyhentää palautusaikaa. Tämä kuulostaa hyvältä paperilla, mutta eteenpäin-algoritmi on useammin väärä , mikä johtaa täysin tarpeettomiin tulo- ja lähtötoimintoihin, puhumattakaan suuresta RAM-kulutuksesta.

RAID-matriiseissa suositellaan korkeita 1–8 Mt: n ennakkoarvoja, mutta Android-laitteille on parasta jättää oletusarvo 128 kt.

Virtuaalimuistin hallintajärjestelmä muokkaa

Toinen yleinen 'optimointitekniikka' on virtuaalimuistin hallintajärjestelmän virittäminen. Tämä kohdistuu tyypillisesti vain kahteen ytimen muuttujaan, vm.dirty_background_ratio ja vm.dirty_ratio, jotka on tarkoitettu puskurin koon säätämiseen 'likaisen' datan tallentamiseksi. Likainen tiedot ovat tyypillisesti tietoja, jotka on kirjoitettu levylle, mutta enemmän on vielä muistissa ja odottaa kirjoittamista levylle.

Tyypilliset säätöarvot sekä Linux-distroissa että Androisissa VM-hallintajärjestelmään ovat:

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

Joten mitä tämä yrittää tehdä, on se, että kun likainen tietopuskuri on 10% RAM-muistin kokonaismäärästä, se herää pdflush virtaa ja alkaa kirjoittaa tietoja levylle - jos tietojen tallentaminen levylle tapahtuu liian voimakas , puskuri jatkaa kasvuaan, ja kun se saavuttaa 20% käytettävissä olevasta RAM-muistista, järjestelmä siirtyy seuraavaan kirjoitusoperaatioon synkronisessa tilassa - ilman esipuskuria. Tämä tarkoittaa levylle kirjoittamisen työtä estetty, kunnes tiedot kirjoitetaan levylle (AKA ’viive’).

Sinun pitäisi ymmärtää, että vaikka puskurin koko ei saavuta 10% , järjestelmä käynnistyy automaattisesti pdflush-muodossa 30 sekunnin kuluttua. 10/20: n yhdistelmä on melko kohtuullinen, esimerkiksi laitteessa, jossa on 1 Gt RAM-muistia, tämä vastaisi 100/200 Mt RAM-muistia, mikä on enemmän kuin tarpeeksi pursketietueiden osalta, joissa nopeus on usein NAND-järjestelmän nopeustietueen alapuolella -muisti tai SD-kortti, esimerkiksi asennettaessa sovelluksia tai kopioimalla tiedostoja tietokoneelta.

Jostain syystä käsikirjoittajat yrittävät nostaa tätä arvoa jopa korkeammalle, järjettömiksi. Esimerkiksi voimme löytää Xplix optimointikoodin nopeus on jopa 50/90.

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

Laitteessa, jossa on 1 Gt muistia, likaantuneen puskurin rajaksi asetetaan 500/900 Mt, mikä on täysin hyödytöntä Android-laitteelle, koska se toimisi vain alle jatkuva tallennus levylle - jotain tapahtuu vain raskaalla Linux-palvelimella.

ThunderBolt! Skripti käyttää järkevämpää arvoa, mutta kaiken kaikkiaan se on silti melko merkityksetön:

jos ['$ mem' -lt 524288]; sitten sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; sitten 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;

Kaksi ensimmäistä komentoa suoritetaan älypuhelimissa, joissa on 512 Mt RAM-muistia, toinen - 1 Gt ja muut - yli 1 Gt. Itse asiassa oletusasetusten muuttamiseen on vain yksi syy - laite, jolla on erittäin hidas sisäinen muisti tai muistikortti. Tässä tapauksessa on järkevää levittää muuttujien arvoja, eli tehdä jotain tällaista:

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

Kun ylijännitesysteemi kirjoittaa toimintoja ilman, että tarvitsee tallentaa tietoja levylle, viimeinen ei siirry synkronitilaan, mikä sallii sovellusten vähentää viivettä tallennuksen aikana.

Muita hyödyttömiä muutoksia ja suorituskyvyn virityksiä

Siellä on paljon enemmän 'optimointeja', jotka eivät todellakaan tee mitään. Suurimmalla osalla niistä ei yksinkertaisesti ole mitään vaikutusta, kun taas toiset voivat parantaa jonkin verran suorituskyvyn näkökulmasta samalla kun se heikentää laitetta muilla tavoin ( yleensä se supistuu suorituskykyyn verrattuna akun tyhjentämiseen) .

Tässä on joitain suosittuja optimointeja, joista voi olla hyötyä tai ei, riippuen Android-järjestelmästä ja laitteesta.

• Kiihtyvyys - Pieni kiihtyvyys suorituskyvyn ja alijännitteen parantamiseksi säästää vähän akkua.
• Tietokannan optimointi - Teoriassa tämä pitäisi parantavat laitteen suorituskykyä, mutta sen epäilystäkään.
• Zipalign - Ironista kyllä, huolimatta sisäänrakennetusta Android SDK -ominaisuuksien sisällön tasaamisesta myymälän APK-tiedostossa, löydät paljon ohjelmistoja, joita ei lähetetä zipalignin kautta.
• Poista tarpeettomat järjestelmäpalvelut käytöstä poistamalla käyttämätön järjestelmä ja harvoin käytetyt kolmannen osapuolen sovellukset. Pohjimmiltaan bloatware-ohjelmien poistaminen.
• Mukautettu ydin, jossa on optimointeja tietylle laitteelle (kaikki ytimet eivät taas ole yhtä hyviä).
• Jo kuvattu I / O-ajastimen noop.
• Värikylläisyysalgoritmi TCP Westwood - Käytetään tehokkaammin langattomien verkkojen oletusarvoisessa Android Cubic -sovelluksessa, saatavana mukautetuissa ytimissä.

Hyödytön asetukset build.prop

LaraCraft304 XDA Developers -foorumilta on tehnyt tutkimuksen ja löytänyt, että vaikuttavia määriä /system/build.prop -asetuksia, joita suositellaan käytettäväksi 'asiantuntijoina', ei ole lähde AOSP: ssä ja CyanogenModissa. Tässä on luettelo:

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. kernel.checkjni dalvik.vm.verify-bytecode debug.performance.tuning video.