"Strādā kā paredzēts"

Ir zināms, ka Android pieejamības funkcija izraisa lietotāja interfeisa aizkavēšanos. Vai tā ir kļūda, vai tā ir funkcija? Kāpēc tas rodas? Mēs, XDA, pētām galveno cēloni.

Android skaistums slēpjas daudzos dažādos veidos, kā trešo pušu lietojumprogrammas var mijiedarboties ar sistēmu. Paroļu pārvaldnieka lietotnes, piemēram, LastPass nodrošina iespēju automātiski ievadīt attiecīgos lietotājvārda/paroles datus gandrīz jebkurā pieteikšanās ekrānā. Teksta palīgs ļauj ievērojami saīsināt īsziņu sūtīšanas laiku draugiem, ļaujot izveidot teksta paplašināšanas makro. Vietējā starpliktuve samazina grūtības, kas saistītas ar biežu pārslēgšanos starp lietotnēm, lai kopētu lielu teksta daudzumu, ļaujot divreiz pieskarties jebkuram ievades laukam, lai atvērtu starpliktuvi. Kurš var aizmirst Apzaļumot, iespējams, visvairāk entuziastu ieteiktā lietotne, kas kontrolē negodīgas fona lietotnes un tādējādi var pagarināt akumulatora darbības laiku? Visbeidzot, lai gan tas ir mazāk pazīstams lielākajai daļai lietotāju, ir

AutoInput - Tasker spraudnis, kas paredzēts, lai automatizētu ekrāna pieskārienus, teksta ievadi, vilkšanas žestus un daudz ko citu. Visas šīs lietotnes ir paredzētas ļoti dažādiem lietošanas gadījumiem, taču katra no šīm lietotnēm balstās uz ļoti pārprastu Android pamata funkcionalitātes daļu. Pieejamība.

Vidusmēra Android lietotājam varētu šķist dīvaini, ka daudzas no šīm lieliskajām funkcijām, kuras izmanto jūsu iecienītākā lietotne, tiek kontrolētas, izmantojot iestatījumu pieejamība apakšizvēlni. Lietotnes izveide pieejams parasti ir paredzēts, ka Android lietotne ir lietojama personai ar invaliditāti. Tātad, kāpēc pasaulē ir LastPass, Native Clipboard, Text Aide, Greenify vai AutoInput pieejamība apkalpošana? Turklāt, kāpēc šķiet, ka pieejamības pakalpojuma iespējošana izraisīt tik lielu lietotāja interfeisa nobīdi? Šķiet, ka nav nozīmes, kuru Android versiju izmantojat — vai tā ir Android 5.0 Lollipop vai Android 7.0 Nougat - jo noteiktu pieejamības pakalpojumu radītā aizkave var ietekmēt jūsu pieredzi. Vienkāršs šīs problēmas risinājums ir vienkārši atspējot piekļuves pakalpojumus, kurus, iespējams, esat iespējojis, taču, to darot, mēs zaudējam tik daudz noderīgas funkcionalitātes. Vēl viens risinājums ir iesniegt lūgumrakstu Google, lai tas "labotu" Android pieejamības nobīdi, taču Google apgalvo, ka Android pieejamība ir strādā kā paredzēts. Mēs esam runājuši ar dažiem izstrādātājiem, kuri ir cieši pazīstami ar pieejamības pakalpojumiem, un esam izpētījuši, kā šī funkcionalitāte darbojas, un esam šeit, lai pārbaudītu šo apgalvojumu. vai Android pieejamības aizkavēšanās ir kļūda vai tā ir funkcija?


Izpratne par Android pieejamību

Kā jūs varētu iedomāties pēc nosaukuma, pieejamība galvenokārt ir paredzēta izstrādātājiem, lai nodrošinātu papildu funkcionalitāti visiem lietotājiem ar invaliditāti. Patiešām, ātri ieskatieties oficiālās pieejamības dokumentācijas lapas atklāj, ka uzņēmumam Google ir diezgan šaurs skatījums uz to, kāda veida pakalpojumi būtu jānodrošina pieejamības pakalpojumiem.

Daudziem Android lietotājiem ir dažādas spējas, kas liek viņiem dažādos veidos mijiedarboties ar savām Android ierīcēm. Tie ietver lietotājus, kuriem ir vizuāli, fiziski vai ar vecumu saistīti ierobežojumi, kas neļauj viņiem pilnībā redzēt vai izmantojot skārienekrānu, un lietotājiem ar dzirdes traucējumiem, kuri, iespējams, nevar uztvert dzirdamu informāciju un brīdinājumus.

