miten

Yleisimmät Android-optimointimyytit purettiin

Siellä on paljon opetusoppaita, jotka on omistettu Android-suorituskyvyn parantamiseksi, ja yleisiä optimointivihjeitä. Jotkut heistä ovat laillisia, ja toiset perustuvat vain teoriaan tai vanhentuneisiin Android-järjestelmän toimintamenetelmiin tai ovat vain hölynpölyä. Tähän sisältyy vaihtosuosituksia, build.prop: lle lisättyjä arvoja ja muuttuvia muutoksia Linux-ytimessä.

Siellä on jopa tonni "optimointikomentosarjoja", all-in-one-salama .zip, jotka lupaavat parantaa merkittävästi suorituskykyä, akun käyttöikää ja muita asioita. Jotkut hienosäädöt voivat tosiasiallisesti toimia, mutta suurin osa niistä on vain lumelääkevaikutuksia tai, mikä pahempaa, tosiasiallisesti vaikuttaa kielteisesti laitteeseen.

Tämä ei tarkoita sitä, että ihmiset julkaisevat tahattomia skriptejä tarkoituksellisesti - Play Kaupassa on ehdottomasti vääriä maksettuja sovelluksia, mutta Android-foorumeilla julkaistut optimointikomentosarjat ovat yleensä hyviä aikomuksia, niin vain tapahtuu, että kehittäjälle annetaan väärät tiedot, tai vain kokeilla erilaisia optimointitoimenpiteitä. Valitettavasti eräänlainen lumipallovaikutus on ilmeinen, etenkin "all-in-one" -optimointikomentosarjoissa. Pieni kourallinen tweakeista voi tosiasiallisesti tehdä jotain, kun taas toinen komentosarjan tweaks-sarja ei tee mitään ollenkaan - silti nämä komentosarjat siirretään taikuumyrskyiksi ilman, että tehdään todellista tutkimusta siitä, mikä toimii, ja mikä ei .

Siksi monet all-in-one-optimointikomentosarjat käyttävät samoja menetelmiä, joista jotkut ovat täysin vanhentuneita tai pitkällä aikavälillä haitallisia. Yhteenvetona voidaan todeta, että suurin osa "kaikki yhdessä" -optimointikomentosarjoista on vain suositeltuja virityksiä, ilman selkeää käsitystä siitä, kuinka tai miksi nämä optimoinnit toimivat - käyttäjät vilkuttavat sitten skriptit ja väittävät niiden suorittavan yhtäkkiä nopeammin ( kun tosiasiassa, todennäköisimmin laitteen yksinkertainen uudelleenkäynnistäminen aiheutti suorituskyvyn nousun, koska kaikki laitteen RAM-muistissa puhdistuu) .

Tässä Appuals-yksinoikeudellisessa artikkelissa korostetaan joitain yleisimpiä suosituksia Android-suorituskyvyn " optimoimiseksi" ja ovatko ne vain myytti vai laillinen mukautus laitteen suorituskyvylle.

Vaihtaa

Myyttilistan kärjessä on Android-vaihto - mikä on aika järjetöntä ajatellen, että sitä pidetään Android-optimointina. Swaps-päätarkoitus on luoda ja yhdistää sivutiedosto, joka vapauttaa muistitilaa. Tämä kuulostaa järkevältä paperilla, mutta se soveltuu todella palvelimelle, jolla ei juuri ole interaktiivisuutta.

Kun käytät Android-puhelimesi vaihtoa säännöllisesti, se johtaa vakaviin viiveisiin, jotka johtuvat välimuistin ohittamisesta. Kuvittele esimerkiksi, jos sovellus yrittää näyttää vaihtona tallennetun grafiikan, jonka on nyt ladattava levy uudelleen tilan vapauttamisen jälkeen asettamalla tiedonvaihto toiseen sovellukseen. Se on todella sotkuista.

