Debunked dažniausiai pasitaikantys „Android“ optimizavimo mitai

Yra daugybė instrukcijų, skirtų padidinti „Android“ našumą, ir bendrus optimizavimo patarimus. Kai kurie iš jų yra teisėti, o kiti yra pagrįsti tik teoriškai arba pasenusiais operaciniais metodais „Android“ sistemoje arba yra tiesiog nesąmonė. Tai apima apsikeitimo rekomendacijas, pridedamas reikšmes build.prop ir kintamus „Linux“ branduolio pakeitimus.

Yra net daugybė „optimizavimo scenarijų“, „viskas viename“ mirksi .zip, kurie žada žymiai padidinti našumą, baterijos veikimą ir kitus dalykus. Kai kurie patarimai iš tikrųjų gali veikti, tačiau dauguma jų yra tiesiog placebo efektas arba, dar blogiau, iš tikrųjų daro neigiamą poveikį jūsų įrenginiui.

Tai nereiškia, kad žmonės sąmoningai išleidžia įvairius scenarijus - „Google Play“ parduotuvėje tikrai yra fiktyvių mokamų programų, tačiau „Android“ forumuose išleidžiami optimizavimo scenarijai paprastai yra geranoriški, tiesiog taip nutinka, kad kūrėjas gali būti neteisingai informuotas, arba tiesiog eksperimentuokite su įvairiais optimizavimo patarimais. Deja, būdingas tam tikras sniego gniūžtės efektas, ypač „viskas viename“ optimizavimo scenarijuose. Nedidelė sauja pataisų gali iš tikrųjų ką nors padaryti, o kitas scenarijaus pataisų rinkinys gali visiškai nieko nedaryti - vis dėlto šie scenarijai perduodami kaip stebuklingos kulkos, neatlikus jokio tyrimo apie tai, kas veikia, o kas ne .

Taigi daugybė optimizavimo scenarijų „viskas viename“ naudoja tuos pačius metodus, kai kurie iš jų yra visiškai pasenę arba kenksmingi ilgainiui. Apibendrinant galima pasakyti, kad didžioji dalis „viskas viename“ optimizavimo scenarijų yra ne kas kita, kaip kartu sušlapti rekomenduojami derinimai, neturint aiškios idėjos, kaip ir kodėl šie optimizavimai veikia - vartotojai tada mirksi scenarijus ir tvirtina, kad jų atlikimas staiga spartėja. ( kai iš tikrųjų greičiausiai labai paprastas jų įrenginio paleidimas iš naujo paskatino našumą, nes viskas, kas yra įrenginio RAM, bus išvalyta) .

Šiame išskirtiniame „Appuals“ straipsnyje išryškinsime dažniausiai pasitaikančias „ Android“ našumo „ optimizavimo“ rekomendacijas ir tai, ar jos yra tik mitas, ar teisėtas prietaiso našumo keitimas.

Keisti

Mito sąrašo viršuje yra „Android“ apsikeitimo priemonė - tai yra gana absurdiška mintis apie „Android“ optimizavimą. Pagrindinis mainų tikslas yra sukurti ir prijungti ieškos failą, kuris atlaisvins atminties vietą. Tai popieriuje skamba protingai, tačiau tikrai tinka serveriui, kuris beveik neturi interaktyvumo.

Kai reguliariai naudojate „Android“ telefono mainų funkciją, tai gali sukelti didelius atsilikimus, atsirandančius dėl daiktų, slenkančių per talpyklą. Pvz., Įsivaizduokite, jei programa bando pateikti grafiką, išsaugotą mainų faile, kuris dabar turi iš naujo įkelti diską, atlaisvinęs vietos, įdėdamas duomenų mainus į kitą programą. Tai tikrai nepatogu.

Kai kurie optimizavimo entuziastai gali pasakyti, kad apsikeitimas nesudarė jokių problemų, tačiau tai nėra keitimas, dėl kurio našumas padidėja - tai įmontuotas „Android“ mechanizmas „ lowmemorykiller“, kuris reguliariai naikins išsipūtusius, aukšto prioriteto procesus, kurie nenaudojami. LMK buvo sukurtas specialiai mažos atminties sąlygoms tvarkyti, yra iškviečiamas iš „ kswapd“ proceso ir paprastai žudo vartotojo erdvės procesus. Tai skiriasi nuo „ OOMkiller“ (žudikas, kuriam trūksta atminties), tačiau tai visai kita tema.

