Androidi juurdepääsetavuse funktsioon põhjustab teadaolevalt kasutajaliidese viivitust. Kas see on viga või on see funktsioon? Miks see tekib? Meie, XDA, uurime algpõhjust.
Androidi ilu seisneb paljudes erinevates viisides, kuidas kolmandate osapoolte rakendused saavad süsteemiga suhelda. Paroolihalduri rakendused nagu LastPass pakub võimalust automaatselt edastada asjakohaseid kasutajanime/parooli andmeid peaaegu igale sisselogimiskuvale. Tekstiabi võimaldab teil oluliselt lühendada sõpradele sõnumite saatmise aega, võimaldades teil luua tekstilaiendusmakrosid. Algne lõikelaud vähendab raskusi, mis on seotud sagedase rakenduste vahel vahetamisega suurte tekstihulkade kopeerimiseks, võimaldades teil lõikelaua kuvamiseks topeltpuudutada mis tahes sisestusvälja. Kes suudab unustada Rohendada, mis võib-olla on entusiastide poolt enim soovitatud rakendus nr 1, mis hoiab võltsitud taustarakendused kontrolli all ja võib seega pikendada aku kasutusaega? Lõpuks, kuigi enamiku kasutajate jaoks vähem tuttav, on olemas
Tavalisele Androidi kasutajale võib tunduda veider, et paljusid neist hämmastavatest funktsioonidest, mida teie lemmikrakendus kasutab, juhib seade ligipääsetavus alammenüü. Rakenduse tegemine ligipääsetav Tavaliselt peaks see tähendama, et Androidi rakendus on inimesele kasutatav puuetega. Miks siis maailmas on LastPassil, Native Clipboardil, Text Aide'il, Greenifyl või AutoInputil ligipääsetavus teenust? Lisaks, miks juurdepääsetavusteenuse lubamine näib olevat põhjustada nii palju kasutajaliidese viivitust? Tundub, et pole vahet, millist Androidi versiooni te kasutate – olgu see siis nii Android 5.0 Lollipop või Android 7.0 Nougat - kuna teatud juurdepääsetavuse teenuste põhjustatud viivitus võib teie kasutuskogemust mõjutada. Lihtne lahendus sellele probleemile on lihtsalt keelata juurdepääsetavuse teenused, mille olete võib-olla lubanud – kuid seda tehes kaotame nii palju kasulikke funktsioone. Teine lahendus on esitada Google'ile petitsioon Androidi juurdepääsetavuse viivituse parandamiseks, kuid Google väidab, et Androidi juurdepääsetavus on töötab nii nagu ette nähtud. Oleme rääkinud mõne arendajaga, kes on ligipääsetavuse teenustega põhjalikult tuttavad, ja uurinud, kuidas funktsionaalsus töötab, ning oleme siin, et seda väidet testida. kas Androidi juurdepääsetavuse viivitus on viga või on see funktsioon?
Androidi juurdepääsetavuse mõistmine
Nagu nime järgi võite ette kujutada, on juurdepääsetavus enamasti mõeldud arendajatele, et pakkuda puuetega kasutajatele lisafunktsioone. Tõepoolest, kiire pilk peale juurdepääsetavuse ametlikud dokumentatsioonilehed paljastab, et Google'il on üsna kitsas vaade selle kohta, milliseid teenuseid juurdepääsetavuse teenused peaksid pakkuma.
Paljudel Androidi kasutajatel on erinevad võimed, mis nõuavad neilt oma Android-seadmetega erineval viisil suhtlemist. Nende hulka kuuluvad kasutajad, kellel on visuaalsed, füüsilised või vanusega seotud piirangud, mis ei lase neil täielikult näha või puuteekraani kasutamine ja kuulmislangusega kasutajad, kes ei pruugi kuuldavat teavet ja hoiatusi tajuda.
Android pakub juurdepääsetavuse funktsioone ja teenuseid, mis aitavad neil kasutajatel oma seadmeid paremini navigeerida lihtne, sealhulgas tekst kõneks muutmine, haptiline tagasiside, liigutustega navigeerimine, juhtkuul ja suunanupp navigeerimine.
Google'i oma Tagasi rääkima, mis on eelinstallitud igasse Android-telefoni, on suurepärane näide sellest, milline peaks olema "tüüpiline" juurdepääsetavuse teenus. Hääljuurdepääs viib juurdepääsetavuse sammu edasi ja võimaldab oma telefoni peaaegu täielikult juhtida, kasutades ainult häält. Kuid asjaolu, et Google kavatses juurdepääsetavuse teenuseid sellisel viisil kasutada, ei takista arendajad ei saa neid rakendada mis tahes viisil – ja see on just see, mis arendajatel on tehtud. Just tänu sellele, kuidas juurdepääsetavus toimib, on see funktsioon tehtud uskumatult kasulik puuetega või puudega kasutajatele.
Asjade pisut lihtsustamiseks on siin Androidi juurdepääsetavuse põhiülevaade. Arendaja loob Juurdepääsetavusteenus mis tellib erinevaid Juurdepääsetavuse sündmused mis saadab süsteem Teenusele sõltuvalt sellest, kas teatud kriteeriumid on täidetud või mitte. Kui kõik teenused on jaotises Seaded --> Juurdepääsetavus keelatud, ei kogu ega saada Android juurdepääsetavuse sündmusi. Kuid kui kasutaja hakkab juurdepääsetavuse teenuseid lubama, hakkab Android jälgima ja koguma ainult need juurdepääsetavuse sündmused, mida juurdepääsetavuse teenus taotleb. Näiteks juurdepääsetavuse teenus, mis tellib juurdepääsetavuse sündmuse TYPE_WINDOW_CONTENT_CHANGED süsteem teavitab sellest iga kord et praeguses aknas toimub muutus. Teine juurdepääsetavuse üritus kutsus TYPE_VIEW_CLICKED süttib iga kord kasutaja klõpsab mingil nupul.
Androidi juurdepääsetavuse tutvustus. Selles videos olen rakenduse lubanud Tasker jälgida muudatused akna pealkirjas. See nõuab Taskeri juurdepääsetavuse teenuse lubamist. Saate seda korrata, luues Taskeris uue profiili, mille konteksti „Sündmus” väärtuseks on määratud „Muutujate komplekt” ja valides jälgitavaks muutujaks %WIN. Kokku jäädvustati see umbes 1-minutiline video 107 muudatust praeguses aknas.
Sellised juurdepääsetavuse sündmused toimuvad tavalise kasutaja suhtluse ajal sageli. Nii et kujutage ette, mis juhtub, kui kasutaja võimaldab mitut juurdepääsetavuse teenust mis nõuavad kõrgsageduslike juurdepääsetavuse sündmuste käivitamist. nii on - mahajäämus. Selle leevendamiseks saavad arendajad kitsamalt määratleda, milliseid juurdepääsetavuse sündmusi nad hõlmavad Teenus peaks reageerima ja millises kontekstis, näiteks võimalusega piirata teenust ainult reageerima kui sisse teatud rakendused või piirata valimisperiood Sündmuste vahel. Kuid peale selle sõltub juurdepääsetavuse teenuse tekitatud üldkulude summa peamiselt sellest milliseid juurdepääsetavuse sündmusi see tellib. Sisuliselt ei põhjusta iga juurdepääsetavuse teenus viivitust. Üksik juurdepääsetavusteenus, mis nõuab kõrgsageduslikku sündmust, võib põhjustada viivitust, eriti kui nimetatud teenus on ühendatud teise teenusega, mis nõuab teise kõrgsagedusliku sündmuse olemasolu jälgitakse.
Sukelduge APK Teardownsi abil juurdepääsetavusesse
Nagu ülalpool postitatud videost võis aru saada, võib juurdepääsetavuse teenus, mis jälgib akna sisu muutusi, seda teha põhjustab kasutajaliidese jõudluses üsna märgatavaid muutusi, kuna kasutaja käivitas tohutu hulga juurdepääsetavuse sündmusi. süsteem. Siiski on üsna raske täpselt kindlaks teha, kui palju üldkulusid konkreetne juurdepääsetavuse teenus põhjustab. LogCati jälgimine ei vii teid üldiselt kuhugi, kuna juurdepääsetavuse sündmused prinditakse LogCati ainult siis, kui juurdepääsetavuse teenuse arendaja seda teha otsustab. Õnneks on kõigi Androidi juurdepääsetavuse teenuste isa, Automaatne sisestus, teeb täpselt seda. Ja LogCati väljund on täpselt nii räpane, kui ette kujutate.
AutoInput ei varja meie eest tõde. Rakenduse põhjustatud üldkulud võivad olla üsna suured, sõltuvalt sellest, milliseid sündmusi jälgite. Kuid see üldkulu on rakenduse toimimiseks vajalik. Selleks, et automaatsisend peataks kinni iga klahvivajutuse, iga ekraaniliigutuse, iga kasutajaliidese värskenduse ja iga nupuvajutuse, vajadustele vastavate juurdepääsetavuse sündmuste jälgimiseks. Ilma nende sündmusteta ei saa AutoInput süsteemi külge haakida ja pakkuda peaaegu piiramatut kasutajaliidese automatiseerimist, mida see praegu võimaldab. Seega on juurdepääsetavuse kontekstis kõik automaatse sisendi funktsioonid täiesti mõistlikud. Kuid teiste rakenduste puhul peame veidi sügavamalt uurima, et mõista, kuidas nende juurdepääsetavuse teenuseid käsitletakse.
Juurdepääsetavuse teenus atribuudid on määratletud an XML-ressursifail APK-s. Seetõttu saame teostada an APK lammutamine hõlbustusteenusega rakenduses, et välja selgitada teenuse atribuudid. Iga rakendus toimib erinevalt, seega proovin selgitada, kuidas nende teenuse atribuudid on seotud konkreetse funktsiooniga, mida see täidab.
Algne lõikelaud
Lõikepuhvrihaldurite osas on minu jaoks omapärane lõikelaud. Kui otsite väga kohandatavat lõikelauahaldurit, on Native Clipboard päris suurepärane rakendus. Sellel on isegi komponent Xposed Module, mis võimaldab teil lõikepuhvrihalduri kuvamiseks pikalt vajutada nuppu Kleebi! Kahjuks, kui teil pole juurdepääsu Xposed Frameworkile (nagu kõik Nougati kasutajad), peate kahjuks leppima juurdepääsetavuse teenuse lubamiseks, mis võimaldab teil lõikepuhvri kuvamiseks topeltpuudutada mis tahes tekstisisendil juht. Siin on, mida see endaga kaasa toob.
"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro /> Natiivse lõikelaua juurdepääsetavuse teenus nõuab juurdepääsetavuse sündmuse käivitamist iga kord, kui vaatel klõpsatakse, kaua klõpsatakse, fokusseeritakse või kui akna olek muutub. Ilma lähtekoodile juurdepääsuta ei saa ma täpselt öelda, kuidas algne lõikelaud töötab, kuid on tõenäoline, et algne lõikelaud ootab, kuni akna olek näitab, et pehme klaviatuur on hetkel avatud ja jälgib seejärel sisendi puudutusi valdkonnas. Rakenduse küsitlusperiood on 100 ms, nii et see on kindlasti piisavalt kiire, et reageerida põhimõtteliselt kohe nii pehme klaviatuuri nähtavuse muutustele kui ka topeltpuudutustele. See võib põhjustada kasutajaliidese lisakulusid, kui kasutaja kasutab teksti tippimiseks pehmet klaviatuuri, mis võib põhjustada viivitust.
Rohendada
Järgmine on kõigi lemmik akusäästja Greenify. Greenify kasutab juurdepääsetavuse sündmusi oma mittejuurfunktsioonide käivitamiseks.
"@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 /> See kasutab akna oleku muudatusi, et teha kindlaks, millal telefoni ekraan on välja lülitunud, ja see nõuab, et lükkaksite lukustuskuva aktiveerimise edasi, muutes turvaseadetes suvandit. Greenify saab ka sündmused, mille tüüp on teadaanne või teavitusolekut muudetud, viimane pole Android 5.0+ seadmetes tänu teavitusjuurdepääsu funktsioonile vajalik. Siiski võtab ta neid sündmusi sellest hoolimata vastu. Greenify ei tohiks iseenesest palju ülekulusid tekitada, kuid võimalus jääb.
Nova käivitaja
Tõenäoliselt kõige populaarsem kolmanda osapoole käivitusrakendus turul, Nova Launcher on suurepärane näide rakendusest, mis kasutab juurdepääsetavuse teenust minimaalse või ilma lisakuludeta. Teenuse olemasolu ainus põhjus on teatud seadmete abistamine žestide tegemisel.
"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro /> Nagu näete, pole XML-failis hõlbustussündmust määratletud. Mainitud on vaid paketi nimi – Nova Launcher. See, mis siin juhtub, on lahendus teatud seadmete jaoks, mille puhul Nova Launcheri žestid ei tööta. See teenus pakub Nova Launcherile kõiki juurdepääsetavuse sündmusi, millest käivitati ainult Nova Launcheris. See kõlab veidralt, kuid ilmselt on see viis Nova avaekraani liigutuste parandamiseks, kui teie seade nendega ei tööta. Kuna see nõuab sündmusi ainult Novalt endalt, tekitab teenus väga vähe lisakulusid.
LastPass
Lõpuks võib-olla kõige kurikuulsam juurdepääsetavuse teenus, mis põhjustab viivitust (ilmselt selle tohutu populaarsuse tõttu) - LastPass. LastPassi viivituse probleem on nii märgatav et ettevõttel on ametnik Probleemi kirjeldav KKK leht. Nagu KKK-s öeldakse, ei saa te viivitusega midagi teha, välja arvatud teenuse keelamine. Miks tundub LastPassi teenus viivituse osas nii kohutav? Vaatame teenuse atribuute.
"@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 /> Tõde on see, et LastPassi teenuses pole midagi ebatavalist. See nõuab jälgimiseks ainult kahte tüüpi sündmusi – TYPE_VIEW_FOCUSED ja TYPE_WINDOW_CONTENT_CHANGED. See teeb seda seetõttu, et ta peab teadma, millal rakenduse/veebilehe sisu muutub/fookusesse tuleb, ja seejärel hangib praeguse akna sisu, et otsida parooli sisestusvälju. Kuid kuna teenus teeb seda pidevalt kahe eriti sageli käivitatava juurdepääsetavuse sündmuse puhul, põhjustab see viivitust. See on kahetsusväärne tõde.
Lagiga koos elamine
Kui lugesime esimest korda, et Google sulges juurdepääsetavuse viivituse veaaruanded, kuna funktsioon "töötas ettenähtud viisil", olime sama hämmeldunud ja ärritunud kui paljud teist. Kuid selle asemel, et seletust täisväärtuslikult aktsepteerida, otsustasime tõe väljaselgitamiseks ise asja uurida. Nii et kui Google'i töötaja veaaruande lehel ütles järgmist:
Tere, see probleem on püsiv Androidi versioonide puhul. Samuti esineb juurdepääsetavuse teenuse lubamisel alati täiendav viivitus. Selle põhjuseks on asjaolu, et seade lisaks standardsele kasutajaliidesele pakub juurdepääsuteenustele palju teavet, et need saaksid pakkuda neile kasutajatele alternatiivset kasutuskogemust.
Oleme aru saanud miks see on kavandatud käitumine. Rakendused, mis kasutavad juurdepääsetavuse teenuseid Google'i tahtmatul viisil, kannavad alati teatud toimivuskulusid; see kulu on lihtsalt vajalik selleks, et pakkuda teenustele hulgaliselt teavet, mille Androidi juurdepääsetavus taustal käivitab. Androidi mahajäämus juurdepääsetavusteenustega on mitte viga, vaid funktsioon. Funktsioon, millega peame elama, välja arvatud juhul, kui kogu süsteemi ümber töötatakse, ja ma ei kujuta ette, kuidas seda tehakse, et mahutada nii palju erinevaid funktsioonide komplekte nii paljudest erinevatest rakendustest.
Vähemalt LastPassi arendajad ei võtaks seda istumist maha. Nende arendajad on Chromiumi arendajatega koostööd teinud optimeerida juurdepääsetavuse tuge, võib-olla LastPassi toe lubamisega API-de kasutamise kaudu ligipääsetavuse teenuse lubamise asemel. Juurdepääsetavuse teenustega kaasnevate üldkulude optimeerimine on üks võimalus, kuid nagu paljud arendajad on kaudselt märkinud Chromiumi foorumites, see on lihtsalt side, mis ei lahenda tõsiasja, et juurdepääsetavuse teenuste tahtmatu kasutamine võib põhjustada mahajäämus.
Eriline tänu AutoInputi arendajale joaomgcd paljudele minu juurdepääsetavust puudutavatele küsimustele vastamise eest!