Los mitos más comunes de optimización de Android desacreditados

Por lo tanto, muchos scripts de optimización todo en uno utilizan los mismos métodos, algunos de los cuales están completamente desactualizados o son dañinos a largo plazo. En resumen, la mayoría de las secuencias de comandos de optimización 'todo en uno' no son más que ajustes recomendados, sin una idea clara de cómo o por qué estas optimizaciones 'funcionan: los usuarios luego actualizan las secuencias de comandos 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 provocado un aumento del 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 ' optimizando ' 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 que se lo considere 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 papel , pero es realmente aplicable a un servidor , que casi no tiene interactividad.

Cuando usa el intercambio de su teléfono Android con regularidad, se producirán retrasos graves que se derivan de cosas que se escapan 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 complicado.

Algunos entusiastas de la optimización pueden decir que el intercambio no ofreció problemas, pero no es un intercambio lo que aumenta el rendimiento: es el mecanismo integrado de Android. asesino de poca memoria , que matará regularmente los procesos inflados y 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 kswapd proceso, y generalmente mata los procesos del 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á plagada de retrasos y conduce a una degradación en el rendimiento, en lugar de optimizarlo.

zRAM - Desactualizado y ya no es eficiente

zRAM es un método probado y eficaz para la optimización de dispositivos, para dispositivos antiguos - Piense en dispositivos basados ​​en KitKat que funcionan con solo 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 personas que generalmente no siguen los últimos protocolos operativos.

zRAM fue diseñado para SoC multinúcleo de rango de presupuesto de nivel de entrada, como dispositivos que utilizan chipsets MTK y 512 MB de RAM. Teléfonos chinos muy baratos, básicamente. Lo que zRAM básicamente hace es separar el kernel a través del flujo de cifrado.

Cuando se utiliza zRAM en dispositivos más antiguos con núcleo simple , incluso si se recomienda zRAM en tales dispositivos, tienden a aparecer grandes cantidades de retrasos. Esto también sucede con la tecnología KSM ( Combinación de la misma página del kernel) 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 theads del núcleo constantemente activos se ejecutan continuamente desde la memoria para buscar páginas duplicadas. Básicamente, intentar ejecutar el ajuste de optimización ralentiza aún más el dispositivo, irónicamente.

Sembradora - Desactualizado desde Android 3.0

Uno de los consejos de optimización más debatidos entre los desarrolladores de Android es cedro , 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 motivo, 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 todavía se mantenga y se ofrezca como ' moderno' La herramienta de reducción de retrasos 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 eficaz después de Android 4.0+. Sin embargo, por alguna razón, Seeder sigue apareciendo en las discusiones de optimización para los sistemas Android modernos.

Lo que Seeder básicamente hace para Android 3.0 es solucionar 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 requerida de datos; piense en pequeñas cosas como los diversos sensores y botones del dispositivo Android.

El autor de Seeder tomó el demonio de Linux rngd , y compilado 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 que / dev / random / se agote. Esto resultó en un sistema Android que no experimentó una falta de entropía y funcionó mucho más suave.

Google eliminó este error después de Android 3.0, pero por alguna razón, Seeder todavía aparece en 'Ajustes recomendados' listas 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 usando el mismo rngd o la alternativa hasged , o incluso un enlace simbólico entre / dev / urandom y / dev / random. Esto es absolutamente inútil para los sistemas Android modernos.

La razón por la que no tiene sentido es 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 al crear sistemas de archivos EXT2 / EXT3 / EXT4.

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

Odex

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

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; en el lado negativo, los archivos ODEX evitan modificaciones en el firmware y crean problemas con las actualizaciones, por lo que, por esta razón, se distribuyen muchas ROM personalizadas como LineageOS. sin ODEX .

La generación de archivos ODEX se realiza de varias maneras, como mediante el uso de 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, muestra una nueva versión de Android y muestra el mensaje 'Ocupado, optimizando aplicaciones' durante un tiempo.

Ajustes de Lowmemorykiller

La multitarea en Android se diferencia 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 uno esté configurado en Opciones de desarrollador, pero generalmente se recomienda no hacerlo) - 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 baja memoria y el asesino de memoria insuficiente anteriormente en esta guía) .

Para volver al asesino de poca memoria mecanismo, Android puede seguir funcionando con una cantidad limitada de memoria y una falta de partición de intercambio. El usuario puede continuar iniciando aplicaciones y alternar entre ellas, y el sistema eliminará silenciosamente las 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 ha vuelto popular en forma de aplicaciones que eliminan tareas, que generalmente son más dañinas que beneficiosas. Las aplicaciones que eliminan 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 de Android.

