diff options
| author | Qasid Ahmad Sadiq <qasid@google.com> | 2020-12-14 18:36:27 -0800 |
|---|---|---|
| committer | Qasid Ahmad Sadiq <qasid@google.com> | 2020-12-16 00:13:55 -0800 |
| commit | 103dd32a74f9962e41499b4a39b15b32e963ce65 (patch) | |
| tree | a7fee5bcc03bfa8acedbadb486dc0b409115f5ba /tools/aapt2/java/JavaClassGenerator_test.cpp | |
| parent | 312aae751f6e5b09abe25248135aee936b75dbb0 (diff) | |
Prefetching can be interupted by other service requests.
Slow prefetch requests would block user interactive requests, creating
noticeable sluggishness and unresponsiveness in accessibility services,
especially on the web.
Let's make it so a user interactive requests stops prefetching.
We can't interupt an API call, but we can stop in between API calls.
On the service side, we have to seprate the prefetch callbacks from the
find callback. And we have to make it asynchrnous. It does dispatch into
the main thread, so the AccessibilityCache can remain single threaded.
When the calls are interupted on the application side, returnPendingFindAccessibilityNodeInfosInPrefetch checks the find requests that are waiting in the queue, to see if they can be addressed by the prefetch results. If they can be, we don't have to call into potentially imperformance application code.
Bug:30969887
Test: Performance measurements, tried it out by hand to see if their are any bugs. CTSAccessibility*
Change-Id: Ia8f1152afa3987f262f37ed4583775acdd32db43
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions