Se sabe que la función de Accesibilidad de Android provoca retrasos en la interfaz de usuario. ¿Es un error o es una característica? ¿Por qué ocurre? En XDA investigamos la causa raíz.
La belleza de Android radica en las diferentes formas en que las aplicaciones de terceros pueden interactuar con el sistema. Aplicaciones de administrador de contraseñas como Ultimo pase Proporciona la capacidad de introducir automáticamente datos de nombre de usuario/contraseña relevantes en casi cualquier pantalla de inicio de sesión. Asistente de texto le permite acortar significativamente el tiempo que dedica a enviar mensajes de texto a sus amigos al permitirle crear macros de expansión de texto. Portapapeles nativo reduce la molestia que implica cambiar frecuentemente entre aplicaciones para copiar grandes cantidades de texto al permitirle tocar dos veces cualquier campo de entrada para abrir un portapapeles. quien puede olvidar Ecologizar, quizás la aplicación número uno más recomendada por los entusiastas, que mantiene bajo control las aplicaciones maliciosas en segundo plano y, por lo tanto, puede mejorar la duración de la batería. Finalmente, aunque menos familiar para la mayoría de los usuarios, hay
Entrada automática - un complemento de Tasker diseñado para automatizar toques en la pantalla, entrada de texto, gestos de deslizamiento y mucho más. Todas estas aplicaciones sirven para casos de uso muy diferentes, pero cada una de ellas se basa en una parte muy incomprendida de la funcionalidad principal de Android: Accesibilidad.Para el usuario promedio de Android, puede parecer extraño que muchas de estas increíbles funciones utilizadas por su aplicación favorita estén controladas mediante una configuración debajo del accesibilidad submenú. Hacer una aplicación accesible Por lo general, se supone que significa que una aplicación de Android es utilizable por una persona con discapacidades. Entonces, ¿por qué LastPass, Native Clipboard, Text Aide, Greenify o AutoInput tienen una accesibilidad ¿servicio? Además, ¿por qué habilitar un servicio de accesibilidad parece causa mucho retraso en la interfaz de usuario? No parece importar en qué versión de Android estés, ya sea Android 5.0 piruleta o Android 7.0 Turrón - porque el retraso causado por ciertos servicios de accesibilidad puede afectar tu experiencia. Una solución simple a este problema es simplemente deshabilitar los servicios de accesibilidad que haya habilitado, pero al hacerlo, perdemos muchas funciones útiles. Otra solución es pedirle a Google que "arregle" el retraso de accesibilidad de Android, pero Google afirma que la accesibilidad de Android es trabajando según lo previsto. Hemos hablado con algunos desarrolladores muy familiarizados con los servicios de accesibilidad y hemos investigado cómo funciona la funcionalidad, y estamos aquí para probar esa afirmación: ¿El retraso de accesibilidad de Android es un error o es una característica?
Comprender la accesibilidad de Android
Como puede imaginar por el nombre, Accesibilidad está destinada principalmente a que los desarrolladores proporcionen funciones adicionales a cualquier usuario con discapacidades. De hecho, un vistazo rápido a la páginas de documentación oficial para Accesibilidad revela que Google tiene una visión bastante limitada sobre qué tipos de servicios deberían proporcionar los Servicios de Accesibilidad.
Muchos usuarios de Android tienen diferentes capacidades que les exigen interactuar con sus dispositivos Android de diferentes maneras. Estos incluyen usuarios que tienen limitaciones visuales, físicas o relacionadas con la edad que les impiden ver o ver completamente. usando una pantalla táctil y usuarios con pérdida auditiva que tal vez no puedan percibir información y alertas audibles.
Android proporciona funciones y servicios de accesibilidad para ayudar a estos usuarios a navegar más en sus dispositivos. fácilmente, incluyendo conversión de texto a voz, retroalimentación háptica, navegación por gestos, trackball y teclado direccional navegación.
de google Replicar, que viene preinstalado en todos los teléfonos Android, es un gran ejemplo de cómo se supone que es el Servicio de Accesibilidad "típico". Acceso por voz lleva la accesibilidad un paso más allá y permite un control casi completo de su teléfono usando solo su voz. Pero el hecho de que Google haya previsto que los Servicios de Accesibilidad se utilicen de esta manera no impide los desarrolladores los implementen de la forma que quieran, y eso es exactamente lo que los desarrolladores tienen hecho. Es exactamente por la forma en que funciona la Accesibilidad lo que hace que la función increíblemente útil para usuarios con o sin discapacidades.
Para simplificar un poco las cosas, aquí hay un resumen básico de cómo funciona la Accesibilidad de Android. Un desarrollador crea un Servicio de Accesibilidad que se suscribe a varios Eventos de accesibilidad que son enviados por el sistema al Servicio dependiendo de si se cumplen o no ciertos criterios. Cuando todos los servicios están deshabilitados en Configuración --> Accesibilidad, Android no recopila ni envía ningún evento de accesibilidad. Pero cuando el usuario comience a habilitar los Servicios de Accesibilidad, Android comenzará a monitorear y recopilar sólo aquellos Eventos de Accesibilidad que el Servicio de Accesibilidad solicite. Por ejemplo, un Servicio de Accesibilidad que se suscribe al Evento de Accesibilidad TYPE_WINDOW_CONTENT_CHANGED será notificado por el sistema cada vez que se produce un cambio en la ventana actual. Otro evento de accesibilidad llamado TYPE_VIEW_CLICKED se dispara cada vez el usuario hace clic en un botón de algún tipo.
Demostración de accesibilidad de Android. En este video, he habilitado la aplicación. Tasker monitorear para cambios en el título de la ventana. Esto requiere habilitar el Servicio de Accesibilidad de Tasker. Puede replicar esto creando un nuevo perfil en Tasker con el contexto 'Evento' establecido en 'Conjunto de variables' y eligiendo %WIN como variable a monitorear. En total, este video de aproximadamente 1 minuto capturó 107 cambios en la ventana actual.
Este tipo de Eventos de Accesibilidad ocurren con gran frecuencia durante la interacción normal del usuario. Así que imagina lo que sucede cuando un usuario permite múltiples servicios de accesibilidad que solicitan que se realicen eventos de accesibilidad de alta frecuencia. Así es - retraso. Para mitigar esto, los desarrolladores pueden definir de manera más precisa qué tipos de eventos de accesibilidad El servicio debe reaccionar y en qué contexto, como la capacidad de limitar el servicio para que solo reaccione. cuando en ciertas aplicaciones o limitar la período de votación entre Eventos. Pero aparte de eso, la cantidad de gastos generales generados por un Servicio de Accesibilidad depende principalmente de ¿Qué tipo de eventos de accesibilidad? al que se suscribe. En esencia, no todos los Servicios de Accesibilidad provocarán retrasos. Un único Servicio de Accesibilidad que requiere un Evento de alta frecuencia puede causar retrasos, especialmente si dicho Servicio está acoplado a otro Servicio que requiere la realización de otro Evento de alta frecuencia. monitoreado.
Profundizando en la accesibilidad con desmontajes de APK
Como se puede ver en el vídeo publicado anteriormente, un Servicio de Accesibilidad que monitorea los cambios en el contenido de la ventana puede dar como resultado cambios bastante notables en el rendimiento de la interfaz de usuario debido a la gran cantidad de eventos de accesibilidad capturados activados por el sistema. Sin embargo, es bastante difícil determinar exactamente cuántos gastos generales genera un servicio de accesibilidad en particular. Monitorear LogCat generalmente no lo llevará a ninguna parte, ya que los eventos de accesibilidad solo se imprimen en LogCat si el desarrollador del servicio de accesibilidad así lo decide. Afortunadamente, el padre de todos los servicios de accesibilidad de Android, Entrada automática, hace exactamente eso. Y la salida de LogCat es exactamente tan desordenada como te imaginas.
AutoInput no nos oculta la verdad. La sobrecarga causada por la aplicación puede ser bastante enorme dependiendo de los eventos que monitoree. Pero esta sobrecarga es necesaria para que la aplicación funcione. Para que AutoInput intercepte cada pulsación de tecla, cada gesto en la pantalla, cada actualización de la interfaz de usuario y cada pulsación de botón, necesidades para monitorear los respectivos Eventos de Accesibilidad. Sin estos eventos, AutoInput no puede conectarse al sistema y proporcionar la automatización de la interfaz de usuario casi ilimitada que permite actualmente. Por tanto, todas las funciones de AutoInput tienen perfecto sentido en el contexto de Accesibilidad. Pero para otras aplicaciones, debemos profundizar un poco más para comprender cómo se manejan sus Servicios de Accesibilidad.
Un servicio de accesibilidad atributos se definen en un archivo de recursos XML dentro del APK. Por tanto, podemos realizar una Desmontaje de APK en una aplicación con un Servicio de Accesibilidad para descubrir los atributos del Servicio. Cada aplicación funciona de manera diferente, por lo que intentaré explicar cómo se relacionan los atributos de su Servicio con la función específica que realiza.
Portapapeles nativo
Native Clipboard es mi opción cuando se trata de administradores de portapapeles. Si está buscando un administrador de portapapeles altamente personalizable, Native Clipboard es una aplicación excelente. ¡Incluso tiene un componente Xposed Module que le permite mantener presionado el botón 'Pegar' para abrir el administrador del portapapeles! Desafortunadamente, si no tienes acceso a Xposed Framework (como todos los usuarios de Nougat), tendrás que conformarte para habilitar el Servicio de Accesibilidad que le permitirá tocar dos veces cualquier entrada de texto para abrir el portapapeles gerente. Esto es lo que eso implica.
"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro /> El Servicio de Accesibilidad del Portapapeles Nativo solicita activar un Evento de Accesibilidad cada vez que se hace clic en una vista, se hace clic prolongadamente, se enfoca o si hay un cambio en el estado de la ventana. Sin tener acceso al código fuente, no puedo decir exactamente cómo funciona Native Clipboard, pero es probable que Native Clipboard espera a que el estado de la ventana indique que el teclado virtual está actualmente abierto y luego monitorea los toques en la entrada campo. La aplicación tiene un período de sondeo de 100 ms, por lo que definitivamente es lo suficientemente rápido como para reaccionar básicamente de inmediato a los cambios en la visibilidad del teclado virtual, así como a los dobles toques. Esto podría generar cierta sobrecarga en la interfaz de usuario cada vez que el usuario utiliza el teclado virtual para escribir cualquier texto, lo que podría provocar un retraso.
Ecologizar
El siguiente es el ahorrador de batería favorito de todos, Greenify. Greenify utiliza eventos de accesibilidad para potenciar sus funciones no raíz.
"@string/accessibility_service_description"
android: settingsActivity="com.oasisfeng.greenify.accessibility.AccessibilitySettings"
android: accessibilityEventTypes="typeAnnouncement|typeNotificationStateChanged|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric" android: notificationTimeout="0"
android: accessibilityFlags="flagReportViewIds"
android: canRetrieveWindowContent="true"
xmlns: andro /> Utiliza cambios en el estado de la ventana para determinar cuándo se apaga la pantalla del teléfono y requiere que retrase la activación de la pantalla de bloqueo cambiando una opción en la configuración de seguridad. Greenify también recibirá eventos de tipo Anuncio o Estado de notificación cambiado, este último que no es necesario en dispositivos Android 5.0+ gracias a la función Acceso a notificaciones. Sin embargo, seguirá recibiendo estos eventos independientemente de ese hecho. Greenify no debería causar muchos gastos generales por sí solo, pero la posibilidad persiste.
Lanzador Nova
Nova Launcher, probablemente la aplicación de inicio de terceros más popular del mercado, es un excelente ejemplo de una aplicación que utiliza un servicio de accesibilidad con una sobrecarga mínima o nula. La única razón de la existencia del Servicio es ayudar a ciertos dispositivos a realizar gestos.
"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro /> Como puede ver, no hay ningún evento de accesibilidad definido en el archivo XML. Todo lo que se menciona es el nombre de un paquete: Nova Launcher. Lo que sucede aquí es una solución para ciertos dispositivos para los cuales los gestos de Nova Launcher no funcionan. Este servicio proporcionará a Nova Launcher todos los eventos de accesibilidad iniciados desde sólo dentro de Nova Launcher. Suena extraño, pero aparentemente es una forma de arreglar los gestos de la pantalla de inicio de Nova si su dispositivo no funciona con ellos. Dado que esto sólo solicita Eventos de Nova, el Servicio supone muy pocos gastos generales.
Ultimo pase
Finalmente, quizás el servicio de accesibilidad más infame y que causa retrasos (probablemente debido a su inmensa popularidad): LastPass. El problema del retraso dentro de LastPass es tan notable que la empresa tiene un oficial Página de preguntas frecuentes que describe el problema. Como indican las preguntas frecuentes, no hay nada que pueda hacer con respecto al retraso excepto desactivar el Servicio. ¿Por qué el servicio de LastPass parece tan atroz en lo que respecta al retraso? Echemos un vistazo a los atributos del Servicio.
"@string/accessibility_service_description"
android: accessibilityEventTypes="typeViewFocused|typeWindowContentChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="200"
android: accessibilityFlags="flagReportViewIds"
android: canRetrieveWindowContent="true"
android: canRequestEnhancedWebAccessibility="true"
xmlns: andro /> La verdad es que no hay nada fuera de lo común con el servicio de LastPass. Solo solicita dos tipos de eventos para monitorear: TYPE_VIEW_FOCUSED y TYPE_WINDOW_CONTENT_CHANGED. Lo hace porque necesita saber cuándo el contenido de una aplicación/página web cambió/se enfoca, y luego recupera el contenido de la ventana actual para buscar los campos de entrada de contraseña. Pero dado que el servicio hace esto constantemente en dos eventos de accesibilidad que se activan con mucha frecuencia, se produce un retraso. Ésa es la desafortunada verdad.
Viviendo con el retraso
Cuando leímos por primera vez que Google estaba cerrando informes de errores sobre el retraso en la accesibilidad porque la función estaba "funcionando según lo previsto", estábamos tan perplejos y molestos como muchos de ustedes. Pero en lugar de aceptar la explicación al pie de la letra, decidimos investigar el asunto nosotros mismos para determinar la verdad. Entonces, cuando el Googler en la página del informe de errores dijo esto:
Hola, este problema persiste en las versiones de Android. Además, siempre habrá un retraso adicional cuando se habilita un servicio de accesibilidad. Esto se debe a que el dispositivo, además de la interfaz de usuario estándar, proporciona mucha información a los servicios de accesibilidad para que puedan brindar una experiencia de usuario alternativa a esos usuarios.
Hemos llegado a entender por qué esto es comportamiento previsto. Las aplicaciones que utilizan los Servicios de Accesibilidad de una manera no prevista por Google siempre incurrirán en una sobrecarga de rendimiento; este costo es simplemente necesario para proporcionar Servicios con la gran cantidad de información que la Accesibilidad de Android genera en segundo plano. El retraso de Android con los Servicios de Accesibilidad es no es un error, sino una característica. Una característica con la que tendremos que vivir a menos que se modifique todo el sistema, y no puedo imaginar cómo se haría eso para acomodar tantos conjuntos de características diferentes de tantas aplicaciones diferentes.
Como mínimo, los desarrolladores de LastPass no se tomarían esto de brazos cruzados. Sus desarrolladores han trabajado con los desarrolladores de Chromium para optimizar el soporte de accesibilidad, tal vez habilitando la compatibilidad con LastPass mediante el uso de API en lugar de habilitar un Servicio de Accesibilidad. Optimizar los gastos generales incurridos por los Servicios de Accesibilidad es una posibilidad, pero como muchos desarrolladores han señalado implícitamente en en los foros de Chromium, es simplemente una curita que no resolverá el hecho de que los usos no deseados de los Servicios de Accesibilidad pueden resultar en retraso.
¡Un agradecimiento especial al desarrollador de AutoInput, joaomgcd, por responder muchas de mis preguntas sobre Accesibilidad!