Android의 접근성 기능은 UI 지연을 유발하는 것으로 알려져 있습니다. 버그인가요, 아니면 기능인가요? 왜 발생합니까? XDA에서는 근본 원인을 조사합니다.
Android의 장점은 타사 애플리케이션이 시스템과 상호 작용할 수 있는 다양한 방식에 있습니다. 다음과 같은 비밀번호 관리자 앱 라스트패스 거의 모든 로그인 화면에 관련 사용자 이름/비밀번호 데이터를 자동으로 제공하는 기능을 제공합니다. 문자 보좌관 텍스트 확장 매크로를 생성하여 친구에게 문자 메시지를 보내는 시간을 크게 단축할 수 있습니다. 네이티브 클립보드 입력 필드를 두 번 탭하여 클립보드를 불러올 수 있으므로 많은 양의 텍스트를 복사하기 위해 앱을 자주 전환하는 번거로움이 줄어듭니다. 누가 잊을 수 있겠는가 그리니파이, 악성 백그라운드 앱을 점검하여 배터리 수명을 향상시킬 수 있는 매니아들이 가장 추천하는 앱 1위일까요? 마지막으로, 대부분의 사용자에게는 익숙하지 않지만 자동입력 - 화면 탭, 텍스트 입력, 스와이프 제스처 등을 자동화하도록 설계된 Tasker 플러그인입니다. 이러한 앱은 모두 매우 다양한 사용 사례를 제공하지만 각 앱은 핵심 Android 기능 중 매우 잘못 이해된 부분에 의존합니다. 접근성.
일반 Android 사용자에게는 즐겨 사용하는 앱에서 활용되는 이러한 놀라운 기능 중 다수가 아래의 설정으로 제어된다는 것이 이상하게 보일 수 있습니다. 접근성 하위 메뉴. 앱 만들기 얻기 쉬운 일반적으로 다음과 같은 기능을 가진 사람이 Android 앱을 사용할 수 있음을 의미합니다. 장애. 그렇다면 도대체 LastPass, Native Clipboard, Text Aide, Greenify 또는 AutoInput에 왜 접근성 서비스? 게다가 접근성 서비스를 활성화하는 것이 왜 그렇게 보이는가? UI 지연이 너무 많이 발생함? 사용 중인 Android 버전이 무엇인지는 중요하지 않은 것 같습니다. 안드로이드 5.0 롤리팝 또는 안드로이드 7.0 누가 - 특정 접근성 서비스로 인한 지연이 귀하의 경험에 영향을 미칠 수 있기 때문입니다. 이 문제에 대한 간단한 해결책은 활성화했을 수도 있는 접근성 서비스를 비활성화하는 것입니다. 하지만 그렇게 하면 유용한 기능이 너무 많이 손실됩니다. 또 다른 해결책은 Android의 접근성 지연을 '수정'하도록 Google에 청원하는 것입니다. 하지만 Google은 Android 접근성이 문제라고 주장합니다.
Android 접근성 이해
이름에서 짐작할 수 있듯이 접근성은 주로 개발자가 장애가 있는 사용자에게 추가 기능을 제공하기 위한 것입니다. 실제로, 접근성에 대한 공식 문서 페이지 Google은 접근성 서비스에서 어떤 종류의 서비스를 제공해야 하는지에 대해 매우 좁은 견해를 가지고 있음을 보여줍니다.
많은 Android 사용자는 다양한 방식으로 Android 기기와 상호작용해야 하는 다양한 능력을 가지고 있습니다. 여기에는 시각적, 신체적 또는 연령 관련 제한이 있어 완전히 보거나 볼 수 없는 사용자가 포함됩니다. 터치스크린을 사용하는 사용자, 청각 정보와 경고를 인지하지 못하는 청력 손실이 있는 사용자.
Android는 이러한 사용자가 기기를 더 많이 탐색할 수 있도록 접근성 기능과 서비스를 제공합니다. 텍스트 음성 변환, 촉각 피드백, 제스처 탐색, 트랙볼 및 방향 패드를 포함하여 쉽게 항해.
구글의 TalkBack모든 Android 휴대전화에 사전 설치되어 제공되는 는 '전형적인' 접근성 서비스가 어떤 것인지 보여주는 훌륭한 예입니다. 음성 액세스 접근성을 한 단계 더 발전시켜 음성만으로 휴대폰을 거의 완벽하게 제어할 수 있습니다. 그러나 Google이 접근성 서비스를 이러한 방식으로 사용하도록 의도했다는 사실이 이를 방해하지는 않습니다. 개발자는 자신이 원하는 방식으로 이를 구현하지 못하게 됩니다. 바로 이것이 개발자가 갖고 있는 방식입니다. 완료. 이 기능을 만드는 것은 바로 접근성이 작동하는 방식 때문입니다. 장애가 있거나 없는 사용자에게 매우 유용합니다..
작업을 좀 단순화하기 위해 Android 접근성 작동 방식에 대한 기본 요약은 다음과 같습니다. 개발자가 접근성 서비스 다양한 구독을 하고 있는 접근성 이벤트 특정 기준이 충족되는지 여부에 따라 시스템에서 서비스로 전송되는 정보입니다. 설정 --> 접근성에서 모든 서비스가 비활성화되면 Android는 접근성 이벤트를 수집하거나 전송하지 않습니다. 그러나 사용자가 접근성 서비스를 활성화하기 시작하면 Android는 모니터링 및 수집을 시작합니다. 접근성 서비스가 요청하는 접근성 이벤트만. 예를 들어 접근성 이벤트를 구독하는 접근성 서비스 TYPE_WINDOW_CONTENT_CHANGED 시스템에서 알림을 받게 됩니다 매번 현재 창에 변화가 발생한다는 것을 의미합니다. 또 다른 접근성 이벤트가 호출되었습니다. TYPE_VIEW_CLICKED 불이 붙다 매번 사용자가 어떤 종류의 버튼을 클릭합니다.
Android 접근성 데모. 이번 영상에서는 앱을 활성화해봤습니다 태스커 모니터링하다 창 제목 변경. 이를 위해서는 Tasker의 접근성 서비스를 활성화해야 합니다. '이벤트' 컨텍스트를 '변수 세트'로 설정하고 모니터링할 변수로 %WIN을 선택하여 Tasker에서 새 프로필을 생성하여 이를 복제할 수 있습니다. 전체적으로 이 약 1분 분량의 동영상이 캡처되었습니다. 현재 창에서 107개의 변경 사항이 있습니다.
이러한 종류의 접근성 이벤트는 일반적인 사용자 상호 작용 중에 매우 자주 발생합니다. 그럼 사용자가 여러 접근성 서비스를 활성화합니다. 빈도가 높은 접근성 이벤트가 시작되도록 요청합니다. 좋아요 - 지연. 이를 완화하기 위해 개발자는 어떤 종류의 접근성 이벤트를 더 좁게 정의할 수 있습니다. 서비스는 어떤 상황에서 반응해야 하는지(예: 서비스가 반응하도록 제한하는 기능) 언제 특정 앱 또는 제한하기 위해 투표 기간 이벤트 사이. 그러나 그 외에 접근성 서비스에 의해 생성되는 오버헤드의 양은 주로 다음에 따라 달라집니다. 어떤 종류의 접근성 이벤트 구독합니다. 본질적으로 모든 접근성 서비스가 지연을 유발하는 것은 아닙니다. 빈도가 높은 이벤트가 필요한 단일 접근성 서비스는 특히 다음과 같은 경우 지연을 일으킬 수 있습니다. 해당 서비스는 또 다른 고주파 이벤트가 필요한 다른 서비스와 결합됩니다. 모니터링.
APK 분해를 통한 접근성 심층 분석
위에 게시된 비디오에서 알 수 있듯이 창 내용의 변경 사항을 모니터링하는 접근성 서비스는 캡처된 접근성 이벤트의 엄청난 양으로 인해 UI 성능이 상당히 눈에 띄게 변경됩니다. 체계. 그러나 특정 접근성 서비스로 인해 발생하는 오버헤드가 얼마나 되는지 정확하게 판단하는 것은 매우 어렵습니다. 접근성 이벤트는 접근성 서비스 개발자가 선택한 경우에만 LogCat에 인쇄되므로 LogCat을 모니터링하면 일반적으로 아무런 효과가 없습니다. 다행히도 모든 Android 접근성 서비스의 아버지인 자동입력, 정확히 그렇습니다. 그리고 LogCat 출력은 여러분이 상상하는 것만큼 지저분합니다.
AutoInput은 우리에게 진실을 숨기지 않습니다. 앱으로 인해 발생하는 오버헤드는 모니터링하는 이벤트에 따라 상당히 클 수 있습니다. 하지만 앱이 작동하려면 이 오버헤드가 필요합니다. AutoInput이 모든 키 누름, 모든 화면 제스처, 모든 UI 업데이트 및 모든 버튼 누름을 가로채기 위해서는 필요 해당 접근성 이벤트를 모니터링합니다. 이러한 이벤트가 없으면 AutoInput은 시스템에 연결할 수 없으며 현재 허용되는 거의 무제한의 UI 자동화를 제공할 수 없습니다. 따라서 AutoInput의 모든 기능은 접근성이라는 맥락에서 완벽하게 이해됩니다. 그러나 다른 앱의 경우 접근성 서비스가 처리되는 방식을 이해하려면 좀 더 자세히 살펴볼 필요가 있습니다.
접근성 서비스의 속성 에 정의되어 있습니다. XML 리소스 파일 APK 내에서. 따라서 우리는 다음을 수행할 수 있습니다. APK 분해 접근성 서비스가 있는 앱에서 서비스의 속성을 파악합니다. 각 앱은 서로 다르게 작동하므로 해당 서비스의 속성이 앱이 수행하는 특정 기능과 어떻게 관련되는지 설명하려고 합니다.
네이티브 클립보드
기본 클립보드는 클립보드 관리자와 관련하여 제가 즐겨 사용하는 제품입니다. 고도로 사용자 정의 가능한 클립보드 관리자를 찾고 있다면 Native Clipboard가 매우 훌륭한 앱입니다. '붙여넣기' 버튼을 길게 눌러 클립보드 관리자를 불러올 수 있는 Xposed 모듈 구성 요소도 있습니다! 불행하게도 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 /> 기본 클립보드의 접근성 서비스는 보기를 클릭하거나, 길게 클릭하거나, 초점을 맞출 때마다 또는 창 상태가 변경될 때마다 접근성 이벤트를 실행하도록 요청합니다. 소스 코드에 액세스할 수 없으면 기본 클립보드가 어떻게 작동하는지 정확히 말할 수 없지만 기본 클립보드는 소프트 키보드가 현재 열려 있음을 나타내는 창 상태를 기다린 다음 입력 탭을 모니터링합니다. 필드. 이 앱의 폴링 기간은 100ms이므로 소프트 키보드 가시성 및 더블 탭의 변화에 기본적으로 즉시 반응할 수 있을 만큼 충분히 빠릅니다. 이로 인해 사용자가 소프트 키보드를 사용하여 텍스트를 입력할 때마다 약간의 UI 오버헤드가 발생하여 잠재적으로 지연이 발생할 수 있습니다.
그리니파이
다음은 모두가 좋아하는 배터리 절약 기능인 Greenify입니다. Greenify는 접근성 이벤트를 사용하여 루트가 아닌 기능을 강화합니다.
"@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는 오버헤드를 최소화하거나 전혀 사용하지 않고 접근성 서비스를 사용하는 앱의 훌륭한 예입니다. 서비스가 존재하는 유일한 이유는 제스처를 수행하는 특정 장치를 지원하는 것입니다.
"@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 내의 지연 문제는 다음과 같습니다. 눈에 띄게 회사에 공식 직원이 있다는 것 문제를 설명하는 FAQ 페이지. FAQ에 나와 있듯이 서비스를 비활성화하는 것 외에는 지연에 대해 할 수 있는 일이 없습니다. 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 릴리스에서 지속됩니다. 또한 접근성 서비스가 활성화되면 항상 추가 지연이 발생합니다. 그 이유는 장치가 표준 UI 외에도 접근성 서비스에 많은 정보를 제공하여 해당 사용자에게 대체 사용자 경험을 제공할 수 있기 때문입니다.
우리는 이해하게 되었습니다 왜 이것은 의도된 행동. Google이 의도하지 않은 방식으로 접근성 서비스를 사용하는 앱은 항상 약간의 성능 오버헤드를 발생시킵니다. 이 비용은 Android 접근성이 백그라운드에서 실행하는 수많은 정보를 서비스에 제공하는 데만 필요합니다. 접근성 서비스에 대한 Android의 지연은 다음과 같습니다. 버그가 아니라 기능. 전체 시스템을 재작업하지 않는 한 우리가 사용해야 할 기능이며, 수많은 앱의 다양한 기능 세트를 수용하기 위해 이 작업이 어떻게 수행될지 상상할 수 없습니다.
최소한 LastPass 개발자는 이것을 가만히 두지 않을 것입니다. 그들의 개발자는 Chromium 개발자와 협력하여 접근성 지원 최적화, 아마도 LastPass 지원을 활성화하여 API를 사용하여 접근성 서비스를 활성화하는 대신. 접근성 서비스로 인해 발생하는 오버헤드를 최적화하는 것도 하나의 가능성이지만 많은 개발자가 암묵적으로 언급했듯이 Chromium 포럼에서는 접근성 서비스를 의도하지 않게 사용하면 다음과 같은 결과가 발생할 수 있다는 사실을 해결하지 못하는 단순한 반창고일 뿐입니다. 지연.
접근성에 관한 많은 질문에 답변해 주신 AutoInput 개발자 joaomgcd에게 특별히 감사드립니다!