De hecho, tener una gran cantidad de RAM libre puede ser perjudicial para el rendimiento y la duración de la batería de su dispositivo. Cuando las aplicaciones se almacenan en la RAM de Android, es mucho más fácil llamarlas, ejecutarlas, 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 tan populares como antes, aunque los principiantes 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 asesino de poca memoria afinaciones del mecanismo. Esto sería por ejemplo MinFreeManager app, y la idea principal es aumentar la sobrecarga de RAM antes de que el sistema comience a eliminar las aplicaciones en segundo plano.

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

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

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

Sintonización LKM puede ser útil para dispositivos mucho más antiguos con 512 RAM, pero ¿quién es el propietario? 2GB es el 'rango económico' moderno, incluso los dispositivos de 4GB RAM se ven como 'rango medio' en estos días, por lo que los ajustes de LMK están realmente desactualizados 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 ¡Rayo! Script, que contiene estas líneas:

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

La primera línea le dará las instrucciones del programador de E / S al tratar con un SSD, y la segunda aumenta el tamaño máximo de la E / S de la 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.

A continuación, encontrará una línea relacionada con el programador CFQ:

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

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

Un kernel moderno de Linux es capaz de comprender con qué tipo de medio de almacenamiento está trabajando de forma 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 de servicio pesado . Su teléfono no es un servidor Linux de alta resistencia.

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 el noop / FIFO-queue, por lo que este tipo de planificador ' retocar' no está haciendo nada especial o significativo para el subsistema de E / S. De hecho, todos esos comandos de lista multipantalla se reemplazan mejor con un ciclo simple:

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 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 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 lecturas tempranas de datos de los medios, antes de que la aplicación solicite acceso a esos datos. Básicamente, el kernel intentará averiguar qué datos se necesitarán en el futuro y los precargará en la RAM, lo que reducirá el tiempo de retorno. Esto suena muy bien en papel, pero el algoritmo de lectura anticipada es más frecuente incorrecto , lo que conduce a operaciones de entrada-salida totalmente innecesarias, 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, es mejor dejar el valor predeterminado de 128 KB.

Ajustes del sistema de gestión de memoria virtual

Otra técnica de 'optimización' común es ajustar el subsistema de administración de memoria virtual. Por lo general, esto apunta solo a dos variables del kernel, vm.dirty_background_ratio y vm.dirty_ratio, que sirven para ajustar el tamaño del búfer para almacenar datos 'sucios'. Sucio Los datos suelen ser datos que se han escrito en el disco, pero todavía hay más en la memoria y esperando a que se escriban en el disco.

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

vm.dirty_background_ratio = 10 vm.dirty_ratio = 20

Entonces, lo que esto intenta hacer es que cuando el búfer de datos sucios sea el 10% de la cantidad total de RAM, se despierte pdflush fluye y comienza a escribir datos en el disco, si la operación de grabación de datos en el disco será muy intenso , el búfer seguirá creciendo y, cuando alcance el 20% de la RAM disponible, el sistema cambiará a la siguiente operación de escritura en modo síncrono, sin pre-búfer. Esto significa que el trabajo de escribir en la aplicación de disco será bloqueado, hasta que los datos se escriben en el disco (AKA 'lag').

Lo que debe comprender es que incluso si el tamaño del búfer no llega al 10% , el sistema se activará automáticamente en 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, lo que es más que suficiente en términos de registros de ráfagas 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 desde una computadora.

Por alguna razón, los escritores de guiones intentan impulsar este valor aún más, a un ritmo absurdo. Por ejemplo podemos encontrar en el Xplix secuencia de comandos de optimización 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 en 500/900 MB, lo cual 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 servidor Linux pesado.

¡Rayo! El script usa un valor más razonable, pero en general, sigue siendo bastante insignificante:

si ['$ 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; else sysctl -w vm.dirty_background_ratio = 5; sysctl -w vm.dirty_ratio = 10; fi;

Los dos primeros 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 una tarjeta de memoria muy lenta. En este caso es razonable esparcir los valores de las variables, es decir, hacer algo como esto:

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

Entonces, 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 lag a la hora de grabar.

Ajustes adicionales inútiles 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 aspecto del rendimiento, mientras degrada el dispositivo de otras formas ( generalmente se reduce al rendimiento frente al agotamiento de la batería) .

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

• Aceleración: la pequeña aceleración para mejorar el rendimiento y la subtensión 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 alineación de contenido de la función SDK de Android incorporada dentro del archivo APK en la tienda, puede encontrar una gran cantidad de software que no se transmite a través de zipalign.
• Deshabilite los servicios del sistema innecesarios, 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 (nuevamente, no todos los núcleos son igualmente buenos).
• Ya se ha descrito el planificador de E / S noop.
• Algoritmo de saturación TCP Westwood: se usa de manera más eficiente en el Android Cubic predeterminado para redes inalámbricas, disponible en kernels personalizados.

Configuraciones inútiles build.prop

LaraCraft304 del foro XDA Developers ha realizado un estudio y ha descubierto que una cantidad impresionante de configuraciones de /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.shutdown.APP ro.ADJOME_APP