"Munka a szándék szerint"

Az Android kisegítő lehetőségekről ismert, hogy késést okoz a felhasználói felületen. Ez egy bug, vagy ez egy funkció? Miért fordul elő? Mi az XDA-nál vizsgáljuk a kiváltó okot.

Az Android szépsége abban rejlik, hogy a harmadik féltől származó alkalmazások sokféle módon léphetnek kapcsolatba a rendszerrel. Jelszókezelő alkalmazások, mint pl LastPass lehetővé teszi a releváns felhasználónév/jelszó adatok automatikus betáplálását szinte bármely bejelentkezési képernyőn. Text Aide lehetővé teszi, hogy jelentősen lerövidítse a barátaival való SMS-ezés idejét azáltal, hogy szövegbővítő makrókat hozhat létre. Natív vágólap csökkenti az alkalmazások közötti gyakori váltással járó nehézségeket nagy mennyiségű szöveg másolásához, mivel lehetővé teszi, hogy duplán koppintson bármelyik beviteli mezőre a vágólap megjelenítéséhez. Ki tud felejteni Greenize, talán a rajongók által leginkább ajánlott alkalmazás, amely kordában tartja a rosszindulatú háttéralkalmazásokat, és ezáltal megnöveli az akkumulátor élettartamát? Végül, bár a legtöbb felhasználó kevésbé ismeri, van

Automatikus bevitel - egy Tasker beépülő modul, amely automatizálja a képernyő érintését, a szövegbevitelt, a csúsztatásokat és még sok mást. Ezek az alkalmazások mind nagyon különböző használati eseteket szolgálnak ki, de mindegyik alkalmazás az Android alapvető funkcióinak egy nagyon félreértett részére támaszkodik: Megközelíthetőség.

Egy átlagos Android-felhasználó számára furcsának tűnhet, hogy a kedvenc alkalmazásai által használt csodálatos funkciók közül sokat a megközelíthetőség almenübe. Alkalmazás készítése hozzáférhető jellemzően azt jelenti, hogy egy Android-alkalmazás használható egy személy számára fogyatékosok. Miért van tehát a világon a LastPass, a Native Clipboard, a Text Aide, a Greenify vagy az AutoInput megközelíthetőség szolgáltatás? Továbbá miért tűnik úgy, hogy egy akadálymentesítési szolgáltatás engedélyezése nagy felhasználói felület késést okoz? Úgy tűnik, nem mindegy, hogy az Android melyik verzióját használja – legyen az Android 5.0 Lollipop vagy Android 7.0 Nougat - mert az egyes akadálymentesítési szolgáltatások okozta késés hatással lehet az élményre. A probléma egyszerű megoldása az, ha egyszerűen letiltja az Ön által esetleg engedélyezett kisegítő lehetőségeket – de ezzel annyi hasznos funkciót veszítünk el. Egy másik megoldás az, hogy petíciót kérnek a Google-tól, hogy "javítsa" az Android akadálymentesítési késését, de a Google azt állítja, hogy az Android Accessibility rendeltetésszerűen működik. Beszéltünk néhány olyan fejlesztővel, akik alaposan ismerik a kisegítő lehetőségeket, és megvizsgáltuk a funkciók működését, és azért vagyunk itt, hogy teszteljük ezt az állítást: az Android akadálymentesítési késése hiba vagy funkció?


Az Android kisegítő lehetőségeinek megértése

Ahogy a név alapján elképzelhető, az Accessibility leginkább a fejlesztők számára készült, hogy további funkciókat biztosítson a fogyatékkal élő felhasználók számára. Valóban, egy gyors pillantás a hivatalos dokumentációs oldalak az akadálymentesítéshez feltárja, hogy a Google-nak meglehetősen szűk látóköre van arra vonatkozóan, hogy milyen szolgáltatásokat kell nyújtani az akadálymentesítési szolgáltatásoknak.

Sok Android-felhasználó különböző képességekkel rendelkezik, amelyek megkövetelik, hogy különböző módon kommunikáljanak Android-eszközeivel. Ide tartoznak azok a felhasználók, akiknek vizuális, fizikai vagy életkorral összefüggő korlátai miatt nem tudják teljes mértékben látni vagy érintőképernyő használata, valamint a hallássérült felhasználók, akik esetleg nem képesek észlelni a hallható információkat és figyelmeztetéseket.

Az Android kisegítő lehetőségeket és szolgáltatásokat kínál, amelyek segítségével ezek a felhasználók jobban navigálhatnak eszközeiken egyszerűen, beleértve a szövegfelolvasást, a tapintási visszajelzést, a kézmozdulatokkal történő navigációt, a görgetőgombot és az irányítópadot navigáció.

