Taigi daugelyje „viskas viename“ optimizavimo scenarijų naudojami tie patys metodai, kai kurie iš jų ilgainiui yra visiškai pasenę arba kenksmingi. Apibendrinant galima teigti, kad dauguma „viskas viename“ optimizavimo scenarijų yra ne kas kita, o rekomenduojami derinimai, nesuprantami, kaip ir kodėl šie optimizavimai veikia - vartotojai tada mirksto scenarijus ir teigia, kad jų veikimas staiga greitesnis ( iš tikrųjų greičiausiai padidėjo našumas dėl labai paprasto jų įrenginio perkrovimo , nes viskas išvaloma įrenginio RAM atmintyje) .
Šiame išskirtiniame „Appuals“ straipsnyje pabrėšime keletą dažniausiai naudojamų rekomendacijų optimizavimas “ „Android“ našumas ir tai, ar tai tiesiog mitas, ar teisėtas prietaiso našumo pakeitimas.
Keisti
Mitų sąrašo viršuje yra „Android“ apsikeitimo sandoris - tai yra gana absurdiška, nes jis laikomas „Android“ optimizavimu. Pagrindinis apsikeitimo tikslas yra sukurti ir prijungti ieškos failą, kuris atlaisvins atminties vietą. Tai skamba protingai ant lapo , bet ji tikrai taikoma a serverio , kuris beveik neturi interaktyvumo.
Kai reguliariai naudosite „Android“ telefono apsikeitimo sandorį, tai sukels rimtų atsilikimų, atsirandančių dėl to, kad viskas praeina pro talpyklą. Įsivaizduokite, pavyzdžiui, jei programa bando parodyti grafiką, kuris saugomas apsikeitimo sandėlyje, kuris dabar turi iš naujo įkelti diską, atlaisvinęs vietos, įdėdamas duomenų apsikeitimo su kita programa. Tai tikrai netvarkinga.
Kai kurie optimizavimo entuziastai gali pasakyti, kad apsikeitimas nesukėlė jokių problemų, tačiau tai nėra apsikeitimas, kuris padidina našumą - tai įmontuotas „Android“ mechanizmas lowmemorykiller , kuris reguliariai nužudys išsipūtusius, prioritetinius procesus, kurie nėra naudojami. LMK buvo sukurtas specialiai mažos atminties sąlygoms tvarkyti, yra naudojamas iš kswapd procesą ir paprastai užmuša vartotojo erdvės procesus. Tai skiriasi nuo OOMkiller (atminties žudikas), bet tai visai kita tema.
Esmė ta, kad įrenginys, kuriame yra, pavyzdžiui, 1 GB operatyviosios atminties, niekada negali pasiekti reikalingų našumo duomenų apsikeitimo būdu, todėl „Android“ sistemoje apsikeitimo nereikia. Jo įgyvendinimas yra tiesiog kupinas atsilikimo ir sukelia a degradacija veikime, o ne jį optimizuoti.
„zRAM“ - pasenęs ir nebeefektyvus
„zRAM“ yra patikrintas ir efektyvus prietaisų optimizavimo metodas, skirtas senesni įrenginiai - pagalvokite apie „KitKat“ pagrįstus įrenginius, kurie veikia tik apie 512 MB RAM. Tai, kad kai kurie žmonės vis dar įtraukia „zRAM“ patobulinimus į optimizavimo scenarijus arba rekomenduoja „zRAM“ kaip tam tikrą šiuolaikinį optimizavimo patobulinimą, yra pavyzdys, kai žmonės paprastai nesilaiko naujausių operacinių protokolų.
„zRAM“ buvo skirtas pradinio lygio biudžeto diapazono daugelio branduolių SoC, pvz., įrenginiams, naudojantiems MTK lustų rinkinius ir 512 MB RAM. Iš esmės labai pigūs kiniški telefonai. Iš esmės „zRAM“ daro tai, kad branduolį atskiria per šifravimo srautą.
Kai zRAM naudojamas senesniuose įrenginiuose su a vienas branduolys , net jei tokiems įrenginiams rekomenduojama naudoti „zRAM“, dideli atsilikimų kiekiai gali išaugti. Tai nutinka ir naudojant KSM technologiją ( Branduolio tas pats puslapis sujungiamas) kuri sujungia identiškus atminties puslapius, siekdama laisvos vietos. Tai iš tikrųjų rekomenduoja „Google“, tačiau tai lemia didesnius atsilikimus nuo senesnių įrenginių, nes nuolat aktyvios pagrindinės galvutės nuolat veikia iš atminties, kad būtų galima ieškoti pasikartojančių puslapių. Iš esmės bandymas paleisti optimizavimo koregavimą prietaisą dar labiau sulėtina, ironiškai.
Sėjamoji - pasenusi, nes „Android 3.0“
Vienas iš labiausiai diskutuojamų „Android“ kūrėjų optimizavimo patarimų yra kedras ir mes esame tikri, kad kas nors gali bandyti įrodyti, kad esame klaidingi šia tema, tačiau pirmiausia turime išnagrinėti sėjamosios istoriją.
„Seeder“ programa, skirta „Android“
Taip, yra daugybė pranešimų, kuriuose teigiama, kad įdiegus „Android“ veikia geriau daug senesni „Android“ įrenginiai . Tačiau žmonės dėl bet kokios priežasties mano, kad tai reiškia, kad tai taip pat yra tinkama optimizacija šiuolaikiniai „Android“ įrenginiai , kas yra absurdiška. Tai, kad sėjamoji vis dar yra prižiūrima ir siūloma kaip modernus “ atsilikimo mažinimo įrankis yra klaidingos informacijos pavyzdys, nors tai nėra „Seeder“ kūrėjo kaltė, nes net jų „Play Store“ puslapyje pažymima, kad „Seeder“ yra mažiau efektyvi po „Android 4.0+“. Vis dėlto dėl bet kokių priežasčių „Seeder“ vis dar pasirodo diskusijose apie šiuolaikines „Android“ sistemas.
Tai, ką „Seeder“ iš esmės daro „Android 3.0“, yra pašalinti klaidą, kur „Android“ vykdymo laikas aktyviai naudotų / dev / random / failą, kad gautų entropiją. „/ Dev / random / buffer“ taps nestabilus, o sistema bus užblokuota, kol užpildys reikiamą duomenų kiekį - pagalvokite apie mažus dalykus, pvz., Įvairius jutiklius ir mygtukus „Android“ įrenginyje.
Seederio autorius paėmė „Linux“ demoną rngd ir surinkta „Android“ inastroil, kad ji paimtų atsitiktinius duomenis iš daug greitesnio ir labiau nuspėjamo / dev / urandom kelio ir sujungtų juos į dev / random / kiekvieną sekundę, neleisdama / dev / random / išsisemti. Dėl to atsirado „Android“ sistema, kurioje netrūko entropijos ir ji veikė daug sklandžiau.
„Google“ sugadino šią klaidą po „Android 3.0“, tačiau dėl kažkokių priežasčių „Seeder“ vis dar pasirodo „Rekomenduojami patobulinimai“ „Android“ našumo optimizavimo sąrašai. Be to, „Seeder“ programoje yra keletas analogų, tokių kaip „sEFix“, kurie apima „Seeder“ funkcionalumą, nesvarbu, ar jie naudoja tą patį rngd arba alternatyva užvaldė , ar net tik simbolinė nuoroda tarp / dev / urandom ir / dev / random. Tai yra visiškai beprasmiška šiuolaikinėms „Android“ sistemoms.
Priežastis yra beprasmė, nes naujesnės „Android“ versijos naudoja / dev / random / trimis pagrindiniais komponentais - libcrypto , SSL ryšių šifravimui, SSH raktų generavimui ir kt. WPA_supplication / hostapd, kuris generuoja WEP / WPA raktus, ir galiausiai, kelios bibliotekos, skirtos generuoti ID kuriant EXT2 / EXT3 / EXT4 failų sistemas.
Todėl, kai Sėjamoji arba „Seeder“ pagrindu sukurti patobulinimai yra įtraukti į šiuolaikinius „Android“ optimizavimo scenarijus, o tai galų gale yra degradacija atliekant įrenginio veikimą, nes rngd nuolat pažadins įrenginį ir padidins procesoriaus dažnį, o tai, žinoma, neigiamai veikia akumuliatoriaus sąnaudas.
Odex
Akcijų programinė įranga „Android“ įrenginiuose beveik visada yra „odeksas“. Tai reiškia, kad šalia standartinio „Android“ programų paketo APK formatu, esančio / system / app / ir / system / priv-app /, yra tie patys failų pavadinimai su plėtiniu .odex. Oodex failuose yra optimizuoto baito kodo programų, kurios jau praėjo per tikrintuvą ir optimizavimo priemonę virtualioje mašinoje, tada įrašomos į atskirą failą, naudojant kažką dexopt įrankis.
Taigi, „Odex“ failai skirti iškrauti virtualią mašiną ir pasiūlyti pagreitintą „Oodexed“ programos paleidimą - trūkumai yra tai, kad ODEX failai neleidžia modifikuoti programinės aparatinės įrangos ir kelia problemų su atnaujinimais, todėl dėl šios priežasties platinama daugybė pasirinktinių ROM, tokių kaip „LineageOS“ be ODEX .
Generuoti ODEX failus galima įvairiais būdais, pavyzdžiui, naudojant „Odexer Tool“ - problema yra ta, kad jis yra vien tik placebo efektas. Kai šiuolaikinė „Android“ sistema neranda odex failų kataloge / system, sistema juos iš tikrųjų sukurs ir patalpins į katalogą / system / dalvik-cache /. Būtent taip atsitinka, kai, pavyzdžiui, mirksi nauja „Android“ versija ir kuriam laikui duoda pranešimą „Užimta, optimizuojamos programos“.
Lowmemorykiller patobulina
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ų foninių programų skaičiaus apribojimų ( nebent tai būtų nustatyta „Kūrėjo parinktyse“, tačiau tai paprastai nerekomenduojama) - be to, perėjimas prie fono vykdymo nenutrūksta, nors sistema pasilieka teisę užmušti fonines programas esant mažai atminties ( pažiūrėkite, kur anksčiau šiame vadove kalbėjome apie žudiką žudiką ir atminties žudiką) .
Norėdami grįžti į lowmemorykiller mechanizmas, „Android“ gali toliau veikti turėdamas ribotą atminties kiekį ir neturėdamas keitimo skaidinių. Vartotojas gali toliau paleisti programas ir persijungti tarp jų, ir sistema tyliai užmuš nenaudojamas fono programas, kad pabandytų atlaisvinti atmintį aktyvioms užduotims atlikti.
Tai buvo labai naudinga „Android“ pirmosiomis dienomis, nors dėl kažkokių priežasčių ji tapo populiari užduočių žudikų programomis, kurios paprastai yra labiau žalingos nei naudingos. Programos „Task-killer“ arba atsibunda nustatytais laiko intervalais, arba jas valdo vartotojas, ir atrodo, kad jos atlaisvina didelį kiekį RAM, o tai vertinama kaip teigiama - daugiau laisvos RAM reiškia greitesnį įrenginį, tiesa? Tačiau tai nėra tiksliai „Android“ atvejis.
Tiesą sakant, turint daug laisvos RAM, tai gali pakenkti jūsų įrenginio veikimui ir baterijos veikimo laikui. Kai programos yra saugomos „Android“ RAM, daug lengviau jas iškviesti, paleisti ir pan. „Android“ sistemai nereikia skirti daug išteklių pereinant prie programos, nes ji jau yra atmintyje.
Dėl šios priežasties užduočių žudikai iš tikrųjų nėra tokie populiarūs, kaip kadaise, nors „Android“ naujokai vis dar linkę jais pasikliauti dėl kažkokių priežasčių ( informacijos trūkumas, deja) . Deja, užduočių žudikus pakeitė nauja tendencija lowmemorykiller mechanizmo derinimas. Tai būtų, pavyzdžiui „MinFreeManager“ programą, o pagrindinė mintis yra padidinti RAM atmintį, kol sistema pradeda žudyti fono programas.
Pavyzdžiui, standartinė RAM veikia ribose - 4, 8, 12, 24, 32 ir 40 Mb, o užpildžius 40 MB laisvos vietos, viena iš talpykloje saugomų programų, įkeliama į atmintį bet nebėga bus nutrauktas.
Taigi iš esmės „Android“ visada turės mažiausiai 40 MB laisvos atminties, kurios pakanka, kad anksčiau būtų galima pritaikyti dar vieną programą lowmemorykiller pradeda savo valymo procesą - tai reiškia, kad „Android“ visada stengsis išnaudoti maksimalų turimą RAM kiekį netrukdydamas vartotojo patirčiai.
Deja, kai kurie namų ruošos entuziastai pradėjo rekomenduoti, kad vertė padidėtų iki, pavyzdžiui, 100 MB, prieš pradedant LMK. Dabar vartotojas iš tikrųjų pralaimėti RAM (100 - 40 = 60), taigi, užuot naudojusi šią vietą atsarginėms programoms saugoti, sistema išlaikys tokį atminties kiekį Laisvas , visiškai neturint tam tikslo.
LKM derinimas gali būti naudinga daug senesniems įrenginiams, turintiems 512 RAM, bet kam jie daugiau priklauso? 2 GB yra šiuolaikinis „biudžeto asortimentas“, net 4 GB RAM įrenginiai šiais laikais atrodo „vidutinio lygio“, todėl LMK patobulinimai yra tikrai pasenę ir nenaudingi.
Įvesties / išvesties patobulinimai
Daugelyje „Android“ optimizavimo scenarijų dažnai rasite patobulinimų, nukreipiančių į įvesties / išvesties posistemį. Pavyzdžiui, leidžia pažvelgti į „ThunderBolt“! Scenarijus, kuriame yra šios eilutės:
aidas 0> $ i / eilė / rotacija; echo 1024> $ i / queue / nr_requests;
Pirmoje eilutėje bus nurodytos įvesties / išvesties tvarkyklės instrukcijos, susijusios su SSD, o antroji padidina maksimalų eilės įvesties / išvesties dydį nuo 128 iki 1024 - nes kintamajame $ i yra kelias į blokinių įrenginių medį / sys, o scenarijus veikia cikle.
Po to rasite eilutę, susijusią su CFQ planuokliu:
1 aidas> $ 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 galų gale pirmosios dvi komandos yra beprasmės, nes:
Šiuolaikinis „Linux“ branduolys gali suprasti, su kokia laikmena jis dirba pagal numatytuosius nustatymus.
Ilga įvesties ir išvesties eilė ( pvz., 1024) yra nenaudingas šiuolaikiniame „Android“ įrenginyje, iš tikrųjų jis netenka prasmės net darbalaukyje - jį iš tikrųjų rekomenduojama naudoti tik sunkiųjų serverių . Jūsų telefonas nėra sunkiųjų „Linux“ serveris.
„Android“ įrenginyje praktiškai nėra programų, kurioms teikiama pirmenybė įvestyje-išvestyje, ir nėra mechaninio tvarkyklės, todėl geriausias planuotojas yra „noop“ / „FIFO“ eilė, todėl šio tipo planuoklis “ įgnybti “ nedaro nieko ypatingo ar prasmingo įvesties / išvesties posistemiui. Tiesą sakant, visas šias kelių ekranų sąrašo komandas geriau pakeisti paprastu ciklu:
i i / sys / block / mmc *; do echo noop> $ i / queue / planer echo 0> $ i / queue / iostats done
Tai leistų kaupti įvesties / išvesties statistiką visų diskų langų planavimo priemonę, o tai turėtų teigiamai paveikti našumą, nors ir labai mažą ir beveik nereikšmingą.
Kitas nenaudingas įvesties / išvesties patobulinimas, dažnai randamas našumo scenarijuose, yra padidintos iki 2 MB SD kortelių nuskaitymo vertės. Skaitymo iš anksto mechanizmas skirtas ankstyviems duomenims nuskaityti iš žiniasklaidos, kol programa prašo prieigos prie tų duomenų. Taigi iš esmės branduolys bandys išsiaiškinti, kokių duomenų reikės ateityje, ir iš anksto juos įkelti į RAM, todėl turėtų sumažėti grąžinimo laikas. Popieriuje tai skamba puikiai, tačiau skaitymo į priekį algoritmas yra dažnesnis neteisinga , kuris lemia visiškai nereikalingas įvesties-išvesties operacijas, jau nekalbant apie didelį RAM suvartojimą.
RAID masyvuose rekomenduojamos didelės 1–8 MB perskaičiavimo vertės, tačiau „Android“ įrenginiams geriausia tiesiog palikti numatytąją 128 KB vertę.
Virtualioji atminties valdymo sistema patobulinta
Kita įprasta „optimizavimo“ technika yra virtualiosios atminties valdymo posistemio derinimas. Paprastai tai taikoma tik dviem branduolio kintamiesiems - „vm.dirty_background_ratio“ ir „vm.dirty_ratio“, kurie skirti buferio dydžiui koreguoti saugant „nešvarius“ duomenis. Purvinas duomenys paprastai yra duomenys, kurie buvo įrašyti į diską, tačiau jų dar yra atmintyje ir laukiama, kol bus įrašyti į diską.
Tiek „Linux“ distros, tiek „Androis“ tipinės VM valdymo posistemio vertės yra tokios:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Taigi tai bandoma padaryti tai, kad kai nešvarių duomenų buferis sudaro 10% viso RAM kiekio, jis pabunda pdflush srautas ir pradeda rašyti duomenis į diską - jei bus duomenų įrašymo į diską operacija per intensyvus , buferis ir toliau augs, o kai jis pasieks 20% laisvos RAM, sistema persijungs į tolesnę rašymo operaciją sinchroniniu režimu - be išankstinio buferio. Tai reiškia, kad bus atliekamas darbas rašant į diską užblokuota, kol duomenys bus įrašyti į diską (AKA ‘atsilikimas’).
Ką turėtumėte suprasti, net jei buferio dydis nesiekia 10 proc. , sistema automatiškai pradės veikti po 30 sekundžių. 10/20 derinys yra gana pagrįstas, pavyzdžiui, įrenginyje, kuriame yra 1 GB RAM, tai prilygtų 100/200 MB RAM, o tai yra daugiau nei pakankamai, atsižvelgiant į serijos įrašus, kur greitis dažnai yra mažesnis nei greičio įrašas sistemoje NAND atminties arba SD kortelę, pavyzdžiui, kai diegiate programas ar kopijuojate failus iš kompiuterio.
Kažkodėl scenaristų autoriai bando šią vertę dar labiau pakelti iki absurdiškų rodiklių. Pavyzdžiui, galime rasti „Xplix“ optimizavimo scenarijaus rodiklis siekia 50/90.
sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90
Įrenginyje, kuriame yra 1 GB atminties, nešvaraus buferio riba yra 500/900 MB, o tai visiškai nenaudinga „Android“ įrenginiui, nes jis veiktų tik esant nuolatinis įrašymas į diską - kažkas, kas vyksta tik sunkiame „Linux“ serveryje.
„ThunderBolt“! Scenarijus naudoja labiau pagrįstą vertę, tačiau apskritai jis vis dar 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 RAM, antroji - su 1 GB, o kitos - su daugiau nei 1 GB. Tačiau iš tikrųjų yra tik viena priežastis pakeisti numatytuosius nustatymus - įrenginys su labai lėta vidine atmintimi arba atminties kortele. Šiuo atveju tikslinga skleisti kintamųjų reikšmes, ty padaryti kažką panašaus:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Tada, kai viršįtampių sistema rašo operacijas, nereikalaudama įrašyti duomenų į diską, iki paskutiniųjų nebus perjungta į sinchroninį režimą, o tai leis programoms sumažinti įrašymo vėlavimą.
Papildomi nenaudingi patobulinimai ir atlikimo derinimas
Yra daug daugiau „optimizacijų“, kurios tikrai nieko nedaro. Daugelis jų tiesiog neturi jokio poveikio, o kiti gali pagerėti kai kurie veikimo aspektu, tuo pačiu pažeisdamas prietaisą kitais būdais ( paprastai tai lemia našumą, palyginti su akumuliatoriaus išsekimu) .
Pateikiame keletą papildomų populiarių optimizavimo būdų, kurie gali būti nenaudingi, atsižvelgiant į „Android“ sistemą ir įrenginį.
- Pagreitis - nedidelis pagreitis, siekiant pagerinti našumą ir nepakankamą įtampą, taupo šiek tiek baterijos.
- Duomenų bazės optimizavimas - teoriškai tai turėtų pagerinti įrenginio veikimą, tačiau abejotinas.
- „Zipalign“ - Ironiška, kad nepaisant įmontuoto „Android SDK“ funkcijų turinio suderinimo parduotuvės APK faile, galite rasti, kad daug programinės įrangos nėra perduodama 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“.
- Pasirinktinis branduolys su konkretaus įrenginio optimizavimu (vėlgi, ne visi branduoliai yra vienodai geri).
- Jau aprašyta įvesties / išvesties planavimo priemonė.
- „Saturation“ algoritmas „TCP Westwood“ - efektyviau naudojamas numatytame „Android Cubic“ belaidžiams tinklams, prieinamas pasirinktiniuose branduoliuose.
Nenaudingi nustatymai build.prop
„Xara Developers“ forumo „LaraCraft304“ atliko tyrimą ir nustatė, kad įspūdingo skaičiaus /system/build.prop nustatymų, kuriuos rekomenduojama naudoti „ekspertams“, nėra šaltinio 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. 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.Pys.Pys.Pod.Žymos androidas Plėtra 12 minučių perskaityta
