Los mitos más comunes sobre la optimización de los androides desacreditados

Hay muchas guías de instrucción por ahí dedicadas a aumentar el rendimiento de Android, y consejos de optimización general. Algunas de ellas son legítimas, y otras se basan sólo en la teoría, o métodos operativos anticuados en el sistema Androide, o son simplemente tonterías. Esto incluye recomendaciones para intercambiar, valores añadidos a build.prop, y cambios variables en el kernel de Linux.

Hay incluso una tonelada de «scripts de optimización» por ahí, cremalleras flash todo en uno que prometen aumentar significativamente el rendimiento, la duración de la batería y otras cosas. Algunos de los ajustes pueden funcionar, pero la mayoría son simplemente un efecto placebo, o peor aún, tienen un impacto negativo en tu dispositivo.

Esto no quiere decir que la gente esté lanzando scripts nefastos intencionadamente – hay definitivamente aplicaciones falsas pagadas en la Play Store, pero los scripts de optimización lanzados en los foros de Android son generalmente bien intencionados, sólo sucede que el desarrollador puede estar mal informado, o simplemente experimentando con varios ajustes de optimización. Por desgracia, tiende a producirse una especie de efecto de bola de nieve, especialmente en los scripts de optimización «todo en uno». Un pequeño puñado de los ajustes puede hacer algo , mientras que otro conjunto de ajustes en un guión puede no hacer absolutamente nada – sin embargo, estos guiones se transmiten como si fueran balas mágicas, sin ninguna investigación real sobre lo que funciona y lo que no.

Por lo tanto, muchos de los guiones de optimización «todo en uno» están utilizando los mismos métodos, algunos de los cuales son completamente anticuados o perjudiciales a largo plazo. En resumen, la mayoría de los scripts de optimización «todo en uno» no son más que afinaciones recomendadas, sin una idea clara de cómo o por qué estas optimizaciones «funcionan – los usuarios entonces flashean los scripts, y afirman que su rendimiento es de repente más rápido ( cuando, de hecho, lo más probable es que el simple hecho de reiniciar su dispositivo haya causado un aumento de rendimiento , ya que todo en la RAM del dispositivo se limpia) .

En este artículo exclusivo de Appuals, destacaremos algunas de las recomendaciones más comunes para » optimizar» el rendimiento de los Androides, y si son simplemente un mito, o un ajuste legítimo para el rendimiento del dispositivo.

Intercambio

A la cabeza de la lista de mitos está el intercambio de Androides, que es bastante absurdo en términos de ser pensado como una optimización de Androides. El propósito principal del intercambio es crear y conectar el archivo de paginación, lo que liberará espacio de almacenamiento en la memoria. Esto suena sensato en el papel , pero es realmente aplicable a un servidor , que casi no tiene interactividad.

Cuando se utiliza el intercambio de su teléfono Android con regularidad, se producen graves retrasos que se deben a que las cosas se escapan de la memoria. Imagina, por ejemplo, si una aplicación intenta mostrar un gráfico, que está almacenado en el swap, que ahora tiene que volver a cargar el disco después de liberar espacio al colocar el intercambio de datos con otra aplicación. Es realmente desordenado.

Algunos entusiastas de la optimización pueden decir que el intercambio no ofrece ningún problema, pero no es un intercambio que haga aumentar el rendimiento, sino el mecanismo incorporado de Android lowmemorykiller , que regularmente matará los procesos hinchados y de alta prioridad que no se están utilizando. LMK fue diseñado específicamente para manejar condiciones de baja memoria, se invoca desde el proceso kswapd , y generalmente mata los procesos espaciales del usuario. Esto es diferente de OOMkiller (out-of-memory killer), pero es un tema totalmente distinto.

El punto es que un dispositivo con, por ejemplo, 1GB de RAM nunca puede alcanzar los datos de rendimiento necesarios en un intercambio, y por lo tanto el intercambio no es absolutamente necesario en Android. Su implementación está simplemente llena de retrasos y lleva a una degradación del rendimiento , en lugar de optimizarlo.

zRAM – Anticuado y ya no eficiente

zRAM es un método probado y efectivo para la optimización de dispositivos, para dispositivos más antiguos – piense en los dispositivos basados en KitKat que funcionan con sólo unos 512 MB de RAM. El hecho de que algunas personas todavía incluyan ajustes de zRAM en los scripts de optimización, o recomienden zRAM como algún tipo de ajuste de optimización moderno, es un ejemplo de que las personas generalmente no siguen los últimos protocolos operativos.