Esmė ta, kad įrenginys su, pavyzdžiui, 1 GB operatyviosios atminties, niekada negali pasiekti reikiamų duomenų apie mainus, taigi „Android“ sistemoje apsikeitimo priemonė tikrai nėra reikalinga. Jo įgyvendinimas tiesiog užtrunka ir lemia veiklos pablogėjimą, o ne optimizavimą.

„zRAM“ - pasenęs ir nebeefektyvus

„zRAM“ yra patikrintas ir veiksmingas prietaisų optimizavimo būdas, senesniems įrenginiams - pagalvokite apie „KitKat“ pagrįstus įrenginius, kurie veikia tik apie 512 MB RAM. Tai, kad kai kurie žmonės vis dar įtraukia „zRAM“ pataisas į optimizavimo scenarijus, arba rekomenduoja „zRAM“ kaip tam tikrą šiuolaikišką optimizavimo pataisą, yra pavyzdys, kai žmonės paprastai nesilaiko naujausių veiklos protokolų.

„zRAM“ buvo skirtas pradinio lygio biudžeto diapazono daugiagysliams SoC, pavyzdžiui, įrenginiams, naudojantiems MTK mikroschemų rinkinius, ir 512 MB RAM. Iš esmės labai pigūs kinietiški telefonai. Tai, ką iš esmės daro „zRAM“, yra branduolio atskyrimas per šifravimo srautą.

Kai „zRAM“ naudojamas senesniuose įrenginiuose, turinčiuose vieną šerdį, net jei tokiems įrenginiams rekomenduojama naudoti „zRAM“, dideli atsilikimo kiekiai linkę išbristi. Tai atsitinka ir su KSM technologija („ Kernel Same Page Merging“), kuri sujungia identiškus atminties puslapius ir siūlo laisvą vietą. Tai iš tikrųjų rekomenduoja „Google“, tačiau dėl to senesniuose įrenginiuose atsiliekama daugiau, nes nuolat aktyvios pagrindinės temos nuolat veikia iš atminties, ieškant pasikartojančių puslapių. Iš esmės, bandant paleisti optimizavimo pataisą, dar labiau ironizuojama, kad įrenginys sulėtėja.

Sėjamoji - pasenusi nuo „Android 3.0“

Vienas iš labiausiai „Android“ kūrėjų aptariamų optimizavimo patarimų yra sėjamoji ir esame tikri, kad kas nors gali bandyti įrodyti, kad suklydome šia tema, tačiau pirmiausia turime ištirti sėjamosios istoriją.

Taip, yra daugybė ataskaitų, skelbiančių geresnį „Android“ našumą įdiegus ją daug senesniuose „Android“ įrenginiuose . Tačiau žmonės dėl bet kokios priežasties mano, kad tai taip pat yra šiuolaikinių „Android“ įrenginių optimizavimas, o tai yra absoliučiai absurdiška. Klaidingos informacijos pavyzdys yra faktas, kad „Seeder“ vis dar prižiūrimas ir siūlomas kaip „ modernus“ atsilikimo mažinimo įrankis - nors tai nėra „Seeder“ kūrėjo kaltė, nes net jų „Play Store“ puslapis pažymi, kad „Seeder“ yra mažiau efektyvus po „Android 4.0“ ar naujesnės versijos. Tačiau dėl kokių nors priežasčių Seederis vis dar pasirodo diskusijose apie šiuolaikinių „Android“ sistemų optimizavimą.

Tai, ką „Seeder“ iš esmės daro „Android 3.0“, yra klaidos pašalinimas, kai „Android“ vykdymo laikas aktyviai naudotų / dev / random / failą, norėdamas įgyti entropiją. / Dev / random / buffer taptų nestabili, o sistema būtų blokuojama, kol ji užpildys reikiamą duomenų kiekį - pagalvokite apie tokias smulkmenas, kaip įvairūs jutikliai ir mygtukai „Android“ įrenginyje.

