Se știe că funcția de accesibilitate a Android cauzează întârziere în interfața de utilizare. Este o eroare sau este o caracteristică? De ce apare? Noi, cei de la XDA, investigăm cauza principală.
Frumusețea Androidului constă în numeroasele moduri diferite prin care aplicațiile terțe pot interacționa cu sistemul. Aplicații de gestionare a parolelor, cum ar fi LastPass oferă posibilitatea de a furniza automat date relevante privind numele de utilizator/parola în aproape orice ecran de conectare. Asistent text vă permite să vă scurtați semnificativ timpul de a trimite mesaje mesaje prietenilor, permițându-vă să creați macrocomenzi de extindere a textului. Clipboard nativ reduce problemele legate de comutarea frecventă între aplicații pentru a copia cantități mari de text, permițându-vă să atingeți de două ori orice câmp de introducere pentru a afișa un clipboard. Cine poate uita Greenify, poate cea mai recomandată aplicație numărul 1 de către entuziaști, care ține sub control aplicațiile de fundal necinstite și poate astfel spori durata de viață a bateriei? În cele din urmă, deși mai puțin familiarizat cu majoritatea utilizatorilor, există
Intrare automată - un plug-in Tasker conceput pentru a automatiza atingerile pe ecran, introducerea textului, gesturile de glisare și multe altele. Toate aceste aplicații servesc cazuri de utilizare foarte diferite, dar fiecare dintre aceste aplicații se bazează pe o parte foarte greșit înțeleasă a funcționalității de bază Android: Accesibilitate.Pentru utilizatorul obișnuit de Android, ar putea părea ciudat că multe dintre aceste caracteristici uimitoare utilizate de aplicația dvs. preferată sunt controlate de o setare sub accesibilitate submeniu. Realizarea unei aplicații accesibil de obicei, se presupune că o aplicație Android este utilizabilă de către o persoană cu dizabilități. Deci, de ce în lume LastPass, Clipboard nativ, Text Aide, Greenify sau AutoInput au un accesibilitate serviciu? În plus, de ce se pare că activarea unui serviciu de accesibilitate cauza atât de mult UI lag? Nu pare să conteze pe ce versiune de Android folosiți - indiferent dacă este Android 5.0 Lollipop sau Android 7.0 Nougat - deoarece decalajul cauzat de anumite servicii de accesibilitate vă poate afecta experiența. O soluție simplă la această problemă este să dezactivați doar serviciile de accesibilitate pe care este posibil să le fi activat - dar, făcând acest lucru, pierdem atât de multe funcționalități utile. O altă soluție este de a solicita Google să „remedieze” decalajul de accesibilitate al Android, dar Google susține că Accesibilitatea Android este funcționează conform intenției. Am vorbit cu câțiva dezvoltatori familiarizați cu serviciile de accesibilitate și am cercetat cum funcționează funcționalitatea și suntem aici pentru a testa această afirmație: este întârzierea de accesibilitate a Android o eroare sau este o caracteristică?
Înțelegerea accesibilității Android
După cum vă puteți imagina după nume, Accesibilitatea este destinată dezvoltatorilor pentru a oferi funcționalități suplimentare oricăror utilizatori cu dizabilități. Într-adevăr, o privire rapidă asupra pagini de documentație oficială pentru Accesibilitate dezvăluie că Google are o viziune destul de restrânsă asupra tipurilor de servicii care ar trebui furnizate de Serviciile de accesibilitate.
Mulți utilizatori Android au abilități diferite care le impun să interacționeze cu dispozitivele lor Android în moduri diferite. Acestea includ utilizatorii care au limitări vizuale, fizice sau legate de vârstă care îi împiedică să vadă pe deplin sau folosind un ecran tactil și utilizatorii cu pierdere de auz care ar putea să nu poată percepe informații și alerte sonore.
Android oferă funcții și servicii de accesibilitate pentru a-i ajuta pe acești utilizatori să navigheze mai mult pe dispozitivele lor cu ușurință, inclusiv text-to-speech, feedback haptic, navigare prin gesturi, trackball și direcțional-pad navigare.
de la Google Răspunde, care vine preinstalat pe fiecare telefon Android, este un exemplu grozav al cum ar trebui să fie serviciul de accesibilitate „tipic”. Acces vocal duce accesibilitatea cu un pas mai departe și permite controlul aproape complet al telefonului folosind doar vocea. Dar faptul că Google a intenționat ca serviciile de accesibilitate să fie utilizate în acest mod nu împiedică dezvoltatorii să le implementeze în orice mod doresc - și exact asta au dezvoltatorii Terminat. Este tocmai din cauza modului în care funcționează Accesibilitatea care face caracteristica incredibil de util utilizatorilor cu sau fără dizabilități.
Pentru a simplifica puțin lucrurile, iată o descriere de bază a modului în care funcționează accesibilitatea Android. Un dezvoltator creează un Serviciul de accesibilitate care subscrie la diverse Evenimente de accesibilitate care sunt trimise de sistem către Serviciu în funcție de îndeplinirea sau nu a anumitor criterii. Când toate Serviciile sunt dezactivate în Setări --> Accesibilitate, Android nu colectează și nu trimite niciun eveniment de accesibilitate. Dar când utilizatorul începe să activeze Serviciile de accesibilitate, Android va începe să monitorizeze și să colecteze numai acele Evenimente de accesibilitate pe care le solicită Serviciul de accesibilitate. De exemplu, un serviciu de accesibilitate care se abona la Evenimentul de accesibilitate TYPE_WINDOW_CONTENT_CHANGED va fi notificat de către sistem de fiecare dată că are loc o modificare în fereastra curentă. Un alt eveniment de accesibilitate sunat TYPE_VIEW_CLICKED se stinge de fiecare dată utilizatorul face clic pe un buton de un fel.
Demonstrație de accesibilitate Android. În acest videoclip, am activat aplicația Tasker a monitoriza pentru modificări ale titlului ferestrei. Acest lucru necesită activarea Serviciului de accesibilitate Tasker. Puteți replica acest lucru creând un profil nou în Tasker cu contextul „Eveniment” setat la „Set de variabile” și alegând %WIN ca variabilă de monitorizat. În total, acest videoclip de aproximativ 1 minut a fost capturat 107 modificări în fereastra curentă.
Aceste tipuri de evenimente de accesibilitate apar cu mare frecvență în timpul interacțiunii normale cu utilizatorul. Deci imaginați-vă ce se întâmplă când un utilizator activează mai multe servicii de accesibilitate care solicită ca evenimentele de accesibilitate de înaltă frecvență să fie declanșate. Asta e corect - lag. Pentru a atenua acest lucru, dezvoltatorii pot defini mai restrâns ce tipuri de evenimente de accesibilitate au Serviciul ar trebui să reacționeze și în ce context, cum ar fi capacitatea de a limita Serviciul doar să reacționeze când în anumite aplicații sau pentru a limita perioada de votare între Evenimente. Dar, în afară de asta, cantitatea de cheltuieli generale generate de un serviciu de accesibilitate depinde în mare măsură de ce fel de evenimente de accesibilitate se abona la. În esență, nu orice serviciu de accesibilitate va cauza decalaj. Un singur serviciu de accesibilitate care necesită un eveniment de înaltă frecvență poate cauza decalaj, mai ales dacă Serviciul menționat este cuplat cu un alt Serviciu care necesită un alt Eveniment de înaltă frecvență monitorizat.
Pătrundeți adânc în accesibilitate cu demontare APK
După cum ați putea observa din videoclipul postat mai sus, un serviciu de accesibilitate care monitorizează modificările în conținutul ferestrei poate duce la schimbări destul de vizibile în performanța interfeței de utilizare din cauza cantității mari de evenimente de accesibilitate capturate declanșate de sistem. Cu toate acestea, este destul de dificil să determinați cu exactitate câtă suprasarcină este cauzată de un anumit serviciu de accesibilitate. Monitorizarea LogCat nu vă va duce nicăieri, deoarece evenimentele de accesibilitate sunt tipărite pe LogCat numai dacă dezvoltatorul Serviciului de accesibilitate alege să facă acest lucru. Din fericire, tatăl tuturor serviciilor de accesibilitate Android, Intrare automată, face exact asta. Și ieșirea LogCat este exact la fel de dezordonată pe cât v-ați imagina.
Intrarea automată nu ne ascunde adevărul. Suplimentul cauzat de aplicație poate fi destul de enorm, în funcție de evenimentele pe care le monitorizați. Dar această suprasarcină este necesară pentru ca aplicația să funcționeze. Pentru ca AutoInput să intercepteze fiecare apăsare de tastă, fiecare gest de pe ecran, fiecare actualizare a UI și fiecare apăsare de buton, are nevoie pentru a monitoriza evenimentele de accesibilitate respective. Fără aceste evenimente, AutoInput nu se poate conecta în sistem și nu poate oferi automatizarea aproape nelimitată a interfeței de utilizator pe care o permite în prezent. Astfel, toate funcțiile AutoInput au un sens perfect în contextul Accesibilității. Dar pentru alte aplicații, trebuie să ne uităm puțin mai profund pentru a înțelege cum sunt gestionate serviciile lor de accesibilitate.
Un serviciu de accesibilitate atribute sunt definite într-o fișier cu resurse XML în cadrul APK-ului. Prin urmare, putem efectua o Demontarea APK-ului pe o aplicație cu un serviciu de accesibilitate pentru a afla atributele serviciului. Fiecare aplicație funcționează diferit, așa că voi încerca să explic modul în care atributele serviciului lor se raportează la funcția specifică pe care o îndeplinește.
Clipboard nativ
Clipboardul nativ este alegerea mea când vine vorba de manageri de clipboard. Dacă sunteți în căutarea unui manager de clipboard extrem de personalizabil, Native Clipboard este o aplicație destul de grozavă. Are chiar și o componentă Xposed Module pentru a vă permite să apăsați lung pe butonul „Lipire” pentru a afișa managerul clipboard-ului! Din păcate, dacă nu aveți acces la Xposed Framework (cum ar fi fiecare utilizator de pe Nougat), atunci va trebui să vă rezolvați pentru activarea Serviciului de accesibilitate, care vă va permite să atingeți de două ori orice intrare de text pentru a afișa clipboard-ul administrator. Iată ce presupune asta.
"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro /> Serviciul de accesibilitate al Native Clipboard solicită declanșarea unui eveniment de accesibilitate de fiecare dată când se face clic pe o vizualizare, se face clic lung, se focalizează sau dacă există o schimbare în starea ferestrei. Fără a avea acces la codul sursă, nu pot spune exact cum funcționează Native Clipboard, dar este probabil ca Native Clipboard așteaptă ca starea fereastră să indice faptul că tastatura soft este deschisă în prezent și apoi monitorizează atingerile pe intrare camp. Aplicația are o perioadă de sondare de 100 ms, așa că este cu siguranță suficient de rapid pentru a reacționa practic imediat la modificările vizibilității tastaturii soft, precum și la atingerile duble. Acest lucru ar putea duce la o suprasolicitare a interfeței de utilizare ori de câte ori utilizatorul folosește tastatura soft pentru a introduce orice text, ceea ce poate duce la decalaj.
Greenify
Următorul este economizorul de baterie preferat al tuturor, Greenify. Greenify folosește Evenimente de accesibilitate pentru a-și alimenta funcțiile 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 /> Utilizează modificările din starea ferestrei pentru a determina când ecranul telefonului s-a oprit și necesită amânarea activării ecranului de blocare prin modificarea unei opțiuni din setările de securitate. Greenify va primi, de asemenea, Evenimente de tip Anunț sau Notificare State changed, aceasta din urmă care nu este necesară pe dispozitivele Android 5.0+ datorită funcției Notification Access. Totuși, va primi în continuare aceste evenimente indiferent de acest fapt. Greenify nu ar trebui să cauzeze multe cheltuieli de sine stătătoare, dar posibilitatea rămâne.
Nova Launcher
Probabil cea mai populară aplicație de lansare terță parte de pe piață, Nova Launcher este un exemplu excelent de aplicație care folosește un serviciu de accesibilitate cu un cost minim sau deloc. Singurul motiv pentru existența Serviciului este acela de a ajuta anumite dispozitive să efectueze gesturi.
"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro /> După cum puteți vedea, nu există niciun eveniment de accesibilitate definit în fișierul XML. Tot ceea ce este menționat este numele unui pachet - Nova Launcher. Ceea ce se întâmplă aici este o soluție pentru anumite dispozitive pentru care gesturile lui Nova Launcher nu funcționează. Acest serviciu va oferi Nova Launcher toate evenimentele de accesibilitate de la care au fost lansate numai în Nova Launcher. Sună ciudat, dar se pare că este o modalitate de a remedia gesturile de pe ecranul de pornire ale lui Nova dacă dispozitivul tău nu funcționează cu ele. Deoarece acest lucru solicită doar Evenimente de la Nova însăși, Serviciul prezintă foarte puține cheltuieli.
LastPass
În cele din urmă, poate cel mai infam serviciu de accesibilitate care provoacă întârziere (probabil datorită popularității sale imense) - LastPass. Problema decalajului în LastPass este atât de vizibil că firma are un oficial Pagina de întrebări frecvente care descrie problema. După cum se arată în Întrebările frecvente, nu puteți face nimic în privința decalajului, cu excepția dezactivarii serviciului. De ce serviciul LastPass pare atât de flagrant când vine vorba de decalaj? Să aruncăm o privire la atributele Serviciului.
"@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 /> Adevărul este că nu există nimic ieșit din comun cu serviciul LastPass. Solicită doar două tipuri de evenimente de monitorizat - TYPE_VIEW_FOCUSED și TYPE_WINDOW_CONTENT_CHANGED. Face acest lucru deoarece trebuie să știe când conținutul unei aplicații/pagini web s-a schimbat/intră în atenție și apoi preia conținutul curent al ferestrei pentru a căuta orice câmpuri de introducere a parolei. Dar, deoarece serviciul face acest lucru în mod constant la două evenimente de accesibilitate care declanșează extrem de frecvent, are ca rezultat întârziere. Acesta este adevărul nefericit.
Trăind cu Lag
Când am citit prima dată că Google închidea rapoarte de eroare despre întârzierea accesibilității, deoarece funcția „funcționează conform intenției”, am fost la fel de perplexi și supărați ca mulți dintre voi. Dar, mai degrabă decât să acceptăm explicația la valoarea nominală, am decis să analizăm singuri problema pentru a stabili adevărul. Deci, când Googler-ul de pe pagina de raportare a erorilor a spus asta:
Bună, această problemă este persistentă pentru versiunile Android. De asemenea, va exista întotdeauna o întârziere suplimentară atunci când este activat un serviciu de accesibilitate. Acest lucru se datorează faptului că dispozitivul, pe lângă interfața de utilizare standard, oferă o mulțime de informații serviciilor de accesibilitate, astfel încât acestea să poată oferi acelor utilizatori o experiență alternativă de utilizare.
Am ajuns să înțelegem De ce aceasta este comportamentul intenționat. Aplicațiile care utilizează Serviciile de accesibilitate într-un mod neintenționat de Google vor suporta întotdeauna o suprasolicitare de performanță; acest cost este pur și simplu necesar pentru a oferi Serviciilor multitudinea de informații pe care Accesibilitatea Android le declanșează în fundal. Decalajul Android cu serviciile de accesibilitate este nu o eroare, ci o caracteristică. O caracteristică cu care va trebui să trăim cu excepția cazului în care întregul sistem este reproiectat și nu-mi pot imagina cum s-ar face asta pentru a găzdui atât de multe seturi de caracteristici diferite din atât de multe aplicații diferite.
Cel puțin, dezvoltatorii LastPass nu ar accepta această ședință. Dezvoltatorii lor au lucrat cu dezvoltatorii Chromium pentru optimizați suportul pentru accesibilitate, poate prin activarea suportului LastPass prin utilizarea API-urilor mai degrabă decât activarea unui serviciu de accesibilitate. Optimizarea în jurul cheltuielilor generale suportate de serviciile de accesibilitate este o posibilitate, dar după cum mulți dezvoltatori au observat implicit pe pe forumurile Chromium, este pur și simplu un bandaid care nu va rezolva faptul că utilizările neintenționate ale Serviciilor de accesibilitate pot duce la lag.
Mulțumiri speciale dezvoltatorului AutoInput, joaomgcd, pentru că a răspuns la multe dintre întrebările mele referitoare la Accesibilitate!