zRAM estaba destinado a SoCs multinúcleo de bajo presupuesto, como los dispositivos que utilizan chipsets MTK y 512 MB de RAM. Teléfonos chinos muy baratos, básicamente. Lo que zRAM hace básicamente es separar el núcleo a través del flujo de cifrado.

Cuando se utiliza zRAM en dispositivos más antiguos con un solo núcleo , aunque se recomiende zRAM en dichos dispositivos, tienden a aparecer grandes cantidades de retrasos. Esto también sucede con la tecnología KSM ( Fusión de la misma página del núcleo) que combina páginas de memoria idénticas en un intento de liberar espacio. De hecho, esto es lo que recomienda Google, pero lleva a mayores retrasos en los dispositivos más antiguos, ya que los núcleos constantemente activos se ejecutan continuamente desde la memoria para buscar páginas duplicadas. Básicamente, tratar de ejecutar el ajuste de optimización ralentiza aún más el dispositivo, irónicamente.

Sembrador – Desactualizado desde Android 3.0

Uno de los consejos de optimización más debatidos entre los desarrolladores de Android es seeder , y estamos seguros de que alguien podría tratar de demostrarnos que estamos equivocados en este tema – pero primero tenemos que examinar la historia de seeder.

Aplicación de semillas para Android

Sí, hay un gran número de informes que declaran un mejor rendimiento de Android después de la instalación en dispositivos Android mucho más antiguos . Sin embargo, la gente por cualquier razón cree que esto significa que también es una optimización aplicable para dispositivos Android modernos , lo cual es absolutamente absurdo. El hecho de que Seeder siga siendo mantenido y ofrecido como una herramienta de reducción de retraso » moderna» es un ejemplo de desinformación – aunque esto no es culpa del desarrollador de Seeder, ya que incluso su página de Play Store señala que Seeder es menos efectivo después de Android 4.0+. Sin embargo, por la razón que sea, Seeder sigue apareciendo en las discusiones de optimización para los sistemas Android modernos.

Lo que Seeder hace básicamente para Android 3.0 es abordar un error en el que el tiempo de ejecución de Android usaría activamente el archivo /dev/random/ para adquirir entropía. El buffer /dev/random/ se volvería inestable, y el sistema se bloquearía hasta que llenara la cantidad de datos requerida – piensa en pequeñas cosas como los varios sensores y botones del dispositivo Android.

El autor de Seeder tomó el demonio de Linux rngd , y lo compiló para el inastreil de Android de manera que tomó datos aleatorios de un camino mucho más rápido y más predecible /dev/urandom, y los fusiona en dev/random/ cada segundo, sin permitir que el /dev/random/ se agote. Esto dio como resultado un sistema Androide que no experimentó una falta de entropía, y funcionó mucho más suavemente.

Google eliminó este error después de Android 3.0, pero por alguna razón, Seeder sigue apareciendo en las listas de «ajustes recomendados» para la optimización del rendimiento de Android. Además, la aplicación Seeder tiene unos cuantos análogos como sEFix que incluyen la funcionalidad de Seeder, ya sea usando el mismo rngd o el alternativo haveged , o incluso sólo un enlace simbólico entre /dev/urandom y /dev/random. Esto es absolutamente inútil para los sistemas Androides modernos.

La razón por la que no tiene sentido es porque las nuevas versiones de Android utilizan /dev/random/ en tres componentes principales – libcrypto , para el cifrado de las conexiones SSL, la generación de claves SSH, etc. WPA_supplication/hostapd que genera claves WEP/WPA, y por último, un puñado de librerías para la generación de ID en la creación de sistemas de archivos EXT2/EXT3/EXT4.

Así que cuando Seeder o las mejoras basadas en Seeder se incluyen en los modernos scripts de optimización de Android, lo que acaba ocurriendo es una degradación en el rendimiento del dispositivo, porque rngd despertará constantemente al dispositivo y causará un aumento en la frecuencia de la CPU, lo que, por supuesto, afecta negativamente al consumo de la batería.

Odex

El firmware de los dispositivos Android casi siempre es odex. Esto significa que junto con el paquete estándar para aplicaciones Android en formato APK, que se encuentra en /system/app/ y /system/priv-app/, son de los mismos nombres de archivo con la extensión .odex. Los archivos odex contienen aplicaciones optimizadas de código de bytes que ya han pasado por la máquina virtual del validador y optimizador, y que luego se registran en un archivo separado utilizando algo como la herramienta dexopt .

