Androidin esteettömyysominaisuuden tiedetään aiheuttavan käyttöliittymän viivettä. Onko se bugi vai ominaisuus? Miksi se tapahtuu? Me XDA: lla tutkimme perimmäistä syytä.
Androidin kauneus piilee monissa eri tavoissa, joilla kolmannen osapuolen sovellukset voivat olla vuorovaikutuksessa järjestelmän kanssa. Salasananhallintasovellukset, kuten LastPass tarjoavat mahdollisuuden syöttää automaattisesti asiaankuuluvat käyttäjätunnus-/salasanatiedot lähes mihin tahansa kirjautumisruutuun. Tekstiapulainen Voit lyhentää merkittävästi aikaasi, joka kuluu tekstiviestien lähettämiseen ystävillesi, koska voit luoda tekstinlaajennusmakroja. Alkuperäinen leikepöytä vähentää vaivaa, joka liittyy usein vaihtamiseen sovellusten välillä suurien tekstimäärien kopioimiseksi, koska voit kaksoisnapauttaa mitä tahansa syöttökenttää avataksesi leikepöydän. Kuka voi unohtaa Vihreyttää, kenties harrastajien suositelluin sovellus, joka pitää rikolliset taustasovellukset kurissa ja voi siten pidentää akun käyttöikää? Lopuksi, vaikka se on vähemmän tuttu useimmille käyttäjille, on olemassa
Tavallisesta Android-käyttäjästä saattaa tuntua oudolta, että monia näistä suosikkisovelluksesi käyttämistä hämmästyttävistä ominaisuuksista ohjataan saavutettavuus alivalikko. Sovelluksen tekeminen saatavilla on yleensä tarkoitus tarkoittaa, että Android-sovellus on käyttökelpoinen henkilölle, jolla on vammaisia. Joten miksi ihmeessä LastPassilla, Native Clipboardilla, Text Aidella, Greenifylla tai AutoInputilla on saavutettavuus palvelua? Lisäksi miksi esteettömyyspalvelun käyttöönotto näyttää siltä aiheuttaa niin paljon käyttöliittymän viivettä? Sillä ei näytä olevan väliä, mitä Android-versiota käytät – olipa se sitten Android 5.0 Lollipop tai Android 7.0 Nougat - koska tiettyjen esteettömyyspalveluiden aiheuttama viive voi vaikuttaa käyttökokemukseesi. Yksinkertainen ratkaisu tähän ongelmaan on vain poistaa käytöstä esteettömyyspalvelut, jotka olet saattanut ottaa käyttöön - mutta menetämme niin paljon hyödyllisiä toimintoja. Toinen ratkaisu on pyytää Googlea "korjaamaan" Androidin esteettömyysviive, mutta Google väittää, että Androidin saavutettavuus on toimii tarkoitetulla tavalla. Olemme keskustelleet muutaman kehittäjän kanssa, jotka tuntevat esteettömyyspalvelut, ja tutkineet, miten toiminnallisuus toimii, ja olemme täällä testataksemme tätä väitettä: onko Androidin esteettömyysviive vika vai ominaisuus?
Androidin esteettömyyden ymmärtäminen
Kuten nimestä voisi kuvitella, Accessibility on enimmäkseen tarkoitettu kehittäjille tarjoamaan lisätoimintoja kaikille vammaisille käyttäjille. Todellakin, nopea kurkistus asiaan Viralliset esteettömyyssivut paljastaa, että Googlella on melko kapea näkemys siitä, minkälaisia palveluita esteettömyyspalveluiden tulisi tarjota.
Monilla Android-käyttäjillä on erilaisia kykyjä, jotka edellyttävät heidän olevan vuorovaikutuksessa Android-laitteidensa kanssa eri tavoin. Näihin lukeutuvat käyttäjät, joilla on visuaalisia, fyysisiä tai ikään liittyviä rajoituksia, jotka estävät heitä näkemästä tai kokonaan kosketusnäyttöä käyttäville käyttäjille ja kuulovammaisille käyttäjille, jotka eivät ehkä pysty havaitsemaan kuuluvia tietoja ja hälytyksiä.
Android tarjoaa esteettömyysominaisuuksia ja -palveluita, joiden avulla nämä käyttäjät voivat navigoida laitteissaan paremmin helposti, mukaan lukien tekstistä puheeksi, haptinen palaute, ele-navigointi, ohjauspallo ja suuntalevy navigointi.
Googlen Puhua takaisin, joka on esiasennettu jokaiseen Android-puhelimeen, on loistava esimerkki siitä, millainen "tyypillisen" esteettömyyspalvelun oletetaan olevan. Äänikäyttö vie saavutettavuuden askeleen pidemmälle ja mahdollistaa puhelimen lähes täydellisen hallinnan pelkällä äänelläsi. Mutta se, että Google aikoi esteettömyyspalveluita käytettäväksi tällä tavalla, ei estä kehittäjiä ottamasta niitä käyttöön haluamallaan tavalla – ja juuri sitä kehittäjillä on tehty. Ominaisuuden tekee juuri esteettömyystoimintojen toimintatavoista uskomattoman hyödyllinen käyttäjille, joilla on vamma tai ei.
Asioiden yksinkertaistamiseksi tässä on peruskatsaus Androidin esteettömyystoiminnon toiminnasta. Kehittäjä luo Esteettömyyspalvelu joka tilaa erilaisia Esteettömyystapahtumat jotka järjestelmä lähettää Palveluun riippuen siitä, täyttyvätkö tietyt kriteerit vai eivät. Kun kaikki palvelut on poistettu käytöstä kohdassa Asetukset --> Esteettömyys, Android ei kerää tai lähetä esteettömyystapahtumia. Mutta kun käyttäjä ottaa esteettömyyspalvelut käyttöön, Android alkaa seurata ja kerätä vain ne saavutettavuustapahtumat, joita esteettömyyspalvelu pyytää. Esimerkiksi esteettömyyspalvelu, joka tilaa esteettömyystapahtuman TYPE_WINDOW_CONTENT_CHANGED järjestelmä ilmoittaa joka ikinen kerta että nykyisessä ikkunassa tapahtuu muutos. Toinen esteettömyystapahtuma nimeltään TYPE_VIEW_CLICKED syttyy joka ikinen kerta käyttäjä napsauttaa jonkinlaista painiketta.
Androidin esteettömyysesittely. Tässä videossa olen ottanut sovelluksen käyttöön Tasker valvoa varten muutokset ikkunan otsikossa. Tämä edellyttää Taskerin esteettömyyspalvelun käyttöönottoa. Voit kopioida tämän luomalla uuden profiilin Taskerissa, jossa Tapahtuma-konteksti on asetettu arvoon Variable Set ja valitsemalla valvotavaksi muuttujaksi %WIN. Yhteensä tämä noin 1 minuutin video on kuvattu 107 muutosta nykyisessä ikkunassa.
Tällaisia saavutettavuustapahtumia esiintyy usein tavallisen käyttäjän vuorovaikutuksen aikana. Joten kuvittele mitä tapahtuu, kun käyttäjä mahdollistaa useita esteettömyyspalveluita jotka vaativat korkeataajuisten saavutettavuustapahtumien käynnistämistä. Oikein - viive. Tämän lieventämiseksi kehittäjät voivat määritellä suppeammin, millaisia saavutettavuustapahtumia heillä on Palvelun tulee reagoida ja missä yhteydessä, kuten mahdollisuus rajoittaa Palvelu vain reagoimaan kun sisään tietyt sovellukset tai rajoittaa äänestysaika Tapahtumien välillä. Mutta muusta kuin esteettömyyspalvelun tuottaman yleiskustannusten määrä riippuu enimmäkseen millaisia esteettömyystapahtumia se tilaa. Pohjimmiltaan kaikki esteettömyyspalvelut eivät aiheuta viivettä. Yksittäinen saavutettavuuspalvelu, joka vaatii korkeataajuisen Tapahtuman, voi aiheuttaa viivettä, varsinkin jos mainittu palvelu on yhdistetty toiseen palveluun, joka vaatii toisen korkeataajuisen Tapahtuman seurataan.
Sukella syvälle saavutettavuuteen APK Teardowns -toiminnolla
Kuten yllä julkaistusta videosta voi päätellä, esteettömyyspalvelu, joka tarkkailee ikkunan sisällön muutoksia, voi aiheuttaa melko huomattavia muutoksia käyttöliittymän suorituskyvyssä johtuen valtavasta määrästä taltioituja saavutettavuustapahtumia, jotka järjestelmä. On kuitenkin melko vaikeaa määrittää tarkasti, kuinka paljon ylimääräisiä kustannuksia tietty esteettömyyspalvelu aiheuttaa. LogCatin valvonta ei yleensä johda mihinkään, koska saavutettavuustapahtumat tulostetaan LogCatiin vain, jos saavutettavuuspalvelun kehittäjä niin päättää. Onneksi kaikkien Androidin esteettömyyspalveluiden isä, AutoInput, tekee juuri niin. Ja LogCat-tulostus on juuri niin sotkuinen kuin voisi kuvitella.
AutoInput ei piilota totuutta meiltä. Sovelluksen aiheuttamat yleiskustannukset voivat olla melko valtavia riippuen siitä, mitä tapahtumia seuraat. Mutta tämä yleiskustannukset ovat välttämättömiä sovelluksen toimimiseksi. Jotta automaattinen syöttö voi siepata jokaisen näppäinpainalluksen, jokaisen näytön eleen, jokaisen käyttöliittymäpäivityksen ja jokaisen painikkeen painalluksen, se tarpeisiin seurataksesi vastaavia saavutettavuustapahtumia. Ilman näitä tapahtumia AutoInput ei voi liittyä järjestelmään ja tarjota lähes rajatonta käyttöliittymäautomaatiota, jonka se tällä hetkellä mahdollistaa. Näin ollen kaikki AutoInputin toiminnot ovat täysin järkeviä saavutettavuuden yhteydessä. Mutta muiden sovellusten osalta meidän on katsottava hieman syvemmälle ymmärtääksemme, kuinka niiden esteettömyyspalveluita käsitellään.
Esteettömyyspalvelu attribuutteja on määritelty an XML-resurssitiedosto APK: n sisällä. Siksi voimme suorittaa an APK: n purku sovelluksessa, jossa on esteettömyyspalvelu, selvittääksesi palvelun attribuutit. Jokainen sovellus toimii eri tavalla, joten yritän selittää, kuinka niiden Palvelun attribuutit liittyvät sen suorittamaan tiettyyn toimintoon.
Alkuperäinen leikepöytä
Alkuperäinen leikepöytä on suosikkini leikepöydän johtajien suhteen. Jos etsit erittäin muokattavissa olevaa leikepöydän hallintaa, Native Clipboard on melko loistava sovellus. Siinä on jopa Xposed Module -komponentti, jonka avulla voit painaa pitkään 'Liitä'-painiketta avataksesi leikepöydän hallinnan! Valitettavasti, jos sinulla ei ole pääsyä Xposed Frameworkiin (kuten jokainen Nougatin käyttäjä), sinun on ratkaistava esteettömyyspalvelun käyttöönotto, jonka avulla voit kaksoisnapauttaa mitä tahansa tekstinsyöttöä avataksesi leikepöydän johtaja. Tässä on mitä se sisältää.
"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro /> Alkuperäisen leikepöydän saavutettavuuspalvelu pyytää esteettömyystapahtuman käynnistämistä joka kerta, kun näkymää napsautetaan, klikataan pitkään, kohdistetaan tai jos ikkunan tila muuttuu. Ilman pääsyä lähdekoodiin en voi sanoa tarkalleen, kuinka alkuperäinen leikepöytä toimii, mutta on todennäköistä, että alkuperäinen leikepöytä odottaa, että ikkunatila ilmaisee, että pehmeä näppäimistö on tällä hetkellä auki, ja tarkkailee sitten syötteen napautuksia ala. Sovelluksen kyselyjakso on 100 ms, joten se on varmasti riittävän nopea reagoimaan periaatteessa välittömästi muutoksiin pehmeän näppäimistön näkyvissä sekä kaksoisnapautuksissa. Tämä voi aiheuttaa käyttöliittymän ylikuormitusta aina, kun käyttäjä käyttää pehmeää näppäimistöä minkä tahansa tekstin kirjoittamiseen, mikä voi johtaa viiveeseen.
Vihreyttää
Seuraavaksi on kaikkien suosikki akunsäästö, Greenify. Greenify käyttää saavutettavuustapahtumia ei-root-toimintojensa käynnistämiseen.
"@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 /> Se käyttää ikkunan tilan muutoksia määrittääkseen, milloin puhelimen näyttö on sammunut, ja se edellyttää, että viivytät lukitusnäytön aktivointia muuttamalla suojausasetusten vaihtoehtoa. Greenify vastaanottaa myös Tapahtumat, joiden tyyppi on Announcement tai Notification State muutettu, jälkimmäinen on tarpeeton Android 5.0+ -laitteissa Notification Access -ominaisuuden ansiosta. Se kuitenkin vastaanottaa nämä tapahtumat siitä huolimatta. Greenifyn ei pitäisi itsessään aiheuttaa paljon ylimääräisiä kustannuksia, mutta mahdollisuus on olemassa.
Nova Launcher
Todennäköisesti markkinoiden suosituin kolmannen osapuolen käynnistyssovellus, Nova Launcher on erinomainen esimerkki sovelluksesta, joka käyttää esteettömyyspalvelua minimaalisella tai ilman ylimääräisiä kustannuksia. Ainoa syy Palvelun olemassaoloon on auttaa tiettyjä laitteita suorittamaan eleitä.
"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro /> Kuten näet, XML-tiedostossa ei ole määritetty saavutettavuustapahtumaa. Mainitaan vain paketin nimi - Nova Launcher. Tässä tapahtuu kiertotapa tietyille laitteille, joissa Nova Launcherin eleet eivät toimi. Tämä palvelu tarjoaa Nova Launcherille kaikki esteettömyystapahtumat, joista lähdetään vain Nova Launcherissa. Se kuulostaa oudolta, mutta se on ilmeisesti tapa korjata Novan aloitusnäytön eleet, jos laitteesi ei toimi niiden kanssa. Koska tämä pyytää tapahtumia vain Novalta itseltään, palvelu aiheuttaa hyvin vähän ylimääräisiä kustannuksia.
LastPass
Lopuksi ehkä surullisen kuuluisin saavutettavuuspalvelu, joka aiheuttaa viivettä (luultavasti sen valtavan suosion vuoksi) - LastPass. LastPassin viiveongelma on niin havaittavissa että yhtiöllä on virkamies Ongelmaa kuvaava UKK-sivu. Kuten UKK: ssa todetaan, viiveelle ei voi tehdä muuta kuin poistaa palvelun käytöstä. Miksi LastPassin palvelu näyttää niin törkeältä, kun on kyse viiveestä? Katsotaanpa palvelun ominaisuuksia.
"@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 /> Totuus on, että LastPassin palvelussa ei ole mitään poikkeavaa. Se pyytää valvomaan vain kahta tapahtumatyyppiä - TYPE_VIEW_FOCUSED ja TYPE_WINDOW_CONTENT_CHANGED. Se tekee tämän, koska sen on tiedettävä, milloin sovelluksen/verkkosivun sisältö muuttuu/tulee fokukseen, ja sitten se hakee nykyisen ikkunan sisällön etsiäkseen salasanan syöttökenttiä. Mutta koska palvelu tekee tämän jatkuvasti kahdessa erittäin usein käynnistyvässä esteettömyystapahtumassa, se johtaa viiveeseen. Se on valitettava totuus.
Lagin kanssa asuminen
Kun luimme ensimmäisen kerran, että Google oli sulkemassa esteettömyysviivettä koskevia virheraportteja, koska ominaisuus "toimii tarkoitetulla tavalla", olimme aivan yhtä hämmentyneitä ja järkyttyneitä kuin monet teistä. Mutta sen sijaan, että hyväksyisimme selityksen nimellisarvolla, päätimme tutkia asiaa itse selvittääksemme totuuden. Joten kun Googlen työntekijä virheraporttisivulla sanoi tämän:
Hei, tämä ongelma on jatkuva Android-julkaisujen aikana. Lisäksi tulee aina ylimääräinen viive, kun esteettömyyspalvelu otetaan käyttöön. Tämä johtuu siitä, että laite tarjoaa tavallisen käyttöliittymän lisäksi paljon tietoa esteettömyyspalveluille, jotta ne voivat tarjota käyttäjille vaihtoehtoisen käyttökokemuksen.
Olemme tulleet ymmärtämään miksi Tämä on aiottua käyttäytymistä. Sovellukset, jotka käyttävät esteettömyyspalveluita tavalla, jota Google ei ole halunnut, aiheuttavat aina jonkin verran suorituskykyä. tämä hinta on yksinkertaisesti välttämätön, jotta Palvelut saavat runsaasti tietoa, jonka Androidin esteettömyys laukaisee taustalla. Androidin viive esteettömyyspalveluiden kanssa on ei bugi vaan ominaisuus. Ominaisuus, jonka kanssa meidän on elettävä, ellei koko järjestelmää uudisteta, enkä voi kuvitella, kuinka se tehtäisiin niin, että siihen mahtuisi niin monia erilaisia ominaisuusjoukkoja niin monista eri sovelluksista.
LastPass-kehittäjät eivät ainakaan suostuisi istumaan. Niiden kehittäjät ovat tehneet yhteistyötä Chromium-kehittäjien kanssa optimoida esteettömyystuki, ehkä ottamalla käyttöön LastPass-tuen API: iden käytön kautta esteettömyyspalvelun käyttöönoton sijaan. Yksi mahdollisuus on optimoida esteettömyyspalveluista aiheutuvat yleiskustannukset, mutta kuten monet kehittäjät ovat epäsuorasti huomauttaneet Chromium-foorumeilla, se on yksinkertaisesti side, joka ei ratkaise sitä tosiasiaa, että esteettömyyspalveluiden tahaton käyttö voi johtaa viive.
Erityiset kiitokset AutoInputin kehittäjälle joaomgcd: lle, joka vastasi moniin saavutettavuutta koskeviin kysymyksiini!