Per tant, molts scripts d'optimització tot en un utilitzen els mateixos mètodes, alguns dels quals són completament obsolets o nocius a la llarga. En resum, la majoria dels scripts d’optimització “tot-en-un” no són res més que afinacions recomanades combinades, sense tenir una idea clara de com o per què funcionen aquestes optimitzacions: els usuaris fan flash dels scripts i afirmen que el seu rendiment és de cop més ràpid ( quan, de fet, és molt probable que el simple fet de reiniciar el dispositiu hagi provocat un augment del rendiment , ja que es neteja tot el contingut de la memòria RAM del dispositiu) .
En aquest article exclusiu d'Appuals, destacarem algunes de les recomanacions més habituals per a ' optimitzant ” El rendiment d'Android i si són simplement un mite o un ajust legítim per al rendiment del dispositiu.
Intercanvi
Al capdamunt de la llista de mites hi ha l'intercanvi d'Android, que és bastant absurd en termes de ser considerat com una optimització d'Android. El propòsit principal de Swaps és crear i connectar el fitxer de paginació, que alliberarà espai d'emmagatzematge a la memòria. Sona sensat sobre paper , però és realment aplicable a servidor , que gairebé no té interactivitat.
Quan utilitzeu l’intercanvi del vostre telèfon Android amb regularitat, es produiran retards greus derivats de les coses que passen per la memòria cau. Imagineu-vos, per exemple, si una aplicació intenta mostrar un gràfic que s’emmagatzema a l’intercanvi, que ara ha de tornar a carregar el disc després d’alliberar espai col·locant l'intercanvi de dades amb una altra aplicació. És realment desordenat.
Alguns entusiastes de l’optimització poden dir que l’intercanvi no oferia problemes, però no és un intercanvi que augmenta el rendiment: és el mecanisme integrat d’Android. lowmemorykiller , que matarà regularment processos inflats i d’alta prioritat que no s’utilitzen. LMK ha estat dissenyat específicament per gestionar condicions de poca memòria, s'invoca des de kswapd i generalment mata els processos d’espai d’usuari. Això és diferent de OOMkiller (assassí sense memòria), però aquest és un tema completament diferent.
La qüestió és que un dispositiu amb, per exemple, 1 GB de memòria RAM mai no pot assolir les dades de rendiment necessàries en un swap, per la qual cosa el swap no és absolutament necessari a Android. La seva implementació és simplement plena de retard i condueix a un degradació en rendiment, en lloc d’optimitzar-lo.
zRAM: obsolet i ja no és eficient
zRAM és un mètode provat i eficaç per a l'optimització de dispositius, per a dispositius antics - Penseu en dispositius basats en KitKat que només funcionen amb uns 512 MB de RAM. El fet que algunes persones encara incloguin modificacions de zRAM en scripts d'optimització, o recomanin zRAM com a algun tipus de modificació d'optimització moderna, és un exemple de persones que generalment no segueixen els protocols operatius més recents.
zRAM estava pensat per a SoC multi-core de rang pressupostari d’entrada, com ara dispositius que utilitzen chipsets MTK i 512 MB de RAM. Telèfons xinesos molt econòmics, bàsicament. El que bàsicament fa zRAM és separar el nucli mitjançant el flux de xifratge.
Quan s’utilitza zRAM en dispositius antics amb un fitxer nucli únic , fins i tot si es recomana zRAM en aquests dispositius, solen aparèixer grans quantitats de retards. Això també passa amb la tecnologia KSM ( Fusió de la mateixa pàgina del nucli) que combina pàgines de memòria idèntiques en una aposta per alliberar espai. De fet, això ho recomana Google, però comporta retards majors en dispositius antics, ja que els nuclis actius constantment s'executen des de la memòria per buscar pàgines duplicades. Bàsicament, intentar executar l'opció d'optimització alenteix el dispositiu encara més, irònicament.
Sembradora: obsoleta des d'Android 3.0
Un dels consells d'optimització més debatuts entre els desenvolupadors d'Android és cedre , i estem segurs que algú pot intentar demostrar-nos que estem equivocats en aquest tema, però primer hem d’examinar la història de la sembra.
Aplicació Sembradora per a Android
Sí, hi ha un gran nombre d'informes que declaren un millor rendiment d'Android després de la instal·lació dispositius Android molt més antics . Tanmateix, per qualsevol motiu, la gent creu que això significa que també és una optimització aplicable per a dispositius Android moderns , cosa absolutament absurda. El fet que Seeder encara es mantingui i s’ofereixi com a “ modern ” l'eina de reducció del retard és un exemple de desinformació, tot i que no és culpa del desenvolupador de Seeder, ja que fins i tot a la seva pàgina de Play Store es nota que Seeder és menys eficaç després d'Android 4.0+. Tot i això, per qualsevol motiu, Seeder encara apareix en discussions d’optimització per als sistemes Android moderns.
El que fa bàsicament Seeder per a Android 3.0 és solucionar un error en què el temps d'execució d'Android utilitzaria activament el fitxer / dev / random / per adquirir l'entropia. El / dev / random / buffer es tornaria inestable i el sistema es bloquejaria fins que omplís la quantitat necessària de dades; penseu en coses petites com els diversos sensors i botons del dispositiu Android.
L’autor de Seeder es va endur el dimoni Linux rngd , i compilat per a l'astroil d'Android, de manera que prenia dades aleatòries d'una via / dev / urandom molt més ràpida i previsible i les fusiona en dev / random / cada segon, sense permetre que / dev / random / s'esgoti. Això va donar lloc a un sistema Android que no experimentava la manca d’entropia i que funcionava molt més fàcilment.
Google va destrossar aquest error després d'Android 3.0, però per alguna raó, Seeder encara apareix 'Ajustaments recomanats' llistes per a l'optimització del rendiment d'Android. A més, l’aplicació Seeder té uns quants anàlegs com sEFix que inclouen la funcionalitat de Seeder, tant si s’utilitza el mateix rngd o l’alternativa haveged , o fins i tot només un enllaç simbòlic entre / dev / urandom i / dev / random. Això és absolutament inútil per als sistemes Android moderns.
El motiu és inútil perquè les versions més recents d'Android utilitzen / dev / random / en tres components principals: libcrypto , per xifrar connexions SSL, generar claus SSH, etc. WPA_supplication / hostapd que genera claus WEP / WPA i, finalment, un grapat de biblioteques per generar ID en la creació de sistemes de fitxers EXT2 / EXT3 / EXT4.
Doncs quan Sembradora o les millores basades en Seeder s’inclouen als scripts moderns d’optimització d’Android, el que acaba passant és un degradació en el rendiment del dispositiu, perquè rngd despertarà constantment el dispositiu i provocarà un augment de la freqüència de la CPU, cosa que, per descomptat, afecta negativament el consum de la bateria.
Odex
El firmware existent en dispositius Android gairebé sempre és odex. Això significa que, juntament amb el paquet estàndard per a aplicacions d'Android en format APK, que es troba a / system / app / i / system / priv-app /, tenen els mateixos noms de fitxer amb l'extensió .odex. Els fitxers odex contenen aplicacions de bytecode optimitzades que ja han passat per la màquina virtual del validador i l’optimitzador, i que després s’han enregistrat en un fitxer separat utilitzant alguna cosa com desoptar eina.
Per tant, els fitxers odex estan destinats a descarregar la màquina virtual i ofereixen un llançament accelerat de l’aplicació odexed; a la part negativa, els fitxers ODEX impedeixen modificacions al firmware i creen problemes amb les actualitzacions, de manera que per aquest motiu es distribueixen moltes ROM personalitzades com LineageOS sense ODEX .
La generació de fitxers ODEX es realitza de diverses maneres, com fer servir Eina Odexer: el problema és que és purament un efecte placebo. Quan el sistema Android modern no troba fitxers odex al directori / system, el sistema els crearà i els col·locarà al directori / system / dalvik-cache /. Això és exactament el que passa quan, per exemple, llança una nova versió d'Android i apareix el missatge 'Aplicacions ocupades i optimitzants' durant un temps.
Retocs de lowmemorykiller
La multitarea a Android es diferencia d'altres sistemes operatius mòbils en el sentit que es basa en un model clàssic en què les aplicacions funcionen tranquil·lament en segon pla i no hi ha restriccions en el nombre d'aplicacions en segon pla ( tret que estigui establert a Opcions per a desenvolupadors, però generalment es recomana evitar-ho) - a més, la funcionalitat de transició a una execució en segon pla no s'atura, tot i que el sistema es reserva el dret de matar les aplicacions en segon pla en situacions de poca memòria ( vegeu on parlàvem de lowmemorykiller i assassí sense memòria anteriorment en aquesta guia) .
Per tornar al lowmemorykiller Android pot continuar funcionant amb una quantitat limitada de memòria i amb una manca de partició d'intercanvi. L'usuari pot continuar llançant aplicacions i canviant-les, i el sistema eliminarà silenciosament les aplicacions de fons no utilitzades per intentar alliberar memòria per a tasques actives.
Això va ser molt útil per a Android als primers dies, tot i que, per alguna raó, es va popularitzar en forma d'aplicacions per combatre les tasques, que generalment són més perjudicials que beneficioses. Les aplicacions d'assassinat de tasques es desperten a intervals definits o són executades per l'usuari i semblen alliberar grans quantitats de RAM, cosa que es veu positiva: més RAM lliure significa un dispositiu més ràpid, oi? No obstant això, no és exactament el cas d'Android.
De fet, tenir una gran quantitat de memòria RAM lliure pot ser perjudicial per al rendiment i la durada de la bateria del dispositiu. Quan les aplicacions s’emmagatzemen a la memòria RAM d’Android, és molt més fàcil cridar-les, iniciar-les, etc. El sistema Android no necessita dedicar molts recursos a canviar a l’aplicació, perquè ja hi ha a la memòria.
Per això, els assassins de tasques no són realment tan populars com abans, tot i que els principiants d’Android encara tendeixen a confiar-hi per alguna raó ( falta d’informació, per desgràcia) . Malauradament, una nova tendència ha substituït els assassins de tasques, la tendència de lowmemorykiller afinacions de mecanismes. Això seria per exemple MinFreeManager i la idea principal és augmentar la sobrecàrrega de la memòria RAM abans que el sistema comenci a eliminar aplicacions en segon pla.
Per exemple, la memòria RAM estàndard funciona a les fronteres: 4, 8, 12, 24, 32 i 40 Mb, i quan s’omple l’espai d’emmagatzematge lliure de 40 MB, una de les aplicacions emmagatzemades a la memòria cau però no corrent finalitzarà.
Així, bàsicament, Android sempre tindrà com a mínim 40 MB de memòria disponible, suficient per allotjar una aplicació més abans lowmemorykiller inicia el seu procés de neteja, cosa que significa que Android sempre farà tot el possible per utilitzar la quantitat màxima de RAM disponible sense interferir en l'experiència de l'usuari.
Malauradament, el que alguns entusiastes de la preparació de la producció casolana van recomanar és que el valor s’elevés a, per exemple, a 100 MB abans que comencés LMK. Ara l’usuari realment perdre RAM (100 - 40 = 60), de manera que, en lloc d’utilitzar aquest espai per emmagatzemar aplicacions de fons, el sistema conservarà aquesta quantitat de memòria gratuït , sense cap propòsit.
Afinació LKM pot ser útil per a dispositius molt antics amb 512 RAM, però qui en té més? Els 2 GB són el modern 'rang pressupostari', fins i tot els dispositius de memòria RAM de 4 GB els veuen 'de gamma mitjana' actualment, de manera que els ajustaments de LMK són realment obsolets i inútils.
Ajustaments d'E / S
En molts scripts d’optimització per a Android, sovint trobareu modificacions que s’adrecen al subsistema d’E / S. Per exemple, fem una ullada al fitxer Llamp! Script, que conté aquestes línies:
eco 0> $ i / queue / rotational; echo 1024> $ i / queue / nr_requests;
La primera línia donarà instruccions al planificador d'E / S per tractar un SSD i la segona augmenta la mida màxima de la E / S de la cua de 128 a 1024, perquè la variable $ i conté un camí d'accés a l'arbre de dispositius de bloc a / sys, i l'script s'executa en bucle.
A continuació, trobareu una línia relacionada amb el planificador CFQ:
echo 1> $ i / queue / iosched / back_seek_penalty; echo 1> $ i / queue / iosched / low_latency; echo 1> $ i / queue / iosched / slice_idle;
A continuació, hi ha més línies que pertanyen a altres planificadors, però en última instància, les dues primeres ordres no tenen sentit perquè:
Un nucli Linux modern és capaç d’entendre amb quin tipus de suport d’emmagatzematge treballa per defecte.
Una llarga cua d’entrada-sortida ( com ara 1024) no serveix per a res en un dispositiu Android modern, de fet no té sentit fins i tot a l’escriptori; només es recomana a servidors pesats . El vostre telèfon no és un servidor Linux resistent.
Per a un dispositiu Android, pràcticament no hi ha aplicacions prioritzades a l'entrada-sortida ni cap controlador mecànic, de manera que el millor planificador és la cua noop / FIFO, de manera que aquest tipus de planificador ' retocar ” no fa res especial ni significatiu per al subsistema d'E / S. De fet, totes aquestes ordres de llista de múltiples pantalles se substitueixen millor per un simple cicle:
per a i in / sys / block / mmc *; do echo noop> $ i / queue / scheduler echo 0> $ i / queue / iostats fet
Això permetria el programador noop per a totes les unitats a partir de l'acumulació d'estadístiques d'E / S, que haurien de tenir un impacte positiu en el rendiment, encara que molt petit i gairebé totalment insignificant.
Un altre ajust inútil d'E / S que es troba sovint als scripts de rendiment és l'augment dels valors de lectura anticipada per a targetes SD de fins a 2 MB. El mecanisme de lectura anticipada és per a les primeres lectures de dades dels mitjans de comunicació, abans que l'aplicació sol·liciti accés a aquestes dades. Per tant, bàsicament, el nucli intentarà esbrinar quines dades es necessitaran en el futur i les pre-carregaran a la memòria RAM, cosa que hauria de reduir el temps de retorn. Sona molt bé al paper, però l’algoritme de lectura anticipada és més freqüent mal , que condueix a operacions d'entrada-sortida totalment innecessàries, sense oblidar un alt consum de RAM.
Es recomanen valors elevats de lectura anticipada d'entre 1 i 8 MB a les matrius RAID, però per als dispositius Android és millor deixar el valor per defecte de 128 KB.
Retocs del sistema de gestió de memòria virtual
Una altra tècnica habitual d’optimització és la posada a punt del subsistema de gestió de memòria virtual. Normalment, només s'orienta a dues variables del nucli, vm.dirty_background_ratio i vm.dirty_ratio, que serveixen per ajustar la mida del buffer per emmagatzemar dades 'brutes'. Brut les dades solen ser dades que s’han escrit al disc, però encara hi ha més a la memòria i a l’espera de ser escrites al disc.
Els valors típics de modificació tant en distribucions de Linux com en Androis al subsistema de gestió de màquines virtuals serien com:
vm.dirty_background_ratio = 10 vm.dirty_ratio = 20
Per tant, el que intenta fer és que quan el buffer de dades brutes és el 10% de la quantitat total de RAM, es desperti pdflush flueix i comença a escriure dades al disc, si serà l'operació de gravació de dades al disc massa intens , la memòria intermèdia continuarà creixent i, quan arribi al 20% de la memòria RAM disponible, el sistema canviarà a l'operació d'escriptura posterior en mode síncron - sense pre-memòria intermèdia. Això significa que el treball d'escriptura a l'aplicació de disc serà bloquejat, fins que les dades s’escriuen al disc (AKA ‘lag’).
El que hauríeu d’entendre és que fins i tot si la mida del buffer no arriba al 10% , el sistema s'iniciarà automàticament en pdflush després de 30 segons. Una combinació de 10/20 és bastant raonable, per exemple, en un dispositiu amb 1 GB de RAM, això equival a 100/200 MB de RAM, que és més que suficient en termes de registres de ràfegues on la velocitat sol estar per sota del registre de velocitat del sistema NAND -memory o targeta SD, com ara quan instal·leu aplicacions o copieu fitxers des d’un ordinador.
Per alguna raó, els guionistes intenten augmentar aquest valor encara més, fins a taxes absurdes. Per exemple, el podem trobar a Xplix script d'optimització una taxa tan alta com 50/90.
sysctl -w vm.dirty_background_ratio = 50 sysctl -w vm.dirty_ratio = 90
En un dispositiu amb 1 GB de memòria, estableix el límit d’un buffer brut a 500/900 MB, cosa totalment inútil per a un dispositiu Android, perquè només funcionaria a enregistrament constant al disc - cosa que només passa en un servidor Linux pesat.
Llamp! L’escriptura utilitza un valor més raonable, però, en general, encara no té cap sentit:
if ['$ mem' -lt 524288]; llavors sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ['$ mem' -lt 1049776]; llavors 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;
Les dues primeres ordres s’executen en telèfons intel·ligents amb 512 MB de RAM, la segona (amb 1 GB i altres) amb més d’1 GB. Però, de fet, només hi ha una raó per canviar la configuració predeterminada: un dispositiu amb una memòria interna o una targeta de memòria molt lentes. En aquest cas, és raonable estendre els valors de les variables, és a dir, fer alguna cosa així:
sysctl -w vm.dirty_background_ratio = 10 sysctl -w vm.dirty_ratio = 60
Aleshores, quan un sistema de sobretensió escriu operacions, sense haver de gravar dades al disc, fins a l'últim no canviarà al mode síncron, cosa que permetrà que les aplicacions redueixin el retard en gravar.
Retocs inútils addicionals i afinacions de rendiment
Hi ha moltes més 'optimitzacions' que realment no fan res. La majoria d’ells simplement no tenen cap mena d’efecte, mentre que d’altres poden millorar alguns aspecte del rendiment, tot degradant el dispositiu per altres formes ( generalment es redueix al rendiment en comparació amb l’esgotament de la bateria) .
A continuació, es mostren algunes optimitzacions populars addicionals que poden ser útils o no, segons el sistema i el dispositiu Android.
- Acceleració: la petita acceleració per millorar el rendiment i la baixa tensió permet estalviar una mica de bateria.
- Optimització de bases de dades: en teoria això hauria donen una millora en el rendiment del dispositiu, però és dubtós.
- Zipalign: Irònicament, tot i l’alineació de contingut de la funció SDK d’Android integrada a l’arxiu APK de la botiga, podeu trobar que molts programes no es transmeten mitjançant zipalign.
- Desactiveu els serveis del sistema innecessaris, suprimint el sistema no utilitzat i les aplicacions de tercers que poc s'utilitzen. Bàsicament, desinstal·lant bloatware.
- Nucli personalitzat amb optimitzacions per a un dispositiu específic (de nou, no tots els nuclis són igual de bons).
- Ja s'ha descrit el planificador d'E / S noop.
- Algorisme de saturació TCP Westwood: s'utilitza de manera més eficient a l'Android Cubic per defecte per a xarxes sense fils, disponible en nuclis personalitzats.
Configuració inútil build.prop
LaraCraft304 del fòrum XDA Developers ha dut a terme un estudi i ha trobat que no existeixen un nombre impressionant de paràmetres /system/build.prop que es recomana per a utilitzar 'experts' a la font AOSP i CyanogenMod. Aquí teniu la llista:
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.ADSEtiquetes android Desenvolupament 12 minuts de lectura
