Mitos de optimización de Android más comunes desacreditados

Existen muchas guías de instrucciones dedicadas a aumentar el rendimiento de Android y consejos generales de optimización. Algunos de ellos son legítimos, y otros se basan solo en la teoría, o en métodos operativos obsoletos en el sistema Android, o simplemente no tienen sentido. Esto incluye recomendaciones para intercambiar, valores agregados a build.prop y cambios variables en el kernel de Linux.

Incluso hay una tonelada de "secuencias de comandos de optimización", .zips flash todo en uno que prometen aumentar significativamente el rendimiento, la duración de la batería y otras cosas. Algunos de los ajustes realmente pueden funcionar, pero la mayoría son simplemente un efecto placebo o, lo que es peor, tienen un impacto negativo en su dispositivo.

Eso no quiere decir que las personas estén lanzando scripts nefastos intencionalmente; definitivamente hay aplicaciones pagas falsas en Play Store, pero los scripts de optimización lanzados en los foros de Android generalmente son bien intencionados, simplemente sucede que el desarrollador puede estar mal informado, o simplemente experimentando con varios ajustes de optimización. Desafortunadamente, tiende a ocurrir una especie de efecto bola de nieve, especialmente en los scripts de optimización "todo en uno". Un pequeño puñado de 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 balas mágicas, sin ninguna investigación real sobre qué funciona y qué no .

