Известно е, че функцията за достъпност на Android причинява забавяне на потребителския интерфейс. Дали е грешка или е функция? Защо възниква? Ние от XDA проучваме първопричината.
Красотата на Android се крие в многото различни начини, по които приложенията на трети страни могат да взаимодействат със системата. Приложения за управление на пароли като LastPass предоставят възможност за автоматично подаване на подходящи данни за потребителско име/парола към почти всеки екран за влизане. Текстов помощник ви позволява значително да съкратите времето си за изпращане на съобщения на вашите приятели, като ви позволява да създавате макроси за разширяване на текст. Роден клипборд намалява неприятностите, свързани с честото превключване между приложения за копиране на големи количества текст, като ви позволява да докоснете двукратно всяко поле за въвеждане, за да изведете клипборда. Кой може да забрави Озеленяване, може би най-препоръчваното приложение №1 от ентусиастите, което държи под контрол фалшивите фонови приложения и по този начин може да удължи живота на батерията? И накрая, макар и по-малко запознат с повечето потребители, има
Автоматично въвеждане - плъгин Tasker, предназначен да автоматизира докосванията на екрана, въвеждане на текст, жестове за плъзгане и много други. Всички тези приложения обслужват изключително различни случаи на употреба, но всяко от тези приложения разчита на много неразбрана част от основната функционалност на Android: Достъпност.За обикновения потребител на Android може да изглежда странно, че много от тези удивителни функции, използвани от любимото ви приложение, се контролират от настройка под достъпност подменю. Създаване на приложение достъпен обикновено се предполага, че дадено приложение за Android може да се използва от човек с увреждания. Така че защо, за бога, LastPass, Native Clipboard, Text Aide, Greenify или AutoInput имат достъпност обслужване? Освен това, защо активирането на услуга за достъпност изглежда причиняват толкова много забавяне на потребителския интерфейс? Изглежда няма значение на каква версия на Android сте - независимо дали е Android 5.0 Lollipop или Android 7.0 Nougat - тъй като забавянето, причинено от определени услуги за достъпност, може да повлияе на вашето изживяване. Едно просто решение на този проблем е просто да деактивирате услугите за достъпност, които може да сте активирали - но по този начин губим толкова много полезна функционалност. Друго решение е да поискате от Google да „поправи“ забавянето на достъпността на Android, но Google твърди, че достъпността на Android е работи по предназначение. Разговаряхме с няколко разработчици, които са отблизо запознати с услугите за достъпност и проучихме как работи функционалността, и сме тук, за да тестваме това твърдение: забавянето на достъпността на Android грешка ли е или е функция?
Разбиране на достъпността на Android
Както можете да си представите от името, достъпността е предназначена най-вече за разработчици, за да предостави допълнителна функционалност за всички потребители с увреждания. Наистина, един бърз поглед към официални страници с документация за достъпност разкрива, че Google има доста тясна представа за това какви видове услуги трябва да се предоставят от услугите за достъпност.
Много потребители на Android имат различни способности, които изискват от тях да взаимодействат с устройствата си с Android по различни начини. Те включват потребители, които имат зрителни, физически или свързани с възрастта ограничения, които им пречат да виждат напълно или използване на сензорен екран и потребители със загуба на слуха, които може да не са в състояние да възприемат звукова информация и сигнали.
Android предоставя функции и услуги за достъпност, за да помогне на тези потребители да навигират повече в своите устройства лесно, включително текст-към-говор, тактилна обратна връзка, навигация с жестове, тракбол и насочващ панел навигация.
на Google Отвръщам, който идва предварително инсталиран на всеки телефон с Android, е чудесен пример за това каква трябва да бъде „типичната“ услуга за достъпност. Гласов достъп прави достъпността крачка напред и позволява почти пълен контрол на вашия телефон, като използвате само вашия глас. Но фактът, че Google е предвидил услугите за достъпност да се използват по този начин, не пречи разработчиците да ги прилагат по какъвто начин искат - и точно това имат разработчиците Свършен. Това е точно поради начина, по който работи Достъпността, което прави функцията невероятно полезен за потребители със или без увреждания.
За да опростим малко нещата, ето основно описание на това как работи Достъпността на Android. Разработчикът създава Услуга за достъпност че се абонира за различни Събития за достъпност които се изпращат от системата към Услугата в зависимост от това дали са изпълнени или не определени критерии. Когато всички услуги са деактивирани в Настройки --> Достъпност, Android не събира и не изпраща никакви събития за достъпност. Но когато потребителят започне да активира услугите за достъпност, Android ще започне да наблюдава и събира само тези събития за достъпност, които услугата за достъпност изисква. Например услуга за достъпност, която се абонира за събитието за достъпност TYPE_WINDOW_CONTENT_CHANGED ще бъдат уведомени от системата всеки път че настъпва промяна в текущия прозорец. Извика се друго събитие за достъпност TYPE_VIEW_CLICKED запалва всеки път потребителят кликва върху някакъв бутон.
Демонстрация за достъпност на Android. В това видео аз активирах приложението Tasker за наблюдение промени в заглавието на прозореца. Това изисква активиране на услугата за достъпност на Tasker. Можете да копирате това, като създадете нов профил в Tasker с контекста „Събитие“, зададен на „Набор на променливи“ и изберете %WIN като променлива за наблюдение. Общо този заснет видеоклип от около 1 минута 107 промени в текущия прозорец.
Тези видове събития за достъпност се случват с голяма честота по време на нормално потребителско взаимодействие. Представете си какво се случва, когато един потребител позволява множество услуги за достъпност които изискват задействане на високочестотни събития за достъпност. Това е вярно - закъснение. За да смекчат това, разработчиците могат по-тясно да определят какви видове събития за достъпност имат Услугата трябва да реагира и в какъв контекст, като например възможността да се ограничи услугата само да реагира когато в определени приложения или за ограничаване на избирателен период между Събития. Но освен това количеството режийни разходи, генерирани от услугата за достъпност, зависи най-вече от какви видове събития за достъпност се абонира за. По същество не всяка услуга за достъпност ще причини забавяне. Една единствена услуга за достъпност, която изисква високочестотно събитие, може да причини забавяне, особено ако споменатата услуга е съчетана с друга услуга, която изисква друго високочестотно събитие наблюдавани.
Гмурнете се дълбоко в достъпността с APK Teardowns
Както можете да разберете от видеоклипа, публикуван по-горе, услуга за достъпност, която следи за промени в съдържанието на прозореца, може водят до доста забележими промени в производителността на потребителския интерфейс поради огромното количество уловени събития за достъпност, изстреляни от система. Въпреки това е доста трудно да се определи точно колко режийни разходи са причинени от конкретна услуга за достъпност. Наблюдението на LogCat обикновено няма да ви доведе доникъде, тъй като събитията за достъпност се отпечатват в LogCat само ако разработчикът на услугата за достъпност избере да го направи. За щастие, бащата на всички услуги за достъпност на Android, Автоматично въвеждане, прави точно това. И изходът на LogCat е точно толкова объркан, колкото бихте си представили.
AutoInput не крие истината от нас. Разходите, причинени от приложението, могат да бъдат доста огромни в зависимост от това какви събития наблюдавате. Но тези разходи са необходими, за да функционира приложението. За да може AutoInput да прихване всяко натискане на клавиш, всеки жест на екрана, всяка актуализация на потребителския интерфейс и всяко натискане на бутон, потребности за наблюдение на съответните събития за достъпност. Без тези събития AutoInput не може да се свърже със системата и да осигури почти неограничената автоматизация на потребителския интерфейс, която позволява в момента. По този начин всички функции на AutoInput имат идеален смисъл в контекста на достъпността. Но за други приложения трябва да погледнем малко по-дълбоко, за да разберем как се обработват техните услуги за достъпност.
Услуга за достъпност атрибути са определени в ан XML ресурсен файл в рамките на APK. Следователно можем да извършим Разглобяване на APK в приложение с услуга за достъпност, за да разберете атрибутите на услугата. Всяко приложение функционира по различен начин, така че ще се опитам да обясня как атрибутите на тяхната услуга са свързани с конкретната функция, която изпълнява.
Роден клипборд
Native Clipboard е моят избор, когато става въпрос за мениджъри на клипборда. Ако търсите много адаптивен мениджър на клипборда, Native Clipboard е доста страхотно приложение. Той дори има компонент Xposed Module, който ви позволява да натиснете дълго бутона „Поставяне“, за да изведете мениджъра на клипборда! За съжаление, ако нямате достъп до Xposed Framework (като всеки потребител на Nougat), тогава ще трябва да се примирите за активиране на услугата за достъпност, която ще ви позволи да докоснете два пъти всяко въвеждане на текст, за да изведете клипборда мениджър. Ето какво означава това.
"@string/access_decs"
android: accessibilityEventTypes="typeViewClicked|typeViewFocused|typeViewLongClicked|typeWindowStateChanged"
android: accessibilityFeedbackType="feedbackGeneric"
android: notificationTimeout="100"
android: accessibilityFlags="flagReportViewIds|flagRetrieveInteractiveWindows"
android: canRetrieveWindowContent="true"
xmlns: andro /> Услугата за достъпност на Native Clipboard изисква задействане на събитие за достъпност всеки път, когато се щракне върху изглед, продължително щракване, фокус или ако има промяна в състоянието на прозореца. Без да имам достъп до изходния код, не мога да кажа точно как работи Native Clipboard, но е вероятно Native Clipboard изчаква състоянието на прозореца, за да покаже, че софтуерната клавиатура в момента е отворена, и след това следи за докосвания при въвеждане поле. Приложението има период на запитване от 100 ms, така че определено е достатъчно бързо, за да реагира незабавно на промените във видимостта на меката клавиатура, както и на двойните докосвания. Това може да доведе до известно натоварване на потребителския интерфейс, когато потребителят използва софтуерната клавиатура, за да въвежда текст, което потенциално води до забавяне.
Озеленяване
Следва любимата програма за пестене на батерията на всички, Greenify. Greenify използва събития за достъпност, за да захранва своите различни от 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 /> Той използва промените в състоянието на прозореца, за да определи кога екранът на телефона е изключен, и изисква да забавите активирането на заключения екран, като промените опция в настройките за защита. Greenify също така ще получава събития от тип Съобщение или Променено състояние на известие, като последното е ненужно на устройства с Android 5.0+ благодарение на функцията за достъп до известия. Въпреки това, той все още ще получава тези събития, независимо от този факт. Greenify не би трябвало да причинява много режийни разходи сама по себе си, но възможността остава.
Nova Launcher
Вероятно най-популярното приложение за стартиране на трета страна на пазара, Nova Launcher е отличен пример за приложение, използващо услуга за достъпност с минимални или никакви допълнителни разходи. Единствената причина за съществуването на услугата е да подпомага определени устройства при извършването на жестове.
"@string/accessibility_service_description"
android: accessibilityEventTypes=""
android: packageNames="com.teslacoilsw.launcher"
android: accessibilityFeedbackType=""
android: notificationTimeout="10000"
android: canRetrieveWindowContent="false"
xmlns: andro /> Както можете да видите, в XML файла няма дефинирано събитие за достъпност. Всичко, което се споменава, е името на пакет - Nova Launcher. Това, което се случва тук, е заобиколно решение за определени устройства, за които жестовете на Nova Launcher не работят. Тази услуга ще предостави на Nova Launcher всички събития за достъпност, стартирани от само в Nova Launcher. Звучи странно, но очевидно е начин да поправите жестовете на началния екран на Nova, ако устройството ви не работи с тях. Тъй като това изисква събития само от самата Nova, услугата създава много малко разходи.
LastPass
И накрая, може би най-скандалната услуга за достъпност, която причинява забавяне (вероятно поради огромната си популярност) - LastPass. Проблемът със забавянето в LastPass е толкова забележимо че фирмата има длъжностно лице Страница с често задавани въпроси, описваща проблема. Както се казва в често задаваните въпроси, не можете да направите нищо относно забавянето, освен да деактивирате услугата. Защо услугата на LastPass изглежда толкова впечатляваща, когато става дума за забавяне? Нека да разгледаме атрибутите на услугата.
"@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 /> Истината е, че няма нищо наистина необичайно с услугата на LastPass. Той изисква само два типа събития за наблюдение - TYPE_VIEW_FOCUSED и TYPE_WINDOW_CONTENT_CHANGED. Той прави това, защото трябва да знае кога съдържанието на приложение/уеб страница се е променило/попада на фокус, и след това извлича текущото съдържание на прозореца, за да потърси полета за въвеждане на парола. Но тъй като услугата постоянно прави това при две изключително често задействащи събития за достъпност, това води до забавяне. Това е неприятната истина.
Живот с изоставането
Когато за първи път прочетохме, че Google затваря докладите за грешки относно забавяне на достъпността, тъй като функцията „работи по предназначение“, бяхме също толкова объркани и разстроени, колкото много от вас. Но вместо да приемем обяснението за чиста монета, решихме сами да разгледаме въпроса, за да установим истината. И така, когато служителят на Google на страницата с доклад за грешка каза следното:
Здравейте, този проблем е постоянен при изданията на Android, също така винаги ще има допълнително забавяне, когато е активирана услуга за достъпност. Това е така, защото устройството, в допълнение към стандартния потребителски интерфейс, предоставя много информация на услугите за достъпност, така че те да могат да предоставят алтернативно потребителско изживяване на тези потребители.
Разбрахме се защо това е предвидено поведение. Приложенията, които използват услугите за достъпност по начин, който не е бил предвиден от Google, винаги ще носят известно натоварване на производителността; тази цена е просто необходима, за да предостави на Услугите изобилието от информация, която Android Accessibility изстрелва във фонов режим. Изоставането на Android с услугите за достъпност е не е грешка, а функция. Функция, с която ще трябва да живеем, освен ако цялата система не бъде преработена, и не мога да си представя как ще бъде направено това, за да побере толкова много различни набори от функции от толкова много различни приложения.
Най-малкото, разработчиците на LastPass няма да приемат това заседание. Техните разработчици са работили с разработчиците на Chromium, за да оптимизиране на поддръжката за достъпност, може би като активирате поддръжката на LastPass чрез използването на API вместо да активирате услуга за достъпност. Оптимизирането около режийните разходи, понесени от услугите за достъпност, е една от възможностите, но както много разработчици имплицитно отбелязват на форумите на Chromium, това е просто превръзка, която няма да разреши факта, че нежеланото използване на услугите за достъпност може да доведе до закъснение.
Специални благодарности на разработчика на AutoInput, joaomgcd, за отговора на много от въпросите ми относно достъпността!