Así que los archivos odex están pensados para descargar la máquina virtual y ofrecer una aceleración en el lanzamiento de la aplicación odexed – en el lado negativo, los archivos ODEX impiden las modificaciones del firmware, y crean problemas con las actualizaciones, así que por esta razón muchas ROMs personalizadas como LineageOS se distribuyen sin ODEX .

La generación de archivos ODEX se hace de varias maneras, como el uso de Odexer Tool – el problema es que es puramente un efecto placebo. Cuando el moderno sistema Android no encuentra archivos odex en el directorio /system, el sistema los crea y los coloca en el directorio /system/dalvik-cache/. Esto es exactamente lo que sucede cuando, por ejemplo, flasheas una nueva versión de Android y da el mensaje «Ocupado, optimizando aplicaciones» por un tiempo.

Ajustes de bajo nivel de memoria

La multitarea en Android difiere de otros sistemas operativos móviles en el sentido de que se basa en un modelo clásico en el que las aplicaciones funcionan silenciosamente en segundo plano, y no hay restricciones en el número de aplicaciones en segundo plano ( a menos que se establezca una en las Opciones del desarrollador, pero esto se recomienda generalmente contra) – además, la funcionalidad de transición a una ejecución en segundo plano no se detiene, aunque el sistema se reserva el derecho de matar aplicaciones en segundo plano en situaciones de baja memoria ( ver donde hemos hablado de lowmemorykiller y out-of-memory killer antes en esta guía) .

Para volver al mecanismo de baja memoria , Android puede seguir operando con una cantidad limitada de memoria y una falta de partición de intercambio. El usuario puede continuar lanzando aplicaciones y cambiando entre ellas, y el sistema matará silenciosamente las aplicaciones en segundo plano no utilizadas para intentar liberar memoria para las tareas activas.

Esto fue muy útil para Android en los primeros días, aunque por alguna razón se hizo popular en forma de aplicaciones para matar tareas, que generalmente son más dañinas que beneficiosas. Las aplicaciones de este tipo se despiertan a intervalos determinados o las ejecuta el usuario y parecen liberar grandes cantidades de memoria RAM, lo que se considera positivo: más memoria RAM libre significa un dispositivo más rápido, ¿verdad? Sin embargo, este no es exactamente el caso de Android.

De hecho, tener una gran cantidad de RAM libre puede ser perjudicial para el rendimiento del dispositivo y la duración de la batería. Cuando las aplicaciones se almacenan en la RAM de Android, es mucho más fácil llamarlas, lanzarlas, etc. El sistema Android no necesita dedicar muchos recursos para cambiar a la aplicación, porque ya está en la memoria.

Debido a esto, los asesinos de tareas no son realmente tan populares como lo fueron alguna vez, aunque los novatos de los Androides todavía tienden a confiar en ellos por alguna razón ( falta de información, tristemente) . Desafortunadamente, una nueva tendencia ha reemplazado a los mata-tareas, la tendencia de lowmemorykiller afinaciones de mecanismos. Esto sería por ejemplo MinFreeManager app, y la idea principal es aumentar la sobrecarga de la RAM antes de que el sistema empiece a matar las aplicaciones de fondo.

Así, por ejemplo, la RAM estándar opera en los límites – 4, 8, 12, 24, 32, y 40 Mb, y cuando se llena el espacio libre de almacenamiento de 40 MB, una de las aplicaciones en caché que está cargada en la memoria pero que no se está ejecutando será terminada.

Así que básicamente, Android siempre tendrá al menos 40 MB de memoria disponible, lo que es suficiente para acomodar una aplicación más antes de que lowmemorykiller comience su proceso de limpieza – lo que significa que Android siempre hará todo lo posible para utilizar la máxima cantidad de RAM disponible sin interferir con la experiencia del usuario.

Lamentablemente, lo que algunos entusiastas de la cerveza casera comenzaron a recomendar es que el valor se elevara a, por ejemplo, 100 MB antes de que LMK haga efecto. Ahora el usuario realmente perderá RAM (100 – 40 = 60), así que en lugar de usar este espacio para almacenar aplicaciones de back-end, el sistema mantendrá esta cantidad de memoria libre , sin ningún propósito para ello.