Jotkut optimoinnin harrastajat voivat sanoa, että vaihtaminen ei aiheuttanut ongelmia, mutta suorituskyvyn parantaminen ei ole swap - se on sisäänrakennettu Android-mekanismi lowmemorykiller, joka tappaa säännöllisesti paisuneet, tärkeät prosessit, joita ei käytetä. LMK on suunniteltu erityisesti käsittelemään vähän muistia olevia olosuhteita, sitä kutsutaan kswapd- prosessista ja se yleensä tappaa käyttäjätilan prosessit. Tämä eroaa OOMkilleristä (muistilla tappaja), mutta se on erilainen aihe kokonaan.

Asia on, että laite, jolla on esimerkiksi 1 Gt RAM-muistia, ei voi koskaan saavuttaa tarvittavia suoritustietoja vaihdossa, joten vaihtamista ei ehdottomasti tarvita Androidissa. Sen toteutus on yksinkertaisesti viivästynyt ja johtaa suorituskyvyn heikkenemiseen sen sijaan, että sitä optimoitaisiin.

zRAM - vanhentunut eikä ole enää tehokasta

zRAM on todistettu ja tehokas menetelmä laitteen optimointiin, vanhemmille laitteille - ajattele KitKat-pohjaisia laitteita, jotka käyttävät vain noin 512 Mt RAM-muistia. Se, että jotkut ihmiset sisällyttävät edelleen zRAM-tarkistuksia optimointikomentosarjoihin, tai suosittelevat zRAMia jonkinlaisena nykyaikaisena optimointikielenä, on esimerkki ihmisistä, jotka eivät yleensä noudata uusimpia toimintaprotokollia.

zRAM oli tarkoitettu lähtötason budjettialueen moniytimisiin SoC-laitteisiin, kuten laitteisiin, jotka käyttävät MTK-piirisarjoja ja 512 Mt RAM-muistia. Erittäin halvat kiinalaiset puhelimet, pohjimmiltaan. Se, mitä zRAM käytännössä tekee, on erottaa ydin salausvirran kautta.

Kun zRAM: ää käytetään vanhemmissa laitteissa, joissa on yksi ydin, vaikka zRAM: a suositellaan tällaisissa laitteissa, suurilla viiveillä on taipumus kasautua. Näin tapahtuu myös KSM-tekniikalla ( Kernel Same Page Merging), joka yhdistää identtiset muistisivut tarjouksena vapaata tilaa. Tätä todellakin suosittelee Google, mutta se johtaa vanhempien laitteiden suurempiin viiveisiin, koska jatkuvasti aktiiviset ydinoppaat kulkevat jatkuvasti muistista etsimään kopioitavia sivuja. Periaatteessa optimoinnin säätämisen yrittäminen hidastaa laitetta vielä ironisemmin.

Seeder - vanhentunut Android 3.0: sta lähtien

Yksi Android-laitteiden keskustetuimmista optimointivihjeistä on kylvökone, ja olemme varmoja, että joku voi yrittää osoittaa meille olevan väärä tässä aiheessa - mutta meidän on ensin tutkittava kylvökoneen historia.

Seeder-sovellus Androidille

Kyllä, on olemassa suuri joukko raportteja, jotka ilmoittavat paremman Android-suorituskyvyn asentamisen jälkeen paljon vanhempiin Android-laitteisiin . Ihmiset mistä tahansa syystä uskovat kuitenkin, että tämä tarkoittaa myös nykyaikaisten Android-laitteiden optimointia, mikä on ehdottoman järjetöntä. Se, että Seederia ylläpidetään edelleen ja tarjotaan ” uudenaikaisena” viiveen pienentämisen työkaluna, on esimerkki vääristä tiedoista - vaikka tämä ei ole Seederin kehittäjän virhe, koska jopa heidän Play Kauppa -sivun mukaan Seder on vähemmän tehokas Android 4.0+: n jälkeen. Siitä huolimatta, mistä tahansa syystä, Seeder esiintyy edelleen nykyaikaisten Android-järjestelmien optimointikeskusteluissa.

Se, mitä Seeder pohjimmiltaan tekee Android 3.0: lle, on virhe, jonka avulla Android-käyttöaika käyttää aktiivisesti tiedostoa / dev / random / tiedosto entropian hankkimiseen. / Dev / random / puskurista tulee epävakaa, ja järjestelmä estetään, kunnes se on täyttänyt vaaditun määrän tietoja - ajattele pieniä asioita, kuten Android-laitteen erilaisia antureita ja painikkeita.

Seederin kirjailija otti Linux-demon rngd : n ja käänsi Androidin inastroiliin siten, että se otti satunnaista tietoa paljon nopeammalta ja ennustettavammalta / dev / urandom -polulta ja yhdistää ne dev / satunnaiseen / joka sekuntiin sallimatta / dev / random / olla uupunut. Tämä johti Android-järjestelmään, joka ei kokenut entropian puuttumista ja suoritti paljon sujuvammin.

Google löi tämän virheen Android 3.0: n jälkeen, mutta jostain syystä Seeder esiintyy edelleen suositeltujen tweaks- luetteloissa Android-suorituskyvyn optimoimiseksi. Lisäksi Seeder-sovelluksella on muutamia analogioita, kuten sEFix, jotka sisältävät Seederin toiminnallisuuden, joko käyttävätkö samaa rngd: tä tai vaihtoehtoista haastattua tai jopa vain linkkiä / dev / urandom ja / dev / random välillä. Tämä on täysin turhaa nykyaikaisissa Android-järjestelmissä.

Syynä siihen, että se on turhaa, on se, että uudemmissa Android-versioissa käytetään / dev / random / kolmessa pääkomponentissa - libcrypto, SSL-yhteyksien salaamiseen, SSH-avainten luomiseen jne. kirjastot ID: n luomiseksi EXT2 / EXT3 / EXT4-tiedostojärjestelmien luomisessa.

Joten kun Seeder- tai Seeder-pohjaiset parannukset sisällytetään nykyaikaisiin Android-optimointikomentosarjoihin, lopputuloksena on laitteen suorituskyvyn heikkeneminen, koska rngd herättää laitetta jatkuvasti ja aiheuttaa prosessorin taajuuden nousun, mikä tietysti vaikuttaa negatiivisesti akun kulutukseen. .

Odex

Android-laitteiden osakeohjelmisto on melkein aina odex. Tämä tarkoittaa, että APK-muodossa olevien Android-sovellusten vakiopaketin lisäksi, jotka löytyvät hakemistosta / system / app / ja / system / priv-app /, ovat samat tiedostonimet .odex-tunnisteen kanssa. Odex-tiedostot sisältävät optimoidut tavukoodisovellukset, jotka ovat jo läpäisseet validoijan ja optimoijan virtuaalikoneen, tallennettuna sitten erilliseen tiedostoon hyödyntäen jotain dexopt- työkalua.

Joten odex-tiedostojen on tarkoitus purkaa virtuaalikone ja tarjota odexed-sovelluksen nopeutettu käynnistys - ODEX-tiedostot estävät laiteohjelmiston muutoksia ja aiheuttavat päivityksiin liittyviä ongelmia, joten tästä syystä monet mukautetut ROM-levyt, kuten LineageOS, jaetaan ilman ODEX .

ODEX-tiedostojen luominen tapahtuu monella tapaa, kuten käyttämällä Odexer Tool -työkalua - ongelmana on, että sen puhtaasti lumelääkevaikutus. Kun nykyaikainen Android-järjestelmä ei löydä odex-tiedostoja / system-hakemistosta, järjestelmä tosiasiallisesti luo ne ja sijoittaa ne / system / dalvik-cache / hakemistoon. Näin tapahtuu, kun esimerkiksi salamaat uuden Android-version ja se antaa jonkin aikaa viestin Varattu, sovellusten optimointi.

Lowmemorykiller-tweaks

Androidin multitasking eroaa muista mobiili käyttöjärjestelmistä siinä mielessä, että se perustuu klassiseen malliin, jossa sovellukset toimivat hiljaa taustalla, eikä taustasovellusten määrälle ole rajoituksia ( ellei yksi ole määritetty Kehittäjävaihtoehtoissa, mutta tämä on yleisesti suositellaan vastaan) - lisäksi taustan suorittamiseen siirtymisen toiminnallisuutta ei lopeteta, vaikka järjestelmä pidättää itsellään oikeuden tappaa taustasovellukset vähämuistiisissa tilanteissa ( katso, missä puhumme aikaisemmin lowmemorykilleristä ja muistilähettimestä) opas) .