Google-é TalkBack, amely minden Android telefonra előre telepítve van, nagyszerű példa arra, hogy milyennek kell lennie a „tipikus” akadálymentesítési szolgáltatásnak. Hangalapú hozzáférés Egy lépéssel tovább viszi a kisegítő lehetőségeket, és lehetővé teszi telefonja szinte teljes vezérlését csak a hangja segítségével. De az a tény, hogy a Google az akadálymentesítési szolgáltatásokat ilyen módon kívánta használni, nem akadályozza meg a fejlesztőket attól, hogy tetszőleges módon implementálják őket – és a fejlesztők pontosan ezt teszik Kész. Pontosan az akadálymentesítés működési módja miatt jön létre a funkció hihetetlenül hasznos a fogyatékkal élő vagy anélküli felhasználók számára.

A dolgok leegyszerűsítése érdekében íme egy alapvető összefoglaló az Android kisegítő lehetőségeinek működéséről. A fejlesztő létrehoz egy Kisegítő lehetőségek szolgáltatás hogy előfizet a különböző Kisegítő lehetőségek amelyeket a rendszer elküld a Szolgáltatásnak attól függően, hogy bizonyos feltételek teljesülnek-e vagy sem. Ha az összes szolgáltatás le van tiltva a Beállítások --> Kisegítő lehetőségek alatt, az Android nem gyűjt és nem küld kisegítő lehetőségeket. De amikor a felhasználó elkezdi engedélyezni az akadálymentesítési szolgáltatásokat, az Android elkezdi a figyelést és az adatgyűjtést csak azokat a Kisegítő lehetőségeket, amelyeket a Kisegítő lehetőségek szolgáltatás kér. Például egy akadálymentesítési szolgáltatás, amely előfizet az akadálymentesítési eseményre TYPE_WINDOW_CONTENT_CHANGED értesítést kap a rendszer minden egyes alkalommal hogy az aktuális ablakban változás történik. Egy másik akadálymentesítési esemény az elnevezéssel TYPE_VIEW_CLICKED kigyullad minden egyes alkalommal a felhasználó rákattint valamilyen gombra.

Android kisegítő lehetőségek bemutatója. Ebben a videóban engedélyeztem az alkalmazást Tasker figyelemmel kísérni változások az ablak címében. Ehhez engedélyezni kell a Tasker akadálymentesítési szolgáltatását. Ezt megismételheti, ha új profilt hoz létre a Taskerben, az "Esemény" kontextusban "Változókészlet"-re állítva, és a %WIN-t választja figyelni kívánt változóként. Összesen ez a körülbelül 1 perces videó készült 107 változás az aktuális ablakban.

Az ilyen típusú akadálymentesítési események nagy gyakorisággal fordulnak elő normál felhasználói interakció során. Tehát képzelje el, mi történik, ha egy felhasználó több kisegítő szolgáltatást tesz lehetővé amelyek nagyfrekvenciás akadálymentesítési eseményeket kérnek. Úgy van - lemaradás. Ennek enyhítésére a fejlesztők szűkebben határozhatják meg, hogy milyen akadálymentesítési eseményeket tartsanak magukénak A szolgáltatásnak reagálnia kell, és milyen összefüggésben kell reagálnia, például korlátozni kell a Szolgáltatást, hogy csak reagáljon amikor bent bizonyos alkalmazások vagy korlátozni a szavazási időszak Események között. Ettől eltekintve azonban az akadálymentesítési szolgáltatás által generált általános költségek mértéke leginkább attól függ milyen akadálymentesítési események előfizet. Lényegében nem minden akadálymentesítési szolgáltatás okoz késést. Egyetlen akadálymentesítési szolgáltatás, amely nagyfrekvenciás eseményt igényel, késést okozhat, különösen, ha az említett szolgáltatás egy másik szolgáltatással párosul, amelyhez egy másik nagyfrekvenciás esemény szükséges figyelik.


Merüljön el a kisegítő lehetőségek mélyén az APK Teardowns segítségével

Amint azt a fent közzétett videóból is megtudhatja, az ablak tartalmában bekövetkezett változásokat figyelő Kisegítő lehetőségek szolgáltatás ezt megteheti meglehetősen észrevehető változásokat eredményez a felhasználói felület teljesítményében a rögzített akadálymentesítési események óriási mennyisége miatt, amelyeket a rendszer. Azonban meglehetősen nehéz pontosan meghatározni, hogy egy adott akadálymentesítési szolgáltatás mennyi többletköltséget okoz. A LogCat figyelése általában nem vezet sehova, mivel a kisegítő lehetőségeket csak akkor nyomtatja ki a LogCat, ha az akadálymentesítési szolgáltatás fejlesztője úgy dönt. Szerencsére az összes Android kisegítő szolgáltatás apja, Automatikus bevitel, pontosan ezt teszi. És a LogCat kimenet pontosan olyan rendetlen, mint ahogyan azt elképzelné.