La sintonía de LKM puede ser útil para dispositivos mucho más antiguos con 512 RAM, pero, ¿quiénes son los dueños de esos dispositivos? 2GB es el «rango de presupuesto» moderno, incluso los dispositivos de 4GB de RAM se ven como «rango medio» en estos días, por lo que los ajustes de LMK son realmente anticuados e inútiles.

Ajustes de E/S

En muchos scripts de optimización para Android a menudo encontrarás ajustes que se refieren al subsistema de E/S. Por ejemplo, echemos un vistazo al ThunderBolt! Script, que contiene estas líneas:

 eco 0> $i/cola/rotacional;
eco 1024> $i/queue/nr_requests;

La primera línea le dará al programador de E/S instrucciones para tratar con un SSD, y la segunda incrementa el tamaño máximo de la cola de E/S de 128 a 1024 – porque la variable $i contiene una ruta al árbol de dispositivos de bloque en /sys, y el script se ejecuta en un bucle.

Después de eso, encuentras una línea relacionada con el programador de CFQ:

echo 1> $i/queue/iosched/back_seek_penalty;
eco 1> $i/queue/iosched/low_latency;
echo 1> $i/queue/iosched/slice_idle;

A esto le siguen más líneas que pertenecen a otros planificadores, pero al final, los dos primeros comandos no tienen sentido porque:

Un moderno núcleo de Linux es capaz de entender con qué tipo de medio de almacenamiento está trabajando por defecto.

Una larga cola de entrada y salida ( como la 1024) es inútil en un dispositivo Android moderno, de hecho no tiene sentido ni siquiera en el escritorio – en realidad sólo se recomienda en los servidores de alto rendimiento . Tu teléfono no es un servidor Linux de alto rendimiento.

Para un dispositivo Android, prácticamente no hay aplicaciones priorizadas en la entrada-salida y ningún controlador mecánico, por lo que el mejor planificador es la cola noop / FIFO, por lo que este tipo de planificador » tweak» no hace nada especial o significativo para el subsistema de E/S. De hecho, todos esos comandos de lista multipantalla son mejor reemplazados por un simple ciclo:

para i en /sys/block/mmc*; do
echo noop> $i/queue/scheduler
echo 0> $i/queue/iostats
hecho

Esto permitiría al programador noop para todas las unidades de la acumulación de estadísticas de E/S, lo que debería tener un impacto positivo en el rendimiento, aunque muy pequeño y casi completamente insignificante.

Otro ajuste de E/S inútil que se encuentra a menudo en los guiones de rendimiento es el aumento de los valores de lectura anticipada de las tarjetas SD de hasta 2 MB. El mecanismo de lectura anticipada es para lecturas tempranas de datos de los medios, antes de que la aplicación solicite el acceso a esos datos. Así que básicamente, el núcleo intentará averiguar qué datos se necesitarán en el futuro, y los carga previamente en la RAM, lo que debería reducir el tiempo de retorno. Esto suena muy bien sobre el papel, pero el algoritmo de lectura anticipada es más a menudo incorrecto , lo que lleva a operaciones totalmente innecesarias de entrada-salida, sin mencionar un alto consumo de RAM.

Se recomiendan valores altos de lectura anticipada de entre 1 y 8 MB en las matrices RAID, pero para los dispositivos Android, lo mejor es dejar el valor predeterminado de 128 KB.

Ajustes del sistema de gestión de la memoria virtual

Otra técnica común de «optimización» es la puesta a punto del subsistema de gestión de la memoria virtual. Normalmente, esto sólo tiene como objetivo dos variables del núcleo, vm.dirty_background_ratio y vm.dirty_ratio, que sirven para ajustar el tamaño del búfer para almacenar datos «sucios». Los datos sucios son típicamente datos que han sido escritos en el disco, pero hay más todavía en la memoria y esperando ser escritos en el disco.

Los valores típicos de ajuste tanto en las distribuciones de Linux como en Androis para el subsistema de administración de VM serían como:

vm.dirty_background_ratio = 10
vm.dirty_ratio = 20

Así que lo que esto trata de hacer es que cuando el búfer de datos sucio es el 10% de la cantidad total de RAM, despierta el flujo de pdflush y comienza a escribir datos en el disco – si la operación de grabación de datos en el disco será demasiado intensa , el búfer seguirá creciendo, y cuando alcance el 20% de la RAM disponible, el sistema pasará a la operación de escritura posterior en modo síncrono – sin pre-buffer. Esto significa que el trabajo de escritura en la aplicación de disco se bloqueará , hasta que los datos se escriban en el disco (AKA $0027lag$0027).

