Android のアクセシビリティ機能は、UI の遅延を引き起こすことが知られています。 それはバグですか、それとも機能ですか? なぜそれが起こるのでしょうか？ XDA では根本原因を調査しています。
Android の利点は、サードパーティのアプリケーションがシステムと対話できるさまざまな方法にあります。 パスワードマネージャーアプリなど ラストパス 関連するユーザー名/パスワード データをほぼすべてのログイン画面に自動的にフィードする機能を提供します。 テキストアシスタント テキスト拡張マクロを作成できるため、友人にテキストメッセージを送信する時間を大幅に短縮できます。 ネイティブクリップボード 入力フィールドをダブルタップしてクリップボードを表示できるため、大量のテキストをコピーするためにアプリを頻繁に切り替える手間が軽減されます。 誰が忘れられるだろうか 緑化、おそらく、愛好家によって最も推奨されているアプリのナンバー 1 です。不正なバックグラウンド アプリを抑制し、バッテリー寿命を延ばすことができます。 最後に、ほとんどのユーザーにはあまり馴染みがありませんが、 自動入力 - 画面タップ、テキスト入力、スワイプ ジェスチャなどを自動化するために設計された Tasker プラグイン。 これらのアプリはすべて、非常に異なるユースケースに対応しますが、これらのアプリはそれぞれ、Android のコア機能の非常に誤解されている部分に依存しています。 アクセシビリティ。
平均的な Android ユーザーにとって、お気に入りのアプリで利用されるこれらの素晴らしい機能の多くが、 アクセシビリティ サブメニュー。 アプリを作る アクセス可能な 通常、Android アプリが次のようなユーザーに使用可能であることを意味すると考えられています。 障害. では、一体なぜ LastPass、Native Clipboard、Text Aide、Greenify、または AutoInput に アクセシビリティ サービス？ さらに、アクセシビリティ サービスを有効にすると、なぜ UIの遅延が多すぎる? 使用している Android のバージョンは関係ないようです。 Android 5.0 ロリポップ または Android 7.0 ヌガー - 特定のアクセシビリティ サービスによって生じる遅延がエクスペリエンスに影響を与える可能性があるため。 この問題に対する簡単な解決策は、有効にしたユーザー補助サービスを単に無効にすることです。しかし、そうすると、多くの便利な機能が失われます。 別の解決策は、Android のアクセシビリティの遅れを「修正」するよう Google に請願することですが、Google は Android のアクセシビリティが問題であると主張しています。
Android のアクセシビリティを理解する
名前から想像できるように、アクセシビリティは主に開発者が障害のあるユーザーに追加機能を提供することを目的としています。 実際、ちょっと覗いてみると、 アクセシビリティに関する公式ドキュメント ページ は、Google がユーザー補助サービスによってどのような種類のサービスを提供すべきかについてかなり狭い視野を持っていることを明らかにしています。
多くの Android ユーザーは、さまざまな方法で Android デバイスと対話する必要があるさまざまな能力を持っています。 これらには、視覚的、身体的、または年齢に関連した制限があり、完全に見えたり見えなかったりするユーザーが含まれます。 タッチスクリーンを使用しているユーザー、および聴覚情報やアラートを知覚できない可能性がある難聴のユーザー。
Android は、これらのユーザーがデバイスをより簡単に操作できるようにするためのアクセシビリティ機能とサービスを提供します テキスト読み上げ、触覚フィードバック、ジェスチャー ナビゲーション、トラックボール、方向パッドなどを簡単に実行できます。 ナビゲーション。
Googleの トークバックは、すべての 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 は非常に優れたアプリです。 さらに、「貼り付け」ボタンを長押ししてクリップボード マネージャーを呼び出すことができる Xused Module コンポーネントもあります。 残念ながら、Xused 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 /> ネイティブ クリップボードのアクセシビリティ サービスは、ビューがクリックされる、長押しされる、フォーカスされるたび、またはウィンドウの状態に変化があるたびに、アクセシビリティ イベントを起動するように要求します。 ソース コードにアクセスできないので、ネイティブ クリップボードがどのように機能するかを正確に言うことはできませんが、おそらくネイティブ クリップボードは ウィンドウの状態がソフト キーボードが現在開いていることを示すのを待ってから、入力のタップを監視します。 分野。 アプリのポーリング期間は 100 ミリ秒なので、ソフト キーボードの可視性の変化やダブルタップに基本的に即時に反応するには十分な速さです。 これにより、ユーザーがソフト キーボードを使用してテキストを入力するたびに 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 の 2 つだけです。 これは、アプリ/Web ページのコンテンツがいつ変更されたか、フォーカスが当たったかを知る必要があるためであり、その後、現在のウィンドウのコンテンツを取得してパスワード入力フィールドを探します。 ただし、サービスは非常に頻繁に発生する 2 つのアクセシビリティ イベントに対して常にこれを実行するため、遅延が発生します。 それが残念な真実です。
遅れとともに生きる
Google がアクセシビリティのラグに関するバグ報告を、この機能が「意図したとおりに動作している」という理由で閉鎖しているというニュースを初めて読んだとき、私たちも多くの皆さんと同じように当惑し、動揺しました。 しかし、私たちは説明を額面通りに受け入れるのではなく、真実を判断するために自分たちでこの問題を調査することにしました。 そこで、バグレポートページで Google 社員が次のように述べたとき、
こんにちは、この問題は Android リリース全体にわたって持続しています。また、アクセシビリティ サービスが有効になっていると、常に追加の遅延が発生します。 これは、標準の UI に加えて、デバイスがユーザー補助サービスに多くの情報を提供し、ユーザーに代替のユーザー エクスペリエンスを提供できるようにするためです。
私たちは理解するようになりました なぜ これは 意図された動作。 Google が意図しない方法でユーザー補助サービスを使用するアプリでは、常にパフォーマンスのオーバーヘッドが発生します。 このコストは、Android アクセシビリティがバックグラウンドで起動される大量の情報をサービスに提供するために必要なだけです。 Android のユーザー補助サービスとの遅れは次のとおりです。 バグではなく機能です. システム全体が作り直されない限り、この機能は耐えなければならないでしょうが、非常に多くの異なるアプリの非常に多くの異なる機能セットにどのように対応するのか想像もつきません。
少なくとも、LastPass 開発者はこれを黙って受け入れないだろう。 彼らの開発者は、Chromium 開発者と協力して、 アクセシビリティサポートを最適化するおそらく LastPass サポートを有効にすることで APIの使用を通じて ユーザー補助サービスを有効にするのではなく。 ユーザー補助サービスによって発生するオーバーヘッドを最適化することは 1 つの可能性ですが、多くの開発者が暗黙的に指摘しているように、 Chromium フォーラム、これは単なる絆創膏であり、ユーザー補助サービスの意図しない使用によって次のような問題が発生する可能性があるという事実を解決するものではありません。 遅れ。
アクセシビリティに関する私の質問の多くに答えてくれた AutoInput の開発者 joaomgcd に感謝します。