Palataksesi takaisin lowmemorykiller- mekanismiin, Android voi jatkaa toimintaa rajoitetulla muistimäärällä ja puuttuessa swap-osiosta. Käyttäjä voi jatkaa sovellusten käynnistämistä ja vaihtaa niiden välillä, ja järjestelmä tappaa hiljaa käyttämättömät taustasovellukset yrittääkseen vapauttaa muistia aktiivisiin tehtäviin.

Tämä oli erittäin hyödyllistä Androidille alkuaikoina, tosin jostain syystä se on tullut suosituksi tehtävästä tappavien sovellusten muodossa, jotka ovat yleensä haitallisempia kuin hyödyllisiä. Tehtävätapahtumasovellukset joko heräävät asetettuin 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 vapaa RAM tarkoittaa nopeampaa laitetta, eikö niin? Tämä ei kuitenkaan ole totta tilanne Androidissa.

Itse asiassa suuren määrän ilmaista RAM-muistia käyttäminen voi itse asiassa olla haitallista laitteen suorituskyvylle ja akun kestolle. Kun sovelluksia tallennetaan Androidin RAM-muistiin, on huomattavasti helpompaa kutsua niitä, käynnistää niitä jne. Android-järjestelmän ei tarvitse käyttää paljon resursseja sovellukseen vaihtamiseen, koska se on jo muistissa.

Tästä syystä tehtävien tappajat eivät ole oikeasti niin suosittuja kuin koskaan, vaikka Android-aloittelijat yleensäkin luottavat niihin jostain syystä ( valitettavasti tiedon puute) . Valitettavasti uusi trendi on korvannut tehtävien tappajat, matalan muistin tappajien mekanismien virityksen trendi. Tämä olisi esimerkiksi MinFreeManager- sovellus, ja pääideana on lisätä RAM-muistia yläpuolella, ennen kuin järjestelmä alkaa tappaa taustasovelluksia .

Joten esimerkiksi tavallinen RAM-muisti toimii rajoilla - 4, 8, 12, 24, 32 ja 40 Mt, ja kun 40 Mt: n vapaa tallennustila täytetään, yksi välimuistissa olevista sovelluksista, jotka on ladattu muistiin, mutta ei käynnissä lopetetaan.

Joten periaatteessa Androidilla on aina vähintään 40 Mt vapaata muistia, joka riittää yhden sovelluksen lisäämiseen ennen kuin lowmemorykiller aloittaa puhdistusprosessinsa - mikä tarkoittaa, että Android tekee aina parhaansa käyttääkseen suurimman määrän käytettävissä olevaa RAM-muistia häiritsemättä käyttäjäkokemus.

Valitettavasti se, mitä jotkut kotirenkaan harrastajat aloittivat, on, että arvo nostetaan esimerkiksi 100 Mt: een ennen kuin LMK potkaisee sisään. Nyt käyttäjä todella menettää RAM-muistin (100–40 = 60), joten sen sijaan, että käyttäisit tätä tilaa tallentaaksesi takaisin- sovellusten lopussa, järjestelmä pitää tämän määrän muistia vapaana ilman mitään tarkoitusta siihen.

LKM-virityksestä voi olla hyötyä paljon vanhemmille laitteille, joissa on 512 RAM-muistia, mutta kuka ne enää omistaa? 2 Gt on moderni ”budjettivalikoima”, jopa 4 Gt: n RAM-laitteet näkevät nykyään “keskialueeksi”, joten LMK: n tweaksit ovat todella vanhentuneita ja turhia.

I / O-tweaks

Monista Androidin optimointikomennoista löydät usein säädöksiä, jotka koskevat I / O-alijärjestelmää. Katsotaanpa esimerkiksi ThunderBolt! Komentosarja, joka sisältää nämä rivit:

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