Lo que debes entender es que incluso si el tamaño del buffer no alcanza el 10% , el sistema automáticamente hará una patada en pdflush después de 30 segundos. Una combinación de 10/20 es bastante razonable, por ejemplo en un dispositivo con 1GB de RAM esto equivaldría a 100/200MB de RAM, lo cual es más que suficiente en términos de registros de ráfagas donde la velocidad es a menudo inferior al registro de velocidad en la memoria NAND del sistema, o tarjeta SD, como cuando se instalan aplicaciones o se copian archivos de una computadora.

Por alguna razón, los guionistas intentan elevar este valor aún más, hasta niveles absurdos. Por ejemplo, podemos encontrar en el guión de optimización Xplix una tasa tan alta como 50/90.

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

En un dispositivo con 1 GB de memoria, esto establece el límite de un búfer sucio a 500/900 MB, lo cual es completamente inútil para un dispositivo Android, porque sólo funcionaría bajo la grabación constante en el disco – algo que sólo ocurre en un servidor Linux pesado.

¡ThunderBolt! El guión usa un valor más razonable, pero en general, sigue sin tener sentido:

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

Los dos primeros comandos se ejecutan en smartphones con 512 MB de RAM, el segundo – con 1 GB, y otros – con más de 1 GB. Pero en realidad sólo hay una razón para cambiar la configuración predeterminada: un dispositivo con una memoria interna o tarjeta de memoria muy lenta. En este caso es razonable difundir los valores de las variables, es decir, hacer algo así:

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

Entonces, cuando un sistema de sobrecarga escribe operaciones, sin tener que grabar datos en el disco, hasta el último no cambiará al modo sincrónico, lo que permitirá a las aplicaciones reducir el retraso en la grabación.

Ajustes adicionales inútiles y afinaciones de rendimiento

Hay muchas más «optimizaciones» por ahí que realmente no hacen nada. La mayoría de ellas simplemente no tienen ningún efecto, mientras que otras pueden mejorar algún aspecto del rendimiento, mientras que degradan el dispositivo de otras maneras ( por lo general se reduce al rendimiento frente al agotamiento de la batería) .

Aquí hay algunas optimizaciones populares adicionales que pueden o no ser útiles, dependiendo del sistema y el dispositivo Android.

  • Aceleración – La pequeña aceleración para mejorar el rendimiento y el subvoltaje – ahorra un poco de batería.
  • Optimización de la base de datos – En teoría esto debería dar una mejora en el rendimiento del dispositivo, pero es dudoso.
  • Zipalign – Irónicamente, a pesar de la característica incorporada en el SDK de Android de alineación de contenido dentro del archivo APK en la tienda puedes encontrar que un montón de software no se transmite a través de zipalign.
  • Deshabilitar los servicios innecesarios del sistema, eliminando las aplicaciones de terceros que no se utilizan y que rara vez se usan. Básicamente, desinstalar el bloatware.
  • Núcleo personalizado con optimizaciones para un dispositivo específico (de nuevo, no todos los núcleos son igualmente buenos).
  • Ya he descrito el programador de E/S noop.
  • Algoritmo de saturación TCP Westwood – Utilizado de forma más eficiente en el Android Cubic predeterminado para redes inalámbricas, disponible en núcleos personalizados.

Ajustes inútiles build.prop

LaraCraft304 del foro de desarrolladores de XDA ha realizado un estudio y ha encontrado que un número impresionante de configuraciones de /system/build.prop que se recomiendan para su uso «expertos» no existen en la fuente AOSP y CyanogenMod. Aquí está la lista:

ro>ril.deshabilitar.el.colapso.de.energía
ro mot eri losalert delay
ro.config.hw_fast_dormancy
ro.config.hw_potencia_de_ahorro
windowsmgr.max_events_per_sec
persist.cust.tel.eons
ro.max.fling_velocity
ro.min.fling_velocity
ro.kernel.checkjni
dalvik.vm.verify-bytecode
ajuste.de.rendimiento.de.depuración
video.acelerar.hw
ro.media.dec.jpeg.memcap
ro.config.nocheckin
profiler.force_disable_ulog
profiler.force_disable_err_rpt
modo.de.apagado.del.sistema.de.emergencia
ro.HOME_APP_ADJ
También te puede interesar:  Cómo transferir datos del iPhone al Samsung S7/S6/S6 Edge

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.