Por lo tanto, muchos scripts de optimización todo en uno están utilizando los mismos métodos, algunos de los cuales son completamente obsoletos o perjudiciales a largo plazo. En resumen, la mayoría de los scripts de optimización "todo en uno" no son más que ajustes recomendados combinados, sin una idea clara de cómo o por qué funcionan estas optimizaciones: los usuarios luego flashean los scripts y afirman que su rendimiento es repentinamente más rápido ( cuando, de hecho, lo más probable es que el simple acto de reiniciar su dispositivo haya causado un aumento en el 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 Android, y si son simplemente un mito o un ajuste legítimo para el rendimiento del dispositivo.

Intercambiar

En la parte superior de la lista de mitos está el intercambio de Android, que es bastante absurdo en términos de ser considerado como una optimización de Android. El propósito principal de Swaps 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 usa el intercambio de su teléfono Android con regularidad, dará lugar a retrasos graves que se derivan de cosas que se deslizan más allá del caché. Imagine, por ejemplo, si una aplicación intenta mostrar un gráfico, que se almacena en el intercambio, que ahora tiene que volver a cargar el disco después de liberar espacio colocando el intercambio de datos con otra aplicación. Es realmente desordenado

Algunos entusiastas de la optimización pueden decir que el intercambio no ofreció problemas, pero no es un intercambio que aumenta el rendimiento: es el mecanismo de Android incorporado lowmemorykiller, que matará regularmente los procesos hinchados de alta prioridad que no se están utilizando. LMK fue diseñado específicamente para manejar condiciones de poca memoria, se invoca desde el proceso kswapd y generalmente mata los procesos de espacio de usuario. Esto es diferente de OOMkiller (asesino sin memoria), pero ese es un tema completamente diferente.

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

zRAM: anticuado y ya no es 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 operan con solo aproximadamente 512 MB de RAM. El hecho de que algunas personas aún 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 personas que generalmente no siguen los últimos protocolos operativos.

zRAM estaba destinado a SoCs multinúcleo de rango económico de nivel básico, como dispositivos que utilizan conjuntos de chips MTK y 512 MB de RAM. Teléfonos chinos muy baratos, básicamente. Lo que básicamente hace zRAM es separar el núcleo a través de la secuencia de cifrado.

Cuando se usa zRAM en dispositivos más antiguos con un solo núcleo, incluso si se recomienda zRAM en dichos dispositivos, tienden a surgir grandes cantidades de retrasos. Esto también sucede con la tecnología KSM ( Kernel Same Page Merging) que combina páginas de memoria idénticas en un intento por liberar espacio. De hecho, esto es recomendado por Google, pero conduce a mayores retrasos en los dispositivos más antiguos, porque los cabezales centrales 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.

Sembradora: desactualizada desde Android 3.0

Uno de los consejos de optimización más debatidos entre los desarrolladores de Android es la sembradora, y estamos seguros de que alguien podría intentar demostrar que estamos equivocados en este tema, pero primero debemos examinar la historia de la sembradora.

Aplicación Seeder para Android

Sí, hay una gran cantidad de informes que declaran un mejor rendimiento de Android después de la instalación en dispositivos Android mucho más antiguos . Sin embargo, las personas, por cualquier razón, creen 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 aún se mantenga y se ofrezca como una herramienta de reducción de retraso " moderna" es un ejemplo de información errónea, aunque esto no es culpa del desarrollador de Seeder, ya que incluso su página de Play Store señala que Seeder es menos eficaz después de Android 4.0+. Sin embargo, por cualquier razón, Seeder todavía aparece en las discusiones de optimización para los sistemas Android modernos.

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

El autor de Seeder tomó Linux-demon rngd y compiló para la inastroil de Android, de modo que tomó datos aleatorios de una ruta / dev / urandom mucho más rápida y predecible, y los fusionó en dev / random / cada segundo, sin permitir / dev / random / agotarme. Esto dio como resultado un sistema Android que no experimentó una falta de entropía y funcionó mucho mejor.

Google eliminó este error después de Android 3.0, sin embargo, por alguna razón, Seeder todavía aparece en las listas de "ajustes recomendados" para la optimización del rendimiento de Android. Además, la aplicación Seeder tiene algunos análogos como sEFix que incluyen la funcionalidad de Seeder, ya sea que use el mismo rngd o el hasge alternativo, o incluso solo un enlace simbólico entre / dev / urandom y / dev / random. Esto es absolutamente inútil para los sistemas Android modernos.

La razón no tiene sentido porque las versiones más recientes de Android usan / dev / random / en tres componentes principales: libcrypto, para el cifrado de conexiones SSL, generación de claves SSH, etc. WPA_supplication / hostapd que genera claves WEP / WPA, y finalmente, un puñado de bibliotecas para generar ID en la creación de sistemas de archivos EXT2 / EXT3 / EXT4.

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

Odex

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

Por lo tanto, los archivos odex están destinados a descargar la máquina virtual y ofrecer un lanzamiento acelerado de la aplicación odexed; a la baja, los archivos ODEX evitan modificaciones en el firmware y crean problemas con las actualizaciones, por lo que muchas ROM personalizadas como LineageOS se distribuyen sin ODEX

La generación de archivos ODEX se realiza de varias maneras, como usar la herramienta Odexer: el problema es que es puramente un efecto placebo. Cuando el sistema Android moderno no encuentra archivos odex en el directorio / system, el sistema los creará y los colocará en el directorio / system / dalvik-cache /. Esto es exactamente lo que sucede cuando, por ejemplo, presenta una nueva versión de Android y muestra el mensaje "Ocupado, optimizando aplicaciones" por un tiempo.

Ajustes de Lowmemorykiller

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 la cantidad de aplicaciones en segundo plano (a menos que una esté configurada en Opciones de desarrollador, pero esto es generalmente recomendado en 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 eliminar aplicaciones en segundo plano en situaciones de poca memoria ( vea dónde hablamos sobre el asesino de memoria baja y el asesino sin memoria anteriormente en este guía) .

Para volver al mecanismo de baja memoria, Android puede continuar funcionando con una cantidad limitada de memoria y una falta de partición de intercambio. El usuario puede continuar iniciando aplicaciones y cambiar entre ellas, y el sistema eliminará silenciosamente aplicaciones en segundo plano no utilizadas para intentar liberar memoria para 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 que eliminan tareas, que generalmente son más dañinas que beneficiosas. Las aplicaciones que eliminan las tareas se activan a intervalos establecidos o son ejecutadas por el usuario y parecen liberar grandes cantidades de RAM, lo que se considera positivo: más RAM libre significa un dispositivo más rápido, ¿verdad? Sin embargo, este no es exactamente el caso con Android.

De hecho, tener una gran cantidad de RAM libre puede ser dañino para el rendimiento de su 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, iniciarlas, 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 alguna vez lo fueron, aunque los novatos de Android todavía tienden a confiar en ellos por alguna razón ( falta de información, lamentablemente) . Desafortunadamente, una nueva tendencia ha reemplazado a los asesinos de tareas, la tendencia de los ajustes del mecanismo de baja memoria . Esta sería, por ejemplo, la aplicación MinFreeManager, y la idea principal es aumentar la sobrecarga de RAM antes de que el sistema comience a eliminar aplicaciones en segundo plano.

Entonces, por ejemplo, la RAM estándar funciona en los bordes: 4, 8, 12, 24, 32 y 40 Mb, y cuando se llena el espacio de almacenamiento libre de 40 MB, una de las aplicaciones en caché que se carga en la memoria pero no se ejecuta se dará por terminado.

Básicamente, Android siempre tendrá al menos 40 MB de memoria disponible, 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 usar la máxima cantidad de RAM disponible sin interferir con el experiencia de usuario.

Lamentablemente, lo que algunos entusiastas de homebrew comenzaron recomendando es que el valor se aumente a, por ejemplo, 100 MB antes de que LMK entre en acción. Ahora el usuario realmente perderá RAM (100 - 40 = 60), por lo que en lugar de usar este espacio para almacenar Al finalizar las aplicaciones, el sistema mantendrá esta cantidad de memoria libre, sin ningún propósito.

El ajuste de LKM puede ser útil para dispositivos mucho más antiguos con 512 RAM, pero ¿quién es el propietario? 2 GB es el moderno "rango de presupuesto", incluso los dispositivos de 4 GB de RAM se ven como "rango medio" en estos días, por lo que los ajustes de LMK son realmente obsoletos e inútiles.

Ajustes de E / S

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

 echo 0> $ i / queue / rotacional; echo 1024> $ i / queue / nr_requests; 

La primera línea le dará al planificador de E / S instrucciones para lidiar con un SSD, y la segunda aumenta el tamaño máximo de la E / S de cola 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, encontrará una línea relacionada con 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; 

Esto es seguido por más líneas que pertenecen a otros planificadores, pero en última instancia, los dos primeros comandos no tienen sentido porque:

Un núcleo Linux moderno es capaz de comprender con qué tipo de medio de almacenamiento está trabajando de manera predeterminada.

Una larga cola de entrada-salida ( como 1024) es inútil en un dispositivo Android moderno, de hecho, no tiene sentido incluso en el escritorio, en realidad solo se recomienda en servidores pesados . Su teléfono no es un servidor Linux resistente.

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 " ajuste" del planificador no está haciendo nada especial o significativo para el Subsistema de E / S. De hecho, todos esos comandos de lista de pantallas múltiples se reemplazan mejor por un ciclo simple:

 para i in / sys / block / mmc *; do echo noop> $ i / queue / Scheduler echo 0> $ i / queue / iostats done 

Esto habilitaría el programador noop para todas las unidades a partir 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 a menudo se encuentra en los scripts de rendimiento es el aumento de los valores de lectura anticipada para tarjetas SD de hasta 2 MB. El mecanismo de lectura anticipada es para las primeras lecturas de datos de los medios, antes de que la aplicación solicite acceso a esos datos. Básicamente, el núcleo intentará averiguar qué datos se necesitarán en el futuro y los precargará en la RAM, lo que debería reducir el tiempo de retorno. Esto suena muy bien en el papel, pero el algoritmo de lectura anticipada a menudo es incorrecto, lo que lleva a operaciones totalmente innecesarias de entrada-salida, sin mencionar un alto consumo de RAM.

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

Ajustes del sistema de gestión de memoria virtual

Otra técnica común de "optimización" es ajustar el subsistema de administración de memoria virtual. Esto normalmente apunta solo a dos variables del núcleo, vm.dirty_background_ratio y vm.dirty_ratio, que son para ajustar el tamaño del búfer para almacenar datos "sucios". Los datos sucios suelen ser datos que se han escrito en el disco, pero aún hay más en la memoria y en espera de ser escritos en el disco.

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

 vm.dirty_background_ratio = 10 vm.dirty_ratio = 20 

Entonces, lo que esto intenta hacer es que cuando el búfer de datos sucios 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 continuará creciendo y, cuando alcance el 20% de la RAM disponible, el sistema cambiará a la operación de escritura posterior en modo síncrono, sin pre-búfer. Esto significa que se bloqueará el trabajo de escritura en la aplicación de disco , hasta que los datos se escriban en el disco (también conocido como "retraso").

Lo que debe comprender es que incluso si el tamaño del búfer no alcanza el 10%, el sistema iniciará automáticamente el pdflush después de 30 segundos. Una combinación de 10/20 es bastante razonable, por ejemplo, en un dispositivo con 1 GB de RAM, esto equivaldría a 100/200 MB de RAM, que es más que suficiente en términos de registros de ráfaga donde la velocidad suele estar por debajo del registro de velocidad en el sistema NAND -memoria o tarjeta SD, como al instalar aplicaciones o copiar archivos de una computadora.

Por alguna razón, los escritores de guiones intentan llevar este valor aún más alto, a tasas absurdas. Por ejemplo, podemos encontrar en el script de optimización de 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 que es completamente inútil para un dispositivo Android, porque solo funcionaría bajo grabación constante en el disco, algo que solo sucede en un disco pesado Servidor Linux

¡Rayo! La secuencia de comandos utiliza un valor más razonable, pero en general, todavía no tiene sentido:

 if ["$ mem" -lt 524288], entonces sysctl -w vm.dirty_background_ratio = 15; sysctl -w vm.dirty_ratio = 30; elif ["$ mem" -lt 1049776], luego sysctl -w vm.dirty_background_ratio = 10; sysctl -w vm.dirty_ratio = 20; sino sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi; 

Los primeros dos comandos se ejecutan en teléfonos inteligentes con 512 MB de RAM, el segundo, con 1 GB, y otros, con más de 1 GB. Pero, de hecho, solo 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 como esto:

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

Luego, cuando un sistema de sobretensión escribe operaciones, sin tener que grabar datos en el disco, hasta el último no cambiará al modo síncrono, lo que permitirá que las aplicaciones reduzcan el retraso durante la grabación.

Ajustes inútiles adicionales y ajustes de rendimiento

Hay muchas más "optimizaciones" que realmente no hacen nada. La mayoría de ellos simplemente no tienen ningún efecto, mientras que otros pueden mejorar algunos aspectos del rendimiento, al tiempo 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 ser útiles o no, dependiendo del sistema y dispositivo Android.

  • Aceleración: la pequeña aceleración para mejorar el rendimiento y la baja tensión ahorra un poco de batería.
  • Optimización de la base de datos: en teoría, esto debería mejorar el rendimiento del dispositivo, pero es dudoso.
  • Zipalign: Irónicamente, a pesar de la alineación de contenido de la función SDK de Android incorporada dentro del archivo APK en la tienda, puede encontrar que una gran cantidad de software no se transmite a través de zipalign.
  • Deshabilite los servicios innecesarios del sistema, eliminando el sistema no utilizado y las aplicaciones de terceros que rara vez se utilizan. Básicamente, desinstalar bloatware.
  • Kernel personalizado con optimizaciones para un dispositivo específico (de nuevo, no todos los núcleos son igualmente buenos).
  • Ya se ha descrito el programador de E / S noop.
  • Algoritmo de saturación TCP Westwood: se utiliza de manera más eficiente en el Android Cubic predeterminado para redes inalámbricas, disponible en núcleos personalizados.

Configuración inútil build.prop

LaraCraft304 del foro de desarrolladores de XDA realizó un estudio y descubrió que un número impresionante de configuraciones /system/build.prop que se recomiendan para el uso de "expertos" no existen en la fuente AOSP y CyanogenMod. Aquí está la lista:

 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 ersist.sys.shutOME.mode roH. 

Artículos De Interés