Ensimmäinen rivi antaa I / O-ajoituksen ohjeet käsitellä SSD: tä, ja toinen lisää jonon I / O -jonon enimmäiskokoa 128: sta 1024: ään - koska $ i -muuttuja sisältää polun lohkolaitteiden puun / sys, ja komentosarja suoritetaan silmukassa.

Tämän jälkeen löydät rivin, joka liittyy CFQ-aikatauluun:

 kaiku 1> $ i / jono / iosched / back_seek_penalty; kaiku 1> $ i / jono / iosched / low_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:

Nykyaikainen Linux-ydin pystyy oletuksena ymmärtämään, minkä tyyppisellä tallennusvälineellä se toimii.

Pitkä tulo- ja jonojono ( kuten 1024) on hyödytön nykyaikaisella Android-laitteella, tosiasiassa sen merkityksetön jopa työpöydällä - sitä todella suositellaan vain raskaaseen palvelimeen . Puhelimesi ei ole raskas Linux-palvelin.

Android-laitteessa ei käytännössä ole mitään syöttö- ja lähtölähtökohtia priorisoivia sovelluksia eikä mekaanista ohjainta, joten paras suunnittelija on noop / FIFO-jono, joten tämäntyyppinen ajoituksen " nipistää" ei tee mitään erityistä tai merkityksellistä I / O-osajärjestelmä. Itse asiassa kaikki nämä moninäyttöluettelokomennot korvataan paremmin yksinkertaisella jaksolla:

 i: lle / sys / block / mmc *; tee kaiku noop> $ i / jono / aikataulun kaiku 0> $ i / jono / iostats valmis

Tämä mahdollistaisi noop-aikataulun kaikille asemille I / O-tilastotietojen kertymisestä, jolla pitäisi olla positiivinen vaikutus suorituskykyyn, vaikkakin hyvin pieni ja melkein täysin vähäinen.

Toinen hyödytön I / O-nipistys, joka usein löytyy suorituskykykomentosarjoista, on SD-korttien korkeammat lukemisarvot jopa 2 Mt asti. Edeltämismekanismi on varhainen tietojen lukeminen mediasta, ennen kuin sovellus pyytää pääsyä kyseisiin tietoihin. Joten pohjimmiltaan ydin yrittää selvittää, mitä tietoja tarvitaan tulevaisuudessa, ja lataa sen ennalta RAM-muistiin, jonka pitäisi siten vähentää palautusaikaa. Tämä kuulostaa hyvältä paperilla, mutta luku-algoritmi on useimmiten väärässä, mikä johtaa täysin tarpeettomiin tulo- ja lähtötoimintoihin, puhumattakaan suuresta RAM-kulutuksesta.

RAID-ryhmissä suositellaan korkeita lukuarvoja 1-8 Mt, mutta Android-laitteille on parasta vain jättää oletusarvo 128 KB.

Virtuaalimuistin hallintajärjestelmä tweaks

Toinen yleinen ”optimointitekniikka” on virtuaalimuistin hallintajärjestelmän viritys. Tämä kohdistaa tyypillisesti vain kaksi ytimen muuttujaa, vm.dirty_background_ratio ja vm.dirty_ratio, jotka on tarkoitettu puskurin koon säätämiseen “likaisen” tiedon tallentamiseksi. Likainen data on tyypillisesti levylle kirjoitettua tietoa, mutta muistia on vielä jäljellä ja odotetaan kirjoittamista levylle.

Tyypilliset säätöarvot sekä Linux-distrossa että Androisissa VM-hallintaosajärjestelmään olisivat seuraavat:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

Joten tämä yrittää tehdä, että kun likaisen tietopuskurin osuus on 10% RAM-muistin kokonaismäärästä, se herättää pdflush-prosessin ja alkaa kirjoittaa tietoja levylle - jos levylle tallennettujen tietojen käyttö on liian intensiivistä, puskuri kasvaa edelleen, ja kun se saavuttaa 20% käytettävissä olevasta RAM-muistista, järjestelmä siirtyy seuraavaan kirjoitusoperaatioon synkronisessa tilassa - ilman esipuskuria. Tämä tarkoittaa, että levylle kirjoittaminen on estetty, kunnes tiedot kirjoitetaan levylle (AKA 'lag').