Android nodrošina pieejamības funkcijas un pakalpojumus, lai palīdzētu šiem lietotājiem vairāk pārvietoties savās ierīcēs viegli, tostarp teksta pārvēršana runā, taustes atgriezeniskā saite, žestu navigācija, kursorbumba un virzienu spilventiņš navigācija.

Google Runāt pretī, kas ir iepriekš instalēts katrā Android tālrunī, ir lielisks piemērs tam, kādam ir jābūt “parastajam” pieejamības pakalpojumam. Balss piekļuve paaugstina pieejamību un ļauj gandrīz pilnībā kontrolēt tālruni, izmantojot tikai jūsu balsi. Taču fakts, ka Google plānoja pieejamības pakalpojumus izmantot šādā veidā, to neliedz izstrādātājiem tos ieviest jebkurā veidā, un tas ir tieši tas, kas izstrādātājiem ir darīts. Tieši pieejamības darbības dēļ šī funkcija ir izveidota neticami noderīga lietotājiem ar vai bez invaliditātes.

Lai lietas nedaudz vienkāršotu, šeit ir sniegts Android pieejamības darbības pamatinformācija. Izstrādātājs izveido Pieejamības pakalpojums kas abonē dažādus Pieejamības pasākumi kurus sistēma nosūta Pakalpojumam atkarībā no tā, vai ir izpildīti noteikti kritēriji. Ja visi pakalpojumi ir atspējoti sadaļā Iestatījumi —> Pieejamība, Android neapkopo un nesūta nekādus pieejamības notikumus. Bet, kad lietotājs sāks iespējot pieejamības pakalpojumus, Android sāks pārraudzīt un apkopot tikai tos pieejamības notikumus, kurus pieprasa pieejamības pakalpojums. Piemēram, pieejamības pakalpojums, kas abonē pieejamības notikumu TYPE_WINDOW_CONTENT_CHANGED par to paziņos sistēma katru reizi ka notiek izmaiņas pašreizējā logā. Vēl viens pieejamības pasākums sauc TYPE_VIEW_CLICKED aizdegas katru reizi lietotājs noklikšķina uz kāda veida pogas.

Android pieejamības demonstrācija. Šajā videoklipā esmu iespējojis lietotni Tasker lai uzraudzītu izmaiņas loga virsrakstā. Lai to izdarītu, ir jāiespējo Tasker pieejamības pakalpojums. Varat to atkārtot, programmā Tasker izveidojot jaunu profilu ar kontekstu “Notikums”, kas iestatīts uz “Mainīgo kopa” un kā pārraugāmo mainīgo izvēloties %WIN. Kopumā tika uzņemts šis aptuveni 1 minūti garais video 107 izmaiņas pašreizējā logā.

Šāda veida pieejamības notikumi notiek ļoti bieži parastas lietotāja mijiedarbības laikā. Tāpēc iedomājieties, kas notiek, kad lietotājs iespējo vairākus pieejamības pakalpojumus kas pieprasa augstas frekvences pieejamības notikumu atslēgšanu. tieši tā - aizkavēšanās. Lai to mazinātu, izstrādātāji var šaurāk definēt, kāda veida pieejamības notikumi viņiem ir paredzēti Pakalpojumam ir jāreaģē un kādā kontekstā, piemēram, iespēja ierobežot Pakalpojumu, lai tikai reaģētu kad iekšā noteiktas lietotnes vai ierobežot vēlēšanu periods starp Notikumiem. Taču, izņemot to, pieejamības pakalpojuma radīto pieskaitāmo izmaksu apjoms galvenokārt ir atkarīgs no kāda veida pieejamības pasākumi tas abonē. Būtībā ne katrs pieejamības pakalpojums radīs kavēšanos. Viens pieejamības pakalpojums, kam nepieciešams augstas frekvences notikums, var izraisīt aizkavi, īpaši, ja minētais pakalpojums ir savienots ar citu pakalpojumu, kam nepieciešams cits augstas frekvences notikums uzraudzīta.


Iedziļinieties pieejamības jomā, izmantojot APK Teardowns

Kā jūs varat saprast no iepriekš publicētā videoklipa, pieejamības pakalpojums, kas uzrauga loga satura izmaiņas, var rada diezgan ievērojamas izmaiņas lietotāja interfeisa veiktspējā, pateicoties milzīgajam uzņemto pieejamības notikumu skaitam, ko aktivizējis sistēma. Tomēr ir diezgan grūti precīzi noteikt, cik daudz pieskaitāmo izmaksu rada konkrēts pieejamības pakalpojums. LogCat pārraudzība parasti nekur nenovedīs, jo pieejamības notikumi pakalpojumā LogCat tiek drukāti tikai tad, ja pieejamības pakalpojuma izstrādātājs to izvēlas. Par laimi, visu Android pieejamības pakalpojumu tētis, AutoInput, dara tieši tā. Un LogCat izvade ir tieši tik netīra, kā jūs varētu iedomāties.