Sėjamojo autorius paėmė „Linux-demon rngd“ ir sudarė „Android“ inastroilį, kad paimtų atsitiktinius duomenis iš daug greitesnio ir labiau nuspėjamo / dev / urandom kelio ir sujungtų juos į dev / random / kiekvieną sekundę, neleidžiant / dev / random / išsekti. Dėl to atsirado „Android“ sistema, kuri nepatyrė entropijos ir veikė daug sklandžiau.

„Google“ sutriuškino šią klaidą po „Android 3.0“, tačiau dėl tam tikrų priežasčių Seederis vis dar pasirodo „rekomenduojamų patarimų“ sąrašuose, kad būtų galima optimizuoti „ Android“ našumą. Be to, „Seeder“ programa turi keletą analogų, tokių kaip „SEFix“, apimanti „Seeder“ funkcionalumą, nesvarbu, ar naudojamas tas pats rngd, ar alternatyvus pakeitimas, ar netgi tiesiog nuorodą tarp / dev / urandom ir / dev / random. Tai visiškai beprasmiška šiuolaikinėms „Android“ sistemoms.

Tai beprasmiška todėl, kad naujesnės „Android“ versijos naudoja / dev / random / trijuose pagrindiniuose komponentuose - libcrypto, kad šifruotų SSL ryšius, generuotų SSH raktus ir kt. WPA_supplication / hostapd, kuris generuoja WEP / WPA raktus, ir, pagaliau, sauja bibliotekos ID generavimui kuriant EXT2 / EXT3 / EXT4 failų sistemas.

Taigi, kai „ Seeder“ ar „Seeder“ pagrindu sukurti patobulinimai yra įtraukti į šiuolaikinius „Android“ optimizavimo scenarijus, galų gale pablogėja įrenginio našumas, nes „ rngd “ nuolat pažadins įrenginį ir padidins procesoriaus dažnį, o tai, žinoma, neigiamai veikia akumuliatoriaus sunaudojimą. .

Odex

Akcijų programinė įranga „Android“ įrenginiuose beveik visada „odex“. Tai reiškia, kad greta standartinio „Android“ programų paketo, esančio APK formatu, rasti aplanke / system / app / ir / system / priv-app / yra tų pačių failų pavadinimai su plėtiniu .odex. „Odex“ failuose yra optimizuotos baitų kodo programos, kurios jau praėjo per validatorių ir optimizatorių virtualią mašiną, tada įrašomos į atskirą failą naudojant kažką panašaus į „ dexopt“ įrankį.

Taigi, „odex“ failai yra skirti iškrauti virtualią mašiną ir pasiūlyti pagreitintą pataisytos programos paleidimą - blogiausia, kad „ODEX“ failai neleidžia modifikuoti programinės įrangos ir sukelia problemų dėl atnaujinimų, todėl dėl šios priežasties daugelis pasirinktinių ROM, tokių kaip „LineageOS“, yra platinami be ODEX .

ODEX failai generuojami keliais būdais, pavyzdžiui, naudojant „Odexer Tool“ - problema ta, kad jų grynasis placebo efektas. Kai šiuolaikinė „Android“ sistema neranda odex failų / sistemos kataloge, sistema iš tikrųjų juos sukurs ir įdės į katalogą / sistema / dalvik-cache /. Būtent taip atsitinka, kai, pavyzdžiui, mirksi nauja „Android“ versija ir tam tikrą laiką pasirodo pranešimas „Užimta, programų optimizavimas“.

„Lowmemorykiller“ tweaks

Daugiafunkcinis darbas „Android“ skiriasi nuo kitų mobiliųjų operacinių sistemų tuo, kad jis pagrįstas klasikiniu modeliu, kai programos veikia tyliai fone, ir nėra jokių fono programų skaičiaus apribojimų ( nebent vienas yra nustatytas kūrėjo parinktyse, bet tai yra paprastai nerekomenduojama), be to, nėra sustabdomas perėjimo prie foninio vykdymo funkcionalumas, nors sistema pasilieka teisę naikinti fonines programas silpnos atminties situacijose ( žr. kur anksčiau kalbėjome apie „lowmemorykiller“ ir „out of atminties žudiklius“ vadovas) .

