È noto che la funzionalità di accessibilità di Android causa un ritardo dell'interfaccia utente. È un bug o è una funzionalità? Perché si verifica? Noi di XDA indaghiamo sulla causa principale.
La bellezza di Android risiede nei molti modi diversi in cui le applicazioni di terze parti possono interagire con il sistema. App di gestione password come LastPass fornire la possibilità di fornire automaticamente i dati relativi a nome utente/password pertinenti a quasi tutte le schermate di accesso. Aiutante di testo ti consente di ridurre significativamente il tempo che trascorri a inviare messaggi ai tuoi amici consentendoti di creare macro di espansione del testo. Appunti nativi riduce il fastidio legato al passaggio frequente da un'app all'altra per copiare grandi quantità di testo consentendo di toccare due volte qualsiasi campo di input per visualizzare gli appunti. Chi può dimenticare Greenify, forse l'app più consigliata dagli appassionati, che tiene sotto controllo le app in background non autorizzate e può quindi aumentare la durata della batteria? Infine, anche se meno familiare alla maggior parte degli utenti, c'è
All'utente Android medio potrebbe sembrare strano che molte di queste straordinarie funzionalità utilizzate dalla tua app preferita siano controllate da un'impostazione sotto accessibilità sottomenu. Realizzare un'app accessibile in genere si suppone che significhi che un'app Android è utilizzabile da una persona con disabilità. Allora perché mai LastPass, Native Clipboard, Text Aide, Greenify o AutoInput hanno un file accessibilità servizio? Inoltre, perché sembra che l'abilitazione di un servizio di accessibilità lo faccia? causare così tanto ritardo nell'interfaccia utente? Non sembra importare quale versione di Android utilizzi, indipendentemente dal fatto che sia Android 5.0 Lecca-lecca O Android 7.0 Torrone - perché il ritardo causato da alcuni servizi di accessibilità può influenzare la tua esperienza. Una soluzione semplice a questo problema è semplicemente disabilitare i servizi di accessibilità che potresti aver abilitato, ma così facendo perdiamo molte funzionalità utili. Un'altra soluzione è presentare una petizione a Google per "correggere" il ritardo di accessibilità di Android, ma Google afferma che l'accessibilità di Android lo è funzionando come previsto. Abbiamo parlato con alcuni sviluppatori che hanno molta familiarità con i servizi di accessibilità e abbiamo studiato come funziona la funzionalità, e siamo qui per testare tale affermazione: il ritardo nell'accessibilità di Android è un bug o è una funzionalità?
Comprendere l'accessibilità Android
Come puoi immaginare dal nome, l'accessibilità è destinata principalmente agli sviluppatori per fornire funzionalità aggiuntive a tutti gli utenti con disabilità. In effetti, una rapida occhiata al pagine di documentazione ufficiale per l'accessibilità rivela che Google ha una visione piuttosto ristretta su quali tipi di servizi dovrebbero essere forniti dai servizi di accessibilità.
Molti utenti Android hanno abilità diverse che richiedono loro di interagire con i propri dispositivi Android in modi diversi. Questi includono utenti che hanno limitazioni visive, fisiche o legate all'età che impediscono loro di vedere completamente o utilizzando un touchscreen e utenti con perdita dell'udito che potrebbero non essere in grado di percepire informazioni e avvisi sonori.
Android fornisce funzionalità e servizi di accessibilità per aiutare questi utenti a navigare meglio sui propri dispositivi facilmente, inclusi sintesi vocale, feedback tattile, navigazione gestuale, trackball e pad direzionale navigazione.
Quello di Google Rispondere, preinstallato su ogni telefono Android, è un ottimo esempio di come dovrebbe essere il "tipico" servizio di accessibilità. Accesso vocale porta l'accessibilità un ulteriore passo avanti e consente il controllo quasi completo del telefono utilizzando solo la voce. Ma il fatto che Google abbia previsto che i servizi di accessibilità venissero utilizzati in questo modo non impedisce agli sviluppatori di implementarli nel modo che preferiscono - e questo è esattamente ciò che hanno gli sviluppatori Fatto. È proprio il modo in cui funziona l'Accessibilità che rende questa funzionalità incredibilmente utile per gli utenti con o senza disabilità.
Per semplificare un po' le cose, ecco un riassunto di base di come funziona l'accessibilità di Android. Uno sviluppatore crea un file Servizio di accessibilità che si abbona a vari Eventi sull'accessibilità che vengono inviati dal sistema al Servizio a seconda che siano soddisfatti o meno determinati criteri. Quando tutti i servizi sono disabilitati in Impostazioni --> Accessibilità, Android non raccoglie né invia alcun evento di accessibilità. Ma quando l'utente inizia ad abilitare i servizi di accessibilità, Android inizierà a monitorare e raccogliere solo gli eventi di accessibilità richiesti dal servizio di accessibilità. Ad esempio, un servizio di accessibilità che si iscrive all'evento di accessibilità TYPE_WINDOW_CONTENT_CHANGED verrà avvisato dal sistema ogni singola volta che si verifica un cambiamento nella finestra corrente. Chiamato un altro evento sull'accessibilità TYPE_VIEW_CLICKED si spegne ogni singola volta l'utente fa clic su un pulsante di qualche tipo.
Dimostrazione di accessibilità Android. In questo video ho abilitato l'app Tasker per monitorare modifiche nel titolo della finestra. Ciò richiede l'abilitazione del servizio di accessibilità di Tasker. Puoi replicarlo creando un nuovo profilo in Tasker con il contesto "Evento" impostato su "Insieme variabili" e scegliendo %WIN come variabile da monitorare. In totale, questo video catturato è di circa 1 minuto 107 modifiche nella finestra corrente.
Questi tipi di eventi di accessibilità si verificano con grande frequenza durante la normale interazione dell'utente. Quindi immagina cosa succede quando un utente abilita più servizi di accessibilità che richiedono l'attivazione di eventi di accessibilità ad alta frequenza. Giusto - ritardo. Per mitigare questo problema, gli sviluppatori possono definire in modo più restrittivo quali tipi di eventi di accessibilità utilizzare Il Servizio dovrebbe reagire e in quale contesto, ad esempio la capacità di limitare il Servizio a reagire solo quando dentro determinate app o per limitare il periodo di votazione tra gli eventi. Ma a parte questo, l'ammontare del sovraccarico generato da un servizio di accessibilità dipende principalmente da che tipo di eventi di accessibilità a cui si abbona. In sostanza, non tutti i servizi di accessibilità causeranno ritardi. Un singolo servizio di accessibilità che richiede un evento ad alta frequenza può causare ritardi, soprattutto se detto Servizio è accoppiato con un altro Servizio che richiede la realizzazione di un altro Evento ad alta frequenza monitorato.
Approfondimento sull'accessibilità con gli smontaggi APK
Come puoi vedere dal video pubblicato sopra, un servizio di accessibilità che monitora le modifiche nel contenuto della finestra può farlo comportano cambiamenti abbastanza evidenti nelle prestazioni dell'interfaccia utente a causa dell'enorme quantità di eventi di accessibilità acquisiti e attivati da sistema. Tuttavia è piuttosto difficile determinare esattamente il sovraccarico causato da un particolare servizio di accessibilità. Il monitoraggio di LogCat generalmente non ti porterà da nessuna parte, poiché gli eventi di accessibilità vengono stampati su LogCat solo se lo sviluppatore del servizio di accessibilità sceglie di farlo. Per fortuna, il padre di tutti i servizi di accessibilità Android, Ingresso automatico, fa esattamente questo. E l'output di LogCat è esattamente disordinato come potresti immaginare.
AutoInput non ci nasconde la verità. Il sovraccarico causato dall'app può essere enorme a seconda degli eventi monitorati. Ma questo sovraccarico è necessario affinché l'app funzioni. Affinché AutoInput possa intercettare ogni pressione di un tasto, ogni gesto sullo schermo, ogni aggiornamento dell'interfaccia utente e ogni pressione di un pulsante, esigenze per monitorare i rispettivi Eventi di Accessibilità. Senza questi eventi, AutoInput non può collegarsi al sistema e fornire l'automazione dell'interfaccia utente quasi illimitata attualmente consentita. Pertanto, tutte le funzioni di AutoInput hanno perfettamente senso nel contesto dell'accessibilità. Ma per altre app, dobbiamo guardare un po' più in profondità per capire come vengono gestiti i loro servizi di accessibilità.
Un servizio di accessibilità attributi sono definiti in un File di risorse XML all'interno dell'APK. Pertanto, possiamo eseguire un Smontaggio dell'APK su un'app con un servizio di accessibilità per individuare gli attributi del servizio. Ogni app funziona in modo diverso, quindi cercherò di spiegare in che modo gli attributi del servizio si riferiscono alla funzione specifica che svolge.
Appunti nativi
Gli Appunti nativi sono il mio punto di riferimento quando si tratta di gestori di appunti. Se stai cercando un gestore di appunti altamente personalizzabile, Native Clipboard è un'app davvero fantastica. Ha anche un componente Xposed Module che ti consente di premere a lungo il pulsante "Incolla" per visualizzare il gestore degli appunti! Sfortunatamente, se non hai accesso a Xposed Framework (come tutti gli utenti di Nougat), dovrai accontentarti per abilitare il servizio di accessibilità che ti consentirà di toccare due volte qualsiasi input di testo per visualizzare gli appunti manager. Ecco cosa comporta.
"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro /> Il servizio di accessibilità degli Appunti nativi richiede l'attivazione di un evento di accessibilità ogni volta che si fa clic su una vista, si fa clic a lungo, si focalizza o se si verifica un cambiamento nello stato della finestra. Senza avere accesso al codice sorgente, non posso dire esattamente come funziona Native Clipboard, ma è probabile che Native Clipboard attende che lo stato Finestra indichi che la tastiera virtuale è attualmente aperta, quindi monitora i tocchi sull'input campo. L'app ha un periodo di polling di 100 ms, quindi è abbastanza veloce da reagire praticamente immediatamente ai cambiamenti nella visibilità della tastiera virtuale e ai doppi tocchi. Ciò potrebbe comportare un sovraccarico dell'interfaccia utente ogni volta che l'utente utilizza la tastiera virtuale per digitare testo, con conseguente potenziale ritardo.
Greenify
Il prossimo è il risparmiatore di batteria preferito da tutti, Greenify. Greenify utilizza gli eventi di accessibilità per alimentare le sue funzioni non root.
"@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 /> Utilizza le modifiche allo stato della finestra per determinare quando lo schermo del telefono è spento e richiede di ritardare l'attivazione della schermata di blocco modificando un'opzione nelle impostazioni di sicurezza. Greenify riceverà anche eventi di tipo Annuncio o Stato di notifica modificato, quest'ultimo non necessario sui dispositivi Android 5.0+ grazie alla funzione Accesso alle notifiche. Riceverà comunque questi eventi indipendentemente da ciò. Greenify non dovrebbe causare grandi spese generali di per sé, ma la possibilità rimane.
Lanciatore Nova
Probabilmente l'app di avvio di terze parti più popolare sul mercato, Nova Launcher è un eccellente esempio di app che utilizza un servizio di accessibilità con un sovraccarico minimo o nullo. L'unico motivo dell'esistenza del Servizio è aiutare alcuni dispositivi nell'esecuzione dei gesti.
"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro /> Come puoi vedere, non esiste alcun evento di accessibilità definito nel file XML. Tutto ciò che viene menzionato è il nome di un pacchetto: Nova Launcher. Ciò che accade qui è una soluzione alternativa per alcuni dispositivi per i quali i gesti di Nova Launcher non funzionano. Questo servizio fornirà a Nova Launcher tutti gli eventi di accessibilità attivati da solo all'interno di Nova Launcher. Sembra strano, ma a quanto pare è un modo per correggere i gesti della schermata iniziale di Nova se il tuo dispositivo non funziona con loro. Poiché questo richiede solo eventi da Nova stessa, il servizio comporta un sovraccarico minimo.
LastPass
Infine, forse il servizio di accessibilità più famigerato che causa ritardi (probabilmente a causa della sua immensa popolarità): LastPass. Il problema del ritardo all'interno di LastPass è così evidente che la società ha un funzionario Pagina delle domande frequenti che descrive il problema. Come affermano le FAQ, non puoi fare nulla per risolvere il ritardo se non disabilitare il servizio. Perché il servizio LastPass sembra così pessimo in termini di ritardo? Diamo un'occhiata agli attributi del servizio.
"@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 verità è che non c'è niente di veramente straordinario nel servizio LastPass. Richiede solo due tipi di eventi da monitorare: TYPE_VIEW_FOCUSED e TYPE_WINDOW_CONTENT_CHANGED. Lo fa perché ha bisogno di sapere quando il contenuto di un'app/pagina web è cambiato/viene messo a fuoco e quindi recupera il contenuto della finestra corrente per cercare eventuali campi di immissione della password. Ma poiché il servizio lo fa costantemente su due eventi di accessibilità attivati con estrema frequenza, si verifica un ritardo. Questa è la triste verità.
Convivere con il ritardo
Quando abbiamo letto per la prima volta che Google stava chiudendo le segnalazioni di bug relative al ritardo nell'accessibilità perché la funzione "funzionava come previsto", eravamo perplessi e turbati quanto molti di voi. Ma invece di accettare la spiegazione per oro colato, abbiamo deciso di esaminare noi stessi la questione per determinare la verità. Quindi, quando il Googler nella pagina di segnalazione del bug ha detto questo:
Salve, questo problema persiste nelle versioni Android. Inoltre, si verificherà sempre un ritardo aggiuntivo quando un servizio di accessibilità è abilitato. Questo perché il dispositivo, oltre all'interfaccia utente standard, fornisce molte informazioni ai servizi di accessibilità in modo che possano offrire a tali utenti un'esperienza utente alternativa.
Siamo arrivati a capire Perché questo è comportamento previsto. Le app che utilizzano i servizi di accessibilità in un modo non previsto da Google incorreranno sempre in un sovraccarico delle prestazioni; questo costo è semplicemente necessario per fornire ai Servizi la pletora di informazioni che l'Accessibilità Android attiva in background. Il ritardo di Android con i servizi di accessibilità è non un bug, ma una funzionalità. Una funzionalità con cui dovremo convivere a meno che l'intero sistema non venga rielaborato, e non riesco a immaginare come ciò potrebbe essere fatto per ospitare così tanti set di funzionalità diversi da così tante app diverse.
Per lo meno, gli sviluppatori di LastPass non lo prenderebbero con calma. I loro sviluppatori hanno collaborato con gli sviluppatori di Chromium ottimizzare il supporto per l'accessibilità, magari abilitando il supporto LastPass attraverso l'uso delle API anziché abilitare un servizio di accessibilità. L'ottimizzazione del sovraccarico sostenuto dai servizi di accessibilità è una possibilità, ma come molti sviluppatori hanno implicitamente notato nei forum di Chromium, si tratta semplicemente di un cerotto che non risolverà il fatto che l'uso involontario dei servizi di accessibilità potrebbe comportare ritardo.
Un ringraziamento speciale allo sviluppatore di AutoInput, joaomgcd, per aver risposto a molte delle mie domande sull'accessibilità!