Az AutoInput nem rejti el előlünk az igazságot. Az alkalmazás által okozott rezsi elég hatalmas lehet attól függően, hogy milyen eseményeket figyel. De ez a többletköltség szükséges az alkalmazás működéséhez. Annak érdekében, hogy az AutoInput elfogjon minden gombnyomást, minden képernyőmozdulatot, minden UI frissítést és minden gombnyomást, igények a megfelelő akadálymentesítési események figyeléséhez. Ezen események nélkül az AutoInput nem tud bekapcsolódni a rendszerbe, és nem tudja biztosítani azt a szinte korlátlan felhasználói felület automatizálást, amelyet jelenleg lehetővé tesz. Így az AutoInput összes funkciója tökéletesen értelmezhető a Kisegítő lehetőségek összefüggésében. Más alkalmazások esetében azonban egy kicsit mélyebbre kell néznünk, hogy megértsük, hogyan kezelik az akadálymentesítési szolgáltatásokat.

Egy akadálymentesítési szolgáltatás attribútumok egyben vannak meghatározva XML erőforrásfájl az APK-n belül. Ezért végre tudunk hajtani egy APK lebontása kisegítő szolgáltatással rendelkező alkalmazásban, hogy kiderítse a szolgáltatás attribútumait. Mindegyik alkalmazás másképp működik, ezért megpróbálom elmagyarázni, hogy a szolgáltatás attribútumai hogyan kapcsolódnak az általa végrehajtott konkrét funkcióhoz.

Natív vágólap

A natív vágólap a kedvencem, ha vágólapkezelőkről van szó. Ha nagymértékben testreszabható vágólapkezelőt keres, a Native Clipboard egy nagyon nagyszerű alkalmazás. Még egy Xposed Module komponenssel is rendelkezik, amely lehetővé teszi a 'Beillesztés' gomb hosszú megnyomását a vágólapkezelő megjelenítéséhez! Sajnos, ha nincs hozzáférése az Xposed Framework-hez (mint például a Nougat összes felhasználója), akkor meg kell oldania az akadálymentesítési szolgáltatás engedélyezésére, amely lehetővé teszi, hogy duplán koppintson bármilyen szövegbevitelre a vágólap megjelenítéséhez menedzser. Íme, mit jelent ez.


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

A natív vágólap akadálymentesítési szolgáltatása minden egyes alkalommal, amikor egy nézetre kattintanak, hosszan kattintanak, fókuszálnak, vagy ha az ablak állapota megváltozik, egy akadálymentesítési esemény elindítását kéri. A forráskódhoz való hozzáférés nélkül nem tudom pontosan megmondani, hogyan működik a natív vágólap, de valószínű, hogy a natív vágólap megvárja, hogy az Ablak állapot jelezze, hogy a billentyűzet jelenleg nyitva van, majd figyeli, hogy nem érinti-e meg a bemenetet terület. Az alkalmazás lekérdezési periódusa 100 ms, tehát ez határozottan elég gyors ahhoz, hogy alapvetően azonnal reagáljon a lágy billentyűzet láthatóságának változásaira, valamint a dupla koppintásokra. Ez némi többletterhelést eredményezhet a felhasználói felületen, amikor a felhasználó a puha billentyűzetet használja bármilyen szöveg beírásához, ami késést okozhat.

Greenize

Következő mindenki kedvenc akkumulátorkímélője, a Greenify. A Greenify az akadálymentesítési eseményeket használja a nem root funkcióinak működtetésére.


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

Az Ablak állapotának változásait használja annak meghatározására, hogy a telefon képernyője mikor kapcsolt ki, és megköveteli, hogy késleltesse a lezárási képernyő aktiválását a biztonsági beállítások egyik beállításának módosításával. A Greenify a Bejelentés vagy az Értesítés állapota módosult típusú eseményeket is megkapja, ez utóbbi az Android 5.0+ eszközökön az értesítési hozzáférés funkciónak köszönhetően szükségtelen. Ettől függetlenül azonban továbbra is fogadni fogja ezeket az eseményeket. A Greenify önmagában nem okoz túl sok költséget, de a lehetőség megmarad.

Nova Launcher

Valószínűleg a legnépszerűbb harmadik féltől származó indítóalkalmazás a piacon, a Nova Launcher kiváló példája az olyan alkalmazásoknak, amelyek kisegítő szolgáltatást használnak minimális vagy semmilyen többletköltséggel. A Szolgáltatás létezésének egyetlen oka az, hogy segítsen bizonyos eszközöket a gesztusok végrehajtásában.


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