AutoInput neslēpj no mums patiesību. Lietotnes radītās pieskaitāmās izmaksas var būt diezgan lielas atkarībā no tā, kādus notikumus pārraugāt. Taču šīs pieskaitāmās izmaksas ir nepieciešamas, lai lietotne darbotos. Lai automātiskā ievade varētu pārtvert katru taustiņu nospiešanu, katru ekrāna žestu, katru lietotāja interfeisa atjauninājumu un katru pogas nospiešanu, vajadzībām lai uzraudzītu attiecīgos pieejamības notikumus. Bez šiem notikumiem automātiskā ievade nevar pievienoties sistēmai un nodrošināt gandrīz neierobežotu lietotāja interfeisa automatizāciju, ko tā pašlaik pieļauj. Tādējādi visas automātiskās ievades funkcijas ir pilnībā saprotamas pieejamības kontekstā. Taču attiecībā uz citām lietotnēm mums ir jāmeklē mazliet dziļāk, lai saprastu, kā tiek apstrādāti to pieejamības pakalpojumi.

Pieejamības pakalpojums atribūti ir definēti an XML resursa fails APK ietvaros. Tāpēc mēs varam veikt an APK nojaukšana lietotnē ar pieejamības pakalpojumu, lai noskaidrotu pakalpojuma atribūtus. Katra lietotne darbojas atšķirīgi, tāpēc es mēģināšu paskaidrot, kā tās pakalpojuma atribūti ir saistīti ar konkrēto funkciju, ko tā veic.

Vietējā starpliktuve

Vietējā starpliktuves ir mana izvēle, kad runa ir par starpliktuves pārvaldniekiem. Ja meklējat ļoti pielāgojamu starpliktuves pārvaldnieku, vietējā starpliktuves ir diezgan lieliska lietotne. Tam pat ir Xposed Module komponents, kas ļauj ilgi nospiest pogu Ielīmēt, lai atvērtu starpliktuves pārvaldnieku! Diemžēl, ja jums nav piekļuves Xposed Framework (piemēram, ikvienam Nougat lietotājam), jums būs jāsamierinās lai iespējotu pieejamības pakalpojumu, kas ļaus jums divreiz pieskarties jebkurai teksta ievadei, lai atvērtu starpliktuvi vadītājs. Lūk, ko tas nozīmē.


"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro />

Vietējā starpliktuves pieejamības pakalpojums pieprasa aktivizēt pieejamības notikumu ikreiz, kad tiek noklikšķināts uz skata, noklikšķināts ar ilgu laiku, fokusēts vai ja tiek mainīts loga stāvoklis. Ja man nav piekļuves avota kodam, es nevaru precīzi pateikt, kā darbojas vietējā starpliktuve, taču visticamāk, ka vietējā starpliktuve gaida, kamēr loga stāvoklis norāda, ka mīkstā tastatūra pašlaik ir atvērta, un pēc tam uzrauga, vai nav pieskārienu ievadei lauks. Lietojumprogrammai ir 100 ms aptaujas periods, tāpēc tas noteikti ir pietiekami ātrs, lai būtībā nekavējoties reaģētu uz mīkstās tastatūras redzamības izmaiņām, kā arī dubultpieskārienu. Tas var radīt zināmas lietotāja saskarnes papildu izmaksas ikreiz, kad lietotājs teksta ievadīšanai izmanto mīksto tastatūru, un tas var izraisīt aizkavi.

Apzaļumot

Nākamais ir visu iecienītākais akumulatora taupīšanas līdzeklis Greenify. Greenify izmanto pieejamības notikumus, lai darbinātu savas funkcijas, kas nav saknes funkcijas.


"@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 />

Tas izmanto loga stāvokļa izmaiņas, lai noteiktu, kad tālruņa ekrāns ir izslēgts, un tas prasa aizkavēt bloķēšanas ekrāna aktivizēšanu, mainot opciju drošības iestatījumos. Greenify saņems arī tādus notikumus, kuru veids ir paziņojums vai paziņojuma statuss, kas nav nepieciešams Android 5.0+ ierīcēs, pateicoties funkcijai Notification Access. Tomēr tā joprojām saņems šos notikumus neatkarīgi no šī fakta. Greenify nevajadzētu radīt lielas izmaksas pašam par sevi, taču iespēja pastāv.

Nova palaidējs

Iespējams, populārākā trešās puses palaišanas programma tirgū, Nova Launcher ir lielisks piemērs lietotnei, kurā tiek izmantots pieejamības pakalpojums ar minimālām vai bez papildu izmaksām. Vienīgais Pakalpojuma pastāvēšanas iemesls ir palīdzēt noteiktām ierīcēm veikt žestus.