Norėdami grįžti prie „ lowmemorykiller“ mechanizmo, „Android“ gali toliau veikti, turėdama ribotą atminties kiekį ir trūkstant apsikeitimo skaidinio. Vartotojas gali tęsti programų paleidimą ir perjungti iš jų, o sistema tyliai užmuš nenaudojamas fonines programas, kad pabandytų atlaisvinti atmintį aktyvioms užduotims atlikti.

Tai buvo labai naudinga „Android“ nuo pat pirmųjų dienų, nors dėl tam tikrų priežasčių jis tapo populiarus užduočių žudikių programų pavidalu, kurios paprastai yra labiau žalingos nei naudingos. Užduočių žudymo programos arba atsibunda nustatytais laiko tarpais, arba jas palaiko vartotojas ir atrodo, kad jos atlaisvina daug RAM, o tai vertinama kaip teigiama - daugiau laisvos RAM reiškia greitesnį įrenginį, tiesa? Tačiau ne visai taip yra su „Android“.

Tiesą sakant, didelis laisvosios atminties kiekis gali pakenkti jūsų įrenginio veikimui ir akumuliatoriaus veikimo laikui. Kai programos yra saugomos „Android“ RAM, daug lengviau jas sušaukti, paleisti ir tt „Android“ sistemai nereikia skirti daug išteklių perjungimui į programą, nes ji jau yra atmintyje.

Dėl šios priežasties užduočių žudikai nėra tokie populiarūs kaip kadaise, nors „Android“ naujokai vis tiek linkę pasikliauti jais dėl tam tikrų priežasčių ( deja, trūksta informacijos) . Deja, užduočių žudiklius pakeitė nauja tendencija - žemų atminties žudikų mechanizmų derinimo tendencija. Tai galėtų būti, pavyzdžiui, „ MinFreeManager“ programa, o pagrindinė idėja yra padidinti RAM pridėtinę vertę prieš sistemai pradėjus žudyti fonines programas.

Pavyzdžiui, standartinė operatyvioji atmintis veikia ribose - 4, 8, 12, 24, 32 ir 40 Mb, o užpildžius 40 MB laisvos vietos saugykloje, viena iš talpykloje laikomų programų, įkelta į atmintį, bet neveikianti bus nutrauktas.

Taigi iš esmės „Android“ visada turės mažiausiai 40 MB laisvos atminties, kurios pakaks, kad būtų galima pritaikyti dar vieną programą, kol „ lowmemorykiller“ pradės valymo procesą - tai reiškia, kad „Android“ visada stengsis išnaudoti maksimalų turimos RAM kiekį, netrukdydama vartotojo patirtis.

Deja, kai kurie namų mėgėjai entuziastai rekomendavo, kad vertė padidėtų iki, pavyzdžiui, 100 MB, prieš pradedant „LMK“. Dabar vartotojas iš tikrųjų praras RAM (100–40 = 60), todėl vietoj to, kad naudotųsi šia vieta saugoti atgal, programų pabaigos, sistema neturės tokio atminties kiekio ir visiškai neturės tam tikslo.

„LKM“ tiuningas gali būti naudingas daug senesniems įrenginiams, turintiems 512 RAM, bet kam jie jau priklauso? 2 GB yra modernus „biudžetinis diapazonas“, net 4 GB RAM įrenginiai šiomis dienomis vertinami kaip „vidutinio nuotolio“ įrenginiai, todėl „LMK“ patarimai yra tikrai pasenę ir nenaudingi.

I / O tweaks

Daugybėje „Android“ optimizavimo scenarijų dažnai rasite patarimų, nukreipiančių į I / O posistemį. Pavyzdžiui, pažiūrėkime į „ ThunderBolt“! Scenarijus, kuriame yra šios eilutės:

 echo 0> $ i / eilė / pasukimas; echo 1024> $ i / eilė / nr_requests; 

Pirmoje eilutėje bus pateiktos I / O planavimo instrukcijos, susijusios su SSD, o antroji padidins maksimalų eilės įvesties / išvesties dydį nuo 128 iki 1024 - nes kintamajame $ i yra kelias į blokų įrenginių medį. / sys, o scenarijus vykdomas kilpoje.