Amint láthatja, az XML-fájlban nincs definiálva akadálymentesítési esemény. Csak egy csomag neve szerepel – Nova Launcher. Ami itt történik, az egy megoldás bizonyos eszközök esetében, amelyeknél a Nova Launcher gesztusai nem működnek. Ez a szolgáltatás biztosítja a Nova Launchert az összes kisegítő lehetőséghez, amelyből kiindult csak a Nova Launcheren belül. Furcsán hangzik, de nyilvánvalóan ez egy módja annak, hogy kijavítsák a Nova kezdőképernyőn megjelenő gesztusait, ha az eszköz nem működik velük. Mivel ez csak magától a Novától kér eseményeket, a szolgáltatás nagyon kevés költséget jelent.

LastPass

Végül, talán a leghírhedtebb akadálymentesítési szolgáltatás, amely késést okoz (valószínűleg óriási népszerűsége miatt) - a LastPass. A LastPasson belüli késés kérdése az annyira észrevehető hogy a cégnek van egy tisztviselője A problémát leíró GYIK oldal. Ahogy a GYIK kijelenti, a késleltetés ellen mást nem tehet, mint a szolgáltatás letiltását. Miért tűnik olyan kirívónak a LastPass szolgáltatása, ha késésről van szó? Vessünk egy pillantást a szolgáltatás attribútumaira.


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

Az igazság az, hogy a LastPass szolgáltatásában nincs semmi rendkívüli. Csak két eseménytípust kér megfigyelni – TYPE_VIEW_FOCUSED és TYPE_WINDOW_CONTENT_CHANGED. Ezt azért teszi, mert tudnia kell, ha egy alkalmazás/weboldal tartalma megváltozott/kerül a fókuszba, majd lekéri az aktuális ablak tartalmát, hogy megkeresse a jelszóbeviteli mezőket. De mivel a szolgáltatás folyamatosan ezt teszi két rendkívül gyakran aktiválódó akadálymentesítési eseményen, ez késést eredményez. Ez a sajnálatos igazság.


Együtt élni a Laggal

Amikor először olvastuk, hogy a Google lezárja a kisegítő lehetőségek késleltetésével kapcsolatos hibajelentéseket, mert a funkció „a rendeltetésszerűen működött”, mi is ugyanolyan zavarban voltunk és idegesek voltunk, mint Önök közül sokan. De ahelyett, hogy névértéken fogadnánk el a magyarázatot, úgy döntöttünk, hogy magunk is megvizsgáljuk az ügyet, hogy meghatározzuk az igazságot. Tehát amikor a Google-alkalmazott a hibajelentési oldalon ezt mondta:

Üdvözlöm, ez a probléma továbbra is fennáll az Android-verziók során, és mindig lesz további késés, ha egy kisegítő szolgáltatás engedélyezve van. Ennek az az oka, hogy az eszköz a szabványos felhasználói felületen túl sok információval szolgál az akadálymentesítési szolgáltatások számára, így azok alternatív felhasználói élményt tudnak nyújtani ezeknek a felhasználóknak.

Megértettük miért ez tervezett viselkedés. Azok az alkalmazások, amelyek a Kisegítő lehetőségeket a Google által nem szándékosan használt módon használják, mindig némi teljesítményt terhelnek; ez a költség egyszerűen szükséges ahhoz, hogy a Szolgáltatások rendelkezésére bocsássák azt a rengeteg információt, amelyet az Android Accessibility elindít a háttérben. Az Android lemaradása az akadálymentesítési szolgáltatásokkal szemben nem hiba, hanem funkció. Egy olyan funkció, amellyel együtt kell élnünk, hacsak nem dolgozzák át az egész rendszert, és el sem tudom képzelni, hogyan lehetne ezt megtenni, hogy ennyi különféle funkciókészletet alkalmazzanak ennyi különböző alkalmazásból.

A LastPass fejlesztői legalábbis ezt nem ülnék le. Fejlesztőik együttműködtek a Chromium fejlesztőivel optimalizálja a kisegítő lehetőségek támogatását, talán a LastPass támogatás engedélyezésével API-k használatával ahelyett, hogy engedélyezne egy akadálymentesítési szolgáltatást. Az akadálymentesítési szolgáltatások költségeinek optimalizálása az egyik lehetőség, de ahogy sok fejlesztő implicit módon megjegyezte, a Chromium fórumokon, ez egyszerűen egy kötszer, amely nem oldja meg azt a tényt, hogy az akadálymentesítési szolgáltatások nem szándékos használata lemaradás.


Külön köszönet az AutoInput fejlesztőjének, a joaomgcd-nek, hogy válaszolt a kisegítő lehetőségekre vonatkozó sok kérdésemre!