"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro />

Kā redzat, XML failā nav definēts neviens pieejamības notikums. Viss, kas minēts, ir paketes nosaukums - Nova Launcher. Tas, kas notiek šeit, ir risinājums noteiktām ierīcēm, kurām Nova Launcher žesti nedarbojas. Šis pakalpojums nodrošinās Nova Launcher visus pieejamības notikumus, kas tiek aktivizēti tikai Nova Launcher. Tas izklausās dīvaini, taču acīmredzot tas ir veids, kā labot Nova sākuma ekrāna žestus, ja jūsu ierīce ar tiem nedarbojas. Tā kā notikumi tiek pieprasīti tikai no pašas Novas, pakalpojums rada ļoti maz papildu izdevumu.

LastPass

Visbeidzot, iespējams, bēdīgi slavenais pieejamības pakalpojums, kas izraisa kavēšanos (iespējams, tā milzīgās popularitātes dēļ) - LastPass. LastPass kavēšanās problēma ir tik pamanāms ka uzņēmumam ir amatpersona FAQ lapa, kurā aprakstīta problēma. Kā norādīts FAQ, jūs nevarat darīt neko, lai novērstu kavēšanos, izņemot pakalpojuma atspējošanu. Kāpēc LastPass pakalpojums šķiet tik briesmīgs, kad runa ir par kavēšanos? Apskatīsim pakalpojuma atribūtus.


"@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 />

Patiesība ir tāda, ka ar LastPass pakalpojumu nav nekas neparasts. Tam ir nepieciešami tikai divi pārraudzības notikumu veidi — TYPE_VIEW_FOCUSED un TYPE_WINDOW_CONTENT_CHANGED. Tas tiek darīts, jo tam ir jāzina, kad lietotnes/tīmekļa lapas saturs ir mainīts/nonāk fokusā, un pēc tam izgūst pašreizējo loga saturu, lai meklētu paroles ievades laukus. Taču, tā kā pakalpojums pastāvīgi to dara divos īpaši bieži aktivizētos pieejamības notikumos, tas rada aizkavi. Tā ir nelaimīgā patiesība.


Dzīvošana ar Lagu

Kad mēs pirmo reizi izlasījām, ka Google slēdz kļūdu ziņojumus par pieejamības aizkavēšanos, jo funkcija "darbojās kā paredzēts", mēs bijām tikpat apmulsuši un satraukti kā daudzi no jums. Taču tā vietā, lai pieņemtu skaidrojumu pēc nominālvērtības, mēs nolēmām paši izpētīt šo lietu, lai noskaidrotu patiesību. Tātad, kad Google darbinieks kļūdu ziņojuma lapā teica:

Sveiki, šī problēma pastāv saistībā ar Android laidieniem, turklāt vienmēr būs papildu aizkave, kad ir iespējots pieejamības pakalpojums. Tas ir tāpēc, ka ierīce papildus standarta lietotāja saskarnei sniedz daudz informācijas pieejamības pakalpojumiem, lai tie varētu šiem lietotājiem nodrošināt alternatīvu lietotāja pieredzi.

Mēs esam sapratuši kāpēc tas ir paredzētā uzvedība. Lietotnēm, kas izmanto pieejamības pakalpojumus Google neparedzētā veidā, vienmēr būs papildu izmaksas par veiktspēju; šīs izmaksas ir vienkārši nepieciešamas, lai sniegtu pakalpojumus ar informācijas pārpilnību, ko Android pieejamība nodrošina fonā. Android aizkavēšanās ar pieejamības pakalpojumiem ir nevis kļūda, bet funkcija. Funkcija, ar kuru mums būs jāsadzīvo, ja vien visa sistēma netiks pārstrādāta, un es nevaru iedomāties, kā tas tiktu darīts, lai pielāgotos tik daudzām dažādām funkciju kopām no tik daudzām dažādām lietotnēm.

Vismaz LastPass izstrādātāji nepieņemtu šo sēdi. Viņu izstrādātāji ir sadarbojušies ar Chromium izstrādātājiem optimizēt pieejamības atbalstu, iespējams, iespējojot LastPass atbalstu izmantojot API nevis iespējot pieejamības pakalpojumu. Viena iespēja ir optimizēt pieejamības pakalpojumu radītās pieskaitāmās izmaksas, taču, kā daudzi izstrādātāji ir netieši atzīmējuši Chromium forumos, tas ir vienkārši pārsējs, kas neatrisinās faktu, ka neparedzēta pieejamības pakalpojumu izmantošana var izraisīt aizkavēšanās.


Īpašs paldies AutoInput izstrādātājam joaomgcd par atbildēm uz daudziem maniem jautājumiem par pieejamību!