Tako veliko optimizacijskih skriptov vse v enem uporablja enake metode, nekatere pa so popolnoma zastarele ali dolgoročno škodljive. Če povzamemo, večina optimizacijskih skriptov 'vse v enem' niso nič drugega kot priporočene nastavitve, brez jasne ideje, kako in zakaj te optimizacije 'delujejo - uporabniki nato utripajo skripte in trdijo, da je njihova zmogljivost nenadoma hitrejša ( ko pa je pravzaprav zelo preprosto dejanje ponovnega zagona njihove naprave povzročilo povečanje zmogljivosti , ker se v RAM-u naprave očisti vse) .
V tem ekskluzivnem članku Appuals bomo izpostavili nekaj najpogostejših priporočil za » optimizacija ' Uspešnost Androida in ne glede na to, ali gre zgolj za mit ali legitimen popravek zmogljivosti naprave.
Zamenjaj
Na vrhu seznama mitov je zamenjava Androida - kar je precej absurdno v smislu, da se nanjo gleda kot na optimizacijo Androida. Glavni namen zamenjave je ustvariti in povezati ostranjevalno datoteko, kar bo sprostilo prostor za shranjevanje v pomnilniku. To se sliši smiselno na papirju , vendar je resnično uporaben za a strežnik , ki skoraj nima interaktivnosti.
Ko redno uporabljate zamenjavo telefona Android, bo prišlo do resnih zaostankov, ki izhajajo iz stvari, ki zdrsnejo mimo predpomnilnika. Predstavljajte si, na primer, če aplikacija poskuša prikazati grafiko, ki je shranjena v zamenjavi, ki mora zdaj znova naložiti disk, potem ko je sprostila prostor, tako da je zamenjala podatke z drugo aplikacijo. Res je neurejeno.
Nekateri navdušenci nad optimizacijo lahko trdijo, da zamenjava ni povzročala težav, vendar to ni zamenjava, ki povečuje zmogljivost - to je vgrajeni mehanizem Android lowmemorykiller , ki bodo redno ubijali napihnjene visoko prioritetne procese, ki se ne uporabljajo. LMK je bil zasnovan posebej za obdelavo pogojev s pomanjkanjem pomnilnika, se prikliče iz kswapd proces in na splošno ubije procese v uporabniškem prostoru. To se razlikuje od OOMkiller (morilec brez pomnilnika), ampak to je povsem druga tema.
Bistvo je, da naprava z na primer 1 GB RAM-a nikoli ne more doseči potrebnih podatkov o zmogljivosti v zamenjavi, zato zamenjava v Androidu absolutno ni potrebna. Njegova izvedba je preprosto preobremenjena in vodi do degradacija v zmogljivosti, namesto da bi jo optimizirali.
zRAM - zastarel in ni več učinkovit
zRAM je preizkušena in učinkovita metoda za optimizacijo naprav za starejše naprave - pomislite na naprave, ki temeljijo na KitKat in delujejo na le približno 512 MB RAM-a. Dejstvo, da nekateri še vedno vključujejo optimizacijo zRAM v optimizacijske skripte ali pa priporočajo zRAM kot nekakšno sodobno optimizacijsko nastavitev, je primer, da ljudje na splošno ne upoštevajo najnovejših operativnih protokolov.
zRAM je bil namenjen vstopnim večjedrnim procesorjem s proračunom, kot so naprave, ki uporabljajo nabore čipov MTK in 512 MB RAM-a. V bistvu zelo poceni kitajski telefoni. ZRAM v bistvu loči jedro prek šifrirnega toka.
Ko se zRAM uporablja v starejših napravah z eno jedro , tudi če je na takih napravah priporočljiv zRAM, se navadno pojavijo velike količine zaostankov. To se zgodi tudi s tehnologijo KSM ( Združevanje iste strani jedra) ki združuje enake pomnilniške strani v želji po sprostitvi prostora. Google to v resnici priporoča, vendar vodi do večjih zaostankov pri starejših napravah, ker nenehno aktivno jedro theads neprekinjeno teče iz pomnilnika in išče podvojene strani. V bistvu poskus, da zaženete potek optimizacije, še bolj upočasni napravo, ironično.
Seeder - Zastarelo od Androida 3.0
Eden najbolj razpravljanih nasvetov za optimizacijo med razvijalci Android je cedra , in prepričani smo, da bi lahko nekdo poskusil dokazati, da se pri tej temi motimo - toda najprej moramo preučiti zgodovino sejalnice.
Aplikacija Seeder za Android
Da, obstaja veliko poročil, ki navajajo boljše delovanje Androida po namestitvi v veliko starejše naprave Android . Vendar ljudje iz kakršnega koli razloga verjamejo, da to pomeni, da je to tudi primerna optimizacija sodobne naprave Android , kar je popolnoma absurdno. Dejstvo, da Seeder še vedno ohranjajo in ponujajo kot „ moderno ' orodje za zmanjšanje zaostanka je primer napačnih informacij - čeprav za to ni kriv razvijalec Seederja, saj celo njihova stran Play Store ugotavlja, da je Seeder manj učinkovit po Androidu 4.0+. Vendar se Seeder iz kakršnega koli razloga še vedno pojavlja v razpravah o optimizaciji sodobnih sistemov Android.
Kaj Seeder v bistvu počne za Android 3.0, je odpraviti napako, pri kateri bi izvajalno okolje Android aktivno uporabljalo datoteko / dev / random / za pridobivanje entropije. Medpomnilnik / dev / random / bi postal nestabilen in sistem bi bil blokiran, dokler ne bi napolnil zahtevane količine podatkov - pomislite na malenkosti, kot so različni senzorji in gumbi na napravi Android.
Avtor Seederja je vzel Linux-demon rngd in sestavljen za nedelujoč sistem Android, tako da je naključne podatke vzel s precej hitrejše in bolj predvidljive poti / razvoj / urandom in jih vsako sekundo združil v razvoj / naključno /, ne da bi se / dev / random / izčrpal. Rezultat tega je bil sistem Android, ki ni imel pomanjkanja entropije in je deloval veliko bolj gladko.
Google je to napako razbil po Androidu 3.0, vendar se iz nekega razloga še vedno pojavlja Seeder 'Priporočeni popravki' seznami za optimizacijo delovanja Androida. Poleg tega ima aplikacija Seeder nekaj analogov, kot je sEFix, ki vključujejo funkcionalnost Seederja, ne glede na to, ali uporabljajo iste rngd ali druga možnost prekleti , ali celo samo simbolična povezava med / dev / urandom in / dev / random. To je za sodobne sisteme Android popolnoma nesmiselno.
Razlog za to je nesmiseln, ker novejše različice Androida uporabljajo / dev / random / v treh glavnih komponentah - libcrypto , za šifriranje SSL povezav, generiranje SSH ključev itd. WPA_supplication / hostapd, ki generira ključe WEP / WPA, in na koncu peščica knjižnic za generiranje ID pri ustvarjanju datotečnih sistemov EXT2 / EXT3 / EXT4.
Kdaj torej Sejalnik ali izboljšave na osnovi Seeder so vključene v sodobne optimizacijske skripte za Android, kar se na koncu zgodi degradacija v zmogljivosti naprave, ker rngd bo nenehno prebujal napravo in povzročal povečanje frekvence CPU, kar seveda negativno vpliva na porabo baterije.
Odex
Vdelana programska oprema na napravah Android je skoraj vedno odex. To pomeni, da sta poleg standardnega paketa za aplikacije za Android v obliki APK, ki ju najdete v / system / app / in / system / priv-app /, enaka imena datotek s pripono .odex. Datoteke odex vsebujejo optimizirane aplikacije bajt kod, ki so že prešle skozi navidezni stroj validatorja in optimizatorja, nato pa jih zabeležijo v ločeno datoteko z uporabo nekaj takega dexopt orodje.
Datoteke odex naj bi torej razložile navidezni stroj in ponudile hiter zagon aplikacije odexed - na spodnji strani datoteke ODEX preprečujejo spremembe vdelane programske opreme in povzročajo težave s posodobitvami, zato se zaradi tega distribuira veliko ROM-ov po meri, kot je LineageOS. brez ODEX-a .
Ustvarjanje datotek ODEX poteka na več načinov, na primer z uporabo orodja Odexer - težava je v tem, da gre zgolj za učinek placeba. Ko sodobni sistem Android ne najde datotek odex v imeniku / system, jih bo sistem dejansko ustvaril in postavil v imenik / system / dalvik-cache /. Prav to se dogaja, ko na primer utripate novo različico Androida in ta nekaj časa prikaže sporočilo »Zaseden, optimiziranje aplikacij«.
Popravki nizkega pomnilnika
Večopravilnost v Androidu se razlikuje od drugih mobilnih operacijskih sistemov v tem smislu, da temelji na klasičnem modelu, kjer aplikacije delujejo tiho v ozadju in ni omejitev glede števila aplikacij v ozadju ( razen če je ena nastavljena v možnostih za razvijalce, vendar je to na splošno priporočljivo) - poleg tega funkcionalnost prehoda na izvajanje v ozadju ni ustavljena, čeprav si sistem pridržuje pravico do uničenja aplikacij v ozadju v primeru pomanjkanja pomnilnika ( oglejte si, kje smo že v tem vodniku govorili o lowmemorykillerju in morilcu brez pomnilnika) .
Če se želite vrniti na lowmemorykiller mehanizem lahko Android še naprej deluje z omejeno količino pomnilnika in pomanjkanjem swap particije. Uporabnik lahko še naprej zažene programe in preklaplja med njimi, sistem pa bo tiho ubijal neuporabljene aplikacije v ozadju, da bi sprostil pomnilnik za aktivna opravila.
To je bilo zelo koristno za Android v zgodnjih dneh, čeprav je iz nekega razloga postalo priljubljeno v obliki aplikacij za ubijanje opravil, ki so na splošno bolj škodljive kot koristne. Aplikacije, ki ubijajo naloge, se prebudijo v določenih intervalih ali pa jih uporabnik zažene in sprostijo veliko RAM-a, kar je pozitivno - več prostega RAM-a pomeni hitrejšo napravo, kajne? Vendar to pri Androidu ni ravno tako.
Dejstvo je, da ima veliko prostega RAM-a dejansko škodljivo za delovanje naprave in življenjsko dobo baterije. Ko so aplikacije shranjene v Androidovem RAM-u, jih je veliko lažje poklicati, zagnati itd. Sistemu Android ni treba nameniti veliko sredstev za preklop na aplikacijo, ker je ta že v pomnilniku.
Zaradi tega morilci opravil v resnici niso tako priljubljeni kot nekoč, čeprav se začetniki Androida iz neznanega razloga še vedno zanašajo nanje ( pomanjkanje informacij, na žalost) . Na žalost je nov trend nadomestil morilce nalog, trend lowmemorykiller uglasitve mehanizmov. To bi bilo na primer MinFreeManager glavna ideja je povečati porabo RAM-a, preden sistem začne ubijati aplikacije v ozadju.
Tako na primer standardni RAM deluje na mejah - 4, 8, 12, 24, 32 in 40 Mb, in ko je zasedenega 40 MB prostega prostora za shranjevanje, ena od predpomnjenih aplikacij, ki se naloži v pomnilnik vendar ne teče bo ukinjena.
V bistvu bo torej Android vedno imel vsaj 40 MB razpoložljivega pomnilnika, kar je dovolj za namestitev še ene aplikacije prej lowmemorykiller začne postopek čiščenja - kar pomeni, da se bo Android vedno potrudil, da bo uporabil največjo količino razpoložljivega RAM-a, ne da bi pri tem posegal v uporabniško izkušnjo.
Na žalost je nekaj, kar so začeli ljubitelji domačih pivcev, priporočiti, da se vrednost dvigne na primer 100 MB, preden začne LMK. Zdaj bo uporabnik dejansko izgubiti RAM (100 - 40 = 60), zato bo sistem namesto, da bi uporabil ta prostor za shranjevanje zalednih aplikacij, obdržal to količino pomnilnika prost , brez povsem nobenega namena.
Uglaševanje LKM lahko koristno za veliko starejše naprave s 512 RAM-a, a kdo jih ima v lasti več? 2 GB je sodoben 'proračunski obseg', tudi naprave s 4 GB RAM-a danes izgledajo kot 'srednjega razreda', zato so popravki LMK res zastareli in neuporabni.
Popravki V / I
V veliko optimizacijskih skriptih za Android pogosto najdete popravke, ki obravnavajo V / I podsistem. Oglejmo si na primer ThunderBolt! Skripta, ki vsebuje te vrstice:
echo 0> $ i / čakalna vrsta / rotacija; echo 1024> $ i / queue / nr_requests;
Prva vrstica bo I / O načrtovalniku dala navodila za ravnanje s SSD-jem, druga pa poveča največjo velikost I / O čakalne vrste s 128 na 1024 - ker spremenljivka $ i vsebuje pot do drevesa blokovnih naprav v / sys, skript pa se izvaja v zanki.
Po tem najdete vrstico, povezano z razporejevalnikom CFQ:
echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle;
Temu sledi še več vrstic, ki pripadajo drugim načrtovalcem, vendar sta na koncu prva dva ukaza nesmiselna, ker:
Sodobno jedro Linuxa lahko razume, s katero vrsto nosilca podatkov privzeto deluje.
Dolga čakalno-vhodna vrsta ( na primer 1024) je v sodobni napravi Android neuporaben, pravzaprav nesmiseln tudi na namizju - v resnici je priporočljiv le za težki strežniki . Vaš telefon ni zahteven Linux strežnik.
Za napravo Android tako rekoč ni aplikacij, ki imajo prednost pri vhodno-izhodnih podatkih, in nobenega mehanskega gonilnika, zato je najboljši načrtovalec čakalna vrsta noop / FIFO, zato je ta vrsta načrtovalnika ' poteg ' ne dela ničesar posebnega ali pomembnega za V / I podsistem. Pravzaprav je vse te ukaze za seznam na več zaslonih bolje nadomestiti s preprostim ciklom:
za i in / sys / block / mmc *; do echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats done
To bi omogočilo načrtovalnik noop za vse pogone iz kopičenja I / O statistik, kar bi moralo pozitivno vplivati na zmogljivost, čeprav zelo majhno in skoraj povsem zanemarljivo.
Druga neuporabna prilagoditev V / I, ki jo pogosto najdemo v skriptih za delovanje, so povečane vrednosti branja naprej za kartice SD do 2 MB. Mehanizem branja naprej je namenjen zgodnjemu branju podatkov iz medijev, preden aplikacija zahteva dostop do teh podatkov. Torej v bistvu jedro poskuša ugotoviti, kateri podatki bodo potrebni v prihodnosti, in jih prednaloži v RAM, kar naj bi tako zmanjšalo čas vračila. Na papirju se to sliši odlično, pogosteje pa je algoritem za branje naprej narobe , kar vodi v popolnoma nepotrebne operacije vhodno-izhodnih podatkov, da ne omenjam velike porabe RAM-a.
V RAID-nizih se priporočajo visoke vrednosti za branje med 1 in 8 MB, za naprave Android pa je najbolje, da pustite privzeto vrednost 128 KB.
Popravki sistema za upravljanje navideznega pomnilnika
Druga pogosta tehnika 'optimizacije' je uglasitev podsistema za upravljanje navideznega pomnilnika. To ponavadi cilja samo na dve spremenljivki jedra, vm.dirty_background_ratio in vm.dirty_ratio, ki sta namenjeni prilagajanju velikosti vmesnega pomnilnika za shranjevanje 'umazanih' podatkov. Umazano podatki so običajno podatki, ki so bili zapisani na disk, vendar jih je še več v pomnilniku in čakajo na zapis na disk.
Tipične vrednosti prilagajanja v Linuxovih distribucijah in Androisu za podsistem za upravljanje VM bi bile take:
vm.dirty_background_ratio = 10 vm.dirty_ratio_ratio = 20
Torej to skuša narediti, da se umazani umazani podatki zberejo 10% celotne količine RAM-a, da se prebudi pdflush tok in začne zapisovati podatke na disk - če bo postopek snemanja podatkov na disk preveč intenzivno , medpomnilnik bo še naprej rasel in ko bo dosegel 20% razpoložljivega RAM-a, bo sistem prešel na nadaljnjo operacijo pisanja v sinhronem načinu - brez predhodnega vmesnega pomnilnika. To pomeni, da bo delo zapisovanja na disk blokirano, dokler se podatki ne zapišejo na disk (AKA 'zaostanek').
Morali bi razumeti, da tudi če je velikost medpomnilnika ne doseže 10% , sistem bo samodejno sprožil pdflush po 30 sekundah. Kombinacija 10/20 je precej smiselna, na primer na napravi z 1 GB RAM-a bi to ustrezalo 100/200 MB RAM-a, kar je več kot dovolj v smislu zaporednih zapisov, kjer je hitrost pogosto pod zapisom hitrosti v sistemu NAND -pomnilnik ali SD-kartica, na primer pri nameščanju aplikacij ali kopiranju datotek iz računalnika.
Iz nekega razloga skušajo pisci scenarijev to vrednost dvigniti še višje, do absurdnih stopenj. Na primer lahko najdemo v Xplix optimizacijski skript s stopnjo do 50/90.
sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90
V napravi z 1 GB pomnilnika ta omejitev umazanega medpomnilnika nastavi na 500/900 MB, kar je za napravo Android popolnoma neuporabno, ker bi delovalo le pod nenehno snemanje na disk - nekaj, kar se zgodi samo na težkem Linux strežniku.
ThunderBolt! Skript uporablja bolj razumno vrednost, vendar je na splošno še vedno dokaj nesmiseln:
če ['$ mem' -lt 524288]; potem sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; nato sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; sicer sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;
Prva dva ukaza se izvajata v pametnih telefonih s 512 MB RAM-a, drugi - z 1 GB in drugi - z več kot 1 GB. Toda v resnici obstaja samo en razlog za spremembo privzetih nastavitev - naprava z zelo počasnim notranjim pomnilnikom ali pomnilniško kartico. V tem primeru je smiselno razširiti vrednosti spremenljivk, to je narediti nekaj takega:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Potem, ko sistem prenapetosti zapisuje operacije, ne da bi bilo treba snemati podatke na disk, do zadnjega ne bo preklopil v sinhroni način, kar bo aplikacijam omogočilo zmanjšanje zaostajanja pri snemanju.
Dodatni neuporabni popravki in nastavitve zmogljivosti
Obstaja veliko več 'optimizacij', ki v resnici ne naredijo ničesar. Večina jih preprosto nima nobenega učinka, druge pa se lahko izboljšajo nekaj z vidika zmogljivosti, medtem ko napravo poslabša na druge načine ( ponavadi se to zmanjša na zmogljivost v primerjavi s prazno baterijo) .
Tu je nekaj dodatnih priljubljenih optimizacij, ki so lahko ali pa ne bodo koristne, odvisno od sistema Android in naprave.
- Pospešek - majhen pospešek za izboljšanje zmogljivosti in podnapetost - prihrani malo baterije.
- Optimizacija zbirke podatkov - v teoriji to bi morali izboljšajo delovanje naprave, vendar je dvomljivo.
- Zipalign - Ironično je, da kljub vgrajeni funkciji Android SDK poravnava vsebine znotraj datoteke APK v trgovini lahko ugotovite, da se veliko programske opreme ne prenaša prek zipalign.
- Onemogočite nepotrebne sistemske storitve, odstranite neuporabljene sistemske in redko uporabljene programe drugih proizvajalcev. V bistvu odstranjevanje bloatware-a.
- Jedro po meri z optimizacijami za določeno napravo (spet niso vsa jedra enako dobra).
- Že opisan I / O načrtovalnik noop.
- Algoritem nasičenja TCP Westwood - Učinkoviteje se uporablja v privzetem Androidu Cubic za brezžična omrežja, na voljo v jedrih po meri.
Nekoristne nastavitve build.prop
LaraCraft304 s foruma XDA Developers je izvedel študijo in ugotovil, da v izvornih AOSP in CyanogenMod ne obstaja impresivno število nastavitev /system/build.prop, ki so priporočljive za uporabo 'strokovnjakov'. Tu je seznam:
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. 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.sAP.UTPOznake android Razvoj 12 minut branja