Po to rasite eilutę, susijusią su CFQ planuokle:

 echo 1> $ i / eilė / iosched / back_seek_penalty; echo 1> $ i / eilė / iosched / low_latency; echo 1> $ i / eilė / iosched / slice_idle; 

Po to eina daugiau eilučių, priklausančių kitiems planuotojams, tačiau galiausiai pirmosios dvi komandos yra beprasmės, nes:

Šiuolaikinis „Linux“ branduolys sugeba suprasti, kokio tipo laikmeną jis veikia pagal numatytuosius nustatymus.

Ilga įvesties ir išvesties eilė ( tokia kaip 1024) yra nenaudinga šiuolaikiniame „Android“ įrenginyje, iš tikrųjų ji neturi prasmės net darbalaukyje - ji tikrai rekomenduojama tik sunkiuose serveriuose . Jūsų telefonas nėra sunkiųjų Linux serverių.

„Android“ įrenginyje praktiškai nėra programų, kurioms būtų suteiktas prioritetas įvesties ir išvesties sistemose, ir nėra mechaninės tvarkyklės, todėl geriausias planuotojas yra „noop“ / „FIFO“ eilės, taigi šio tipo planuoklis „ įsitaiso“ nedaro nieko ypatingo ar prasmingo. I / O posistemis. Tiesą sakant, visas šias kelių ekranų sąrašų komandas geriau pakeisti paprastu ciklu:

 i in / sys / block / mmc *; do echo noop> $ i / eilė / planuoklė echo 0> $ i / eilė / iostats padaryta 

Tai sudarytų galimybę kaupti I / O statistinius duomenis visų diskų taškų planavimo priemonėms, o tai turėtų daryti teigiamą poveikį našumui, nors ir labai maža ir beveik visiškai nereikšminga.

Kitas nenaudingas I / O keitimas, dažnai sutinkamas vykdymo scenarijuose, yra padidintos SD kortelių skaitymo vertės iki 2 MB. Perskaitymo mechanizmas yra skirtas ankstyvam duomenų nuskaitymui iš laikmenos, prieš programai paprašant prieigos prie tų duomenų. Taigi iš esmės branduolys bandys išsiaiškinti, kokių duomenų prireiks ateityje, ir iš anksto įkelia juos į RAM, o tai turėtų sutrumpinti grąžinimo laiką. Tai skamba puikiai popieriuje, tačiau perskaitymo algoritmas dažniausiai būna klaidingas, o tai lemia visiškai nereikalingas įvesties ir išvesties operacijas, jau nekalbant apie didelį RAM sunaudojimą.

RAID masyvuose rekomenduojamos didelės skaitymo vertės nuo 1 iki 8 MB, tačiau „Android“ įrenginiams geriausia palikti numatytąją 128 KB reikšmę.

Virtualiosios atminties valdymo sistema pataisos

Kitas įprastas „optimizavimo“ būdas yra virtualiosios atminties valdymo posistemio derinimas. Paprastai tai taikoma tik dviem branduolio kintamiesiems: vm.dirty_background_ratio ir vm.dirty_ratio, kurie yra skirti pritaikyti buferio dydį, kad būtų galima saugoti „nešvarius“ duomenis. Nešvarūs duomenys paprastai yra duomenys, įrašyti į diską, tačiau jų vis dar yra atmintyje ir laukiama, kol jie bus įrašyti į diską.

Tipiškos „Linux“ ir „Androis“ displėjaus vertės, susijusios su VM valdymo posistemiu, yra tokios:

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Taigi tai bandoma padaryti, kai nešvarių duomenų buferis sudaro 10% visos RAM sumos, jis pažadina „ pdflush“ srautą ir pradeda rašyti duomenis į diską - jei duomenų įrašymo į diską operacija bus per daug intensyvi, buferis toliau augs, o kai jis pasieks 20% turimos RAM, sistema pereis į sekančią rašymo operaciją sinchroniniu režimu - be išankstinio buferio. Tai reiškia, kad rašymo į diską programa bus blokuojama, kol duomenys nebus įrašomi į diską (AKA 'atsilikimas').