Sinun tulisi ymmärtää, että vaikka puskurin koko ei saavuttaisi 10%, järjestelmä potkaisee automaattisesti pdflush-muodossa 30 sekunnin kuluttua. Yhdistelmä 10/20 on melko kohtuullinen, esimerkiksi laitteessa, jossa on 1 Gt RAM-muistia, tämä vastaa 100/200 Mt RAM-muistia, mikä on enemmän kuin tarpeeksi purskerekisterien suhteen, kun nopeus on usein alle NAND-järjestelmän nopeustietueen -muisti tai SD-kortti, kuten asennettaessa sovelluksia tai kopioidessasi tiedostoja tietokoneelta.

Jostain syystä käsikirjoittajat yrittävät nostaa tätä arvoa vielä korkeammalle, järjetömälle tasolle. Esimerkiksi Xplix- optimointikomentosarjasta löytyy jopa 50/90: n nopeus.

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

Laitteessa, jossa on 1 Gt muistia, tämä asettaa likaisen puskurin rajaksi 500/900 Mt, mikä on täysin hyödytöntä Android-laitteelle, koska se toimisi vain jatkuvan levyn tallennuksen yhteydessä - jotain, mikä tapahtuu vain raskaassa paikassa Linux-palvelin.

Thunderbolt! Komentosarja 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, toisessa - 1 Gt ja toisissa - yli 1 Gt. Mutta itse asiassa on vain yksi syy oletusasetusten muuttamiseen - laite, jolla on erittäin hidas sisäinen muisti tai muistikortti. Tässä tapauksessa on kohtuullista levittää muuttujien arvot, toisin sanoen tehdä jotain tällaista:

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

Sitten, kun aaltojärjestelmä kirjoittaa toimintoja, ilman, että sinun on tallennettava tietoja levylle, viimeinen ei siirry synkroniseen tilaan, mikä antaa sovelluksille mahdollisuuden vähentää viivettä nauhoitettaessa.

Lisähyödyttömät hienosäädöt ja suorituskyvyn viritys

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 jotakin suorituskyvyn näkökohtaa, samalla kun heikentävät laitetta muilla tavoilla ( yleensä se laskee suorituskykyyn verrattuna akun tyhjenemiseen) .

Tässä on joitain suosittuja lisäoptimointeja, joista voi olla hyötyä tai jotka eivät ehkä ole hyödyllisiä Android-järjestelmästä ja laitteesta riippuen.

Kiihdytys - Pieni kiihtyvyys suorituskyvyn ja alijäämän parantamiseksi - säästää vähän akkua.
Tietokannan optimointi - Teoriassa tämän pitäisi parantaa laitteen suorituskykyä, mutta se on epävarma.
Zipalign - Ironista kyllä, huolimatta sisäänrakennetusta Android SDK -ominaisuuden sisällön kohdistamisesta myymälän APK-tiedostoon, löydät paljon ohjelmistoja, joita ei siirretä zipalignin kautta.
Poista tarpeettomat järjestelmäpalvelut käytöstä poistamalla käyttämättömät järjestelmät ja harvoin käytetyt kolmansien osapuolien sovellukset. Pohjimmiltaan bloatware-ohjelmien asennuksen poistaminen.
Mukautettu ydin optimoinneilla tietylle laitteelle (jälleen kerran, kaikki ytimet eivät ole yhtä hyviä).
Jo kuvattu I / O-aikataulun noop.
Kylläisyysalgoritmi TCP Westwood - Käytetään tehokkaammin oletusarvoisessa Android Cubicissa langattomille verkoille, jotka ovat saatavana mukautettuihin ytimiin.

Hyödyt asetukset build.prop

XDA Developers -foorumin LaraCraft304 on suorittanut tutkimuksen ja havainnut, että vaikuttavalla määrällä /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_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.shutPHHJJAP.Mysy.shut.SP