v1.0.8 — throttle a11y tree walks to fix frame-rate drop#12
Merged
Conversation
User reported visible frame-rate drop while scrolling YouTube with the accessibility service active. Cause: YouTube fires TYPE_WINDOW_CONTENT_CHANGED at ~30 Hz during scroll, and v1.0.7 ran the full 1200-node tree walk on every event. That's ~36k node inspections per second while scrolling — enough to push the system past the 16ms frame budget. Two changes: 1. Throttle walks for content-changed events to one every 250ms. State-changed events (rare; fire when entering Shorts / navigating screens) keep being processed immediately so detection latency on the path that matters is unchanged. 2. Reduce MAX_NODES_PER_WALK from 1200 to 600. Empirically the relevant Shorts UI lives in the first few hundred nodes; the 1200 cap was just safety margin we don't need. Net effect for the user: while on YouTube home / scrolling the feed, we walk ~4×/sec instead of ~30×/sec, and each walk visits half as many nodes. Total CPU work in the steady state is about 1/15th of v1.0.7. Detection on Shorts open is unaffected since that triggers a STATE_CHANGED event which still walks immediately. Bump versionCode 8 → 9, versionName 1.0.7 → 1.0.8. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
User reports visible frame-rate drop on YouTube while v1.0.7's accessibility service is active. Cause is well-defined: YouTube emits `TYPE_WINDOW_CONTENT_CHANGED` at ~30 Hz during normal scrolling, and v1.0.7 ran a full 1200-node tree walk on every event. ~36k node inspections per second while scrolling is enough to bust the 16ms frame budget.
Fix
Steady-state CPU during YouTube use drops to roughly 1/15th of v1.0.7. Strict-class detection rules are unchanged.
Test plan