Jūs turėtumėte suprasti, kad net jei buferio dydis nesiekia 10%, sistema automatiškai įsijungs pdflush po 30 sekundžių. 10/20 derinys yra gana pagrįstas, pavyzdžiui, įrenginyje, kuriame yra 1 GB operatyviosios atminties, tai prilygtų 100/200 MB RAM, o tai yra daugiau nei pakankamai, kalbant apie „burst“ įrašus, kai greitis dažnai yra mažesnis nei NAND sistemos greitis - atminties arba SD kortelę, pvz., diegiant programas ar kopijuojant failus iš kompiuterio.

Dėl tam tikrų priežasčių scenarijų rašytojai bando šią vertę nustumti dar aukščiau, iki absurdiškų normų. Pavyzdžiui, „ Xplix“ optimizavimo scenarijuje galime rasti net 50/90 greitį.

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

Įrenginyje, kuriame yra 1 GB atminties, nešvarus buferis ribojamas iki 500/900 MB, o tai visiškai nenaudinga „Android“ įrenginiui, nes jis veiktų tik esant nuolatiniam įrašymui diske - kažkas, kas nutinka tik esant sunkiems įrenginiams. „Linux“ serveris.

„ThunderBolt“! Scenarijus naudoja labiau pagrįstą vertę, tačiau apskritai jis vis dar yra gana beprasmis:

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

Pirmosios dvi komandos vykdomos išmaniuosiuose telefonuose su 512 MB operatyviosios atminties, antraisiais - su 1 GB, o kitomis - su daugiau nei 1 GB. Tačiau iš tikrųjų yra tik viena priežastis pakeisti numatytuosius nustatymus - prietaisas su labai lėta vidine atmintimi arba atminties kortele. Šiuo atveju protinga paskirstyti kintamųjų reikšmes, tai yra padaryti kažką panašaus:

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

Tada, kai viršįtampių sistema užrašys operacijas ir nereikės įrašyti duomenų į diską, iki paskutinės nebus perjungta į sinchroninį režimą, o tai leis programoms sumažinti įrašymo vėlavimą.

Papildomi nenaudingi patarimai ir atlikimo derinimai

Yra daug daugiau „optimizacijų“, kurios iš tikrųjų nieko nedaro. Daugelis jų tiesiog neturi jokio poveikio, o kiti gali pagerinti kai kuriuos eksploatacinius parametrus, tuo pačiu pablogindami įrenginį kitais būdais ( paprastai jis tampa našesnis nei akumuliatoriaus eikvojimas) .

Čia yra keletas papildomų populiarių optimizacijų, kurios gali būti arba gali būti nenaudingos, atsižvelgiant į „Android“ sistemą ir įrenginį.

• Pagreitis - nedidelis pagreitis, kuris pagerina našumą ir apkrovą - taupo mažai akumuliatoriaus.
• Duomenų bazės optimizavimas - teoriškai tai turėtų pagerinti įrenginio veikimą, tačiau tai abejotina.
• „Zipalign“ - ironiška, kad nepaisant integruoto „Android SDK“ funkcijos turinio suderinimo per APK failą parduotuvėje, galite rasti daug programinės įrangos neperduodami per zipalign.
• Išjunkite nereikalingas sistemos paslaugas, pašalindami nenaudojamą sistemą ir retai naudojamas trečiųjų šalių programas. Iš esmės pašalinti „bloatware“.
• Individualizuotas branduolys su optimizacijomis konkrečiam įrenginiui (vėlgi, ne visi branduoliai yra vienodai geri).
• Jau aprašytas įvesties / išvesties planuoklis.
• Sotumo algoritmas TCP Westwood - efektyviau naudojamas numatytajame „Android Cubic“ belaidžiams tinklams, prieinamiems pasirinktiniuose branduoliuose.

Nenaudingi parametrai build.prop

„LaraCraft304“ iš „XDA Developers“ forumo atliko tyrimą ir nustatė, kad įspūdingo skaičiaus /system/build.prop nustatymų, kuriuos rekomenduojama naudoti „ekspertams“, nėra šaltinių AOSP ir „CyanogenMod“. Štai sąrašas:

 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 eADIST.sys.shutPHPJ.Jemop.sys.shut.pc