Reduce the latency between the selection span is adjusted and the toolbar is shown
Results:
We measure the latency between Editor.startActionModeInternal is called
and FloatingToolbar.show() is called.
When there is only smart action (url)
Before: ~150ms
After ~30ms
When there are 5 smart actions (phone number)
Before: ~400ms
After: ~100ms
Before and after videos:
https://recall.googleplex.com/projects/ea8c4705-96bd-46f0-9f37-786708050727
Fixed a few issues:
1. updateAssistMenuItems() gets the Icons from TextClassification
object, calls loadDrawable on them and creates the MenuItem
objects loadDrawable() is slow, especially if we have a lot of
smart action icons to load. Even worse, we are calling this
function 4 times in a row when selecting something! 1 time from
onCreateActionMode and 3 times from onPrepareActionMode.
The fix here is to avoid reloading the drawable if it is the same
text classification object.
2. From SelectionActionModeHelper, we call startActionModeInternal
before SelectionModifierCursorController.show()
Internally, SelectionModifierCursorController.show()
show the two selection handles by calling startHandle.show() and
endHandle.show(). Apparently, each handle.show() call invalidates the
action model right after it is just created! This explains two of the
unnecessary onPrepareActionModel calls.
The fix is to call SelectionModifierCursorController.show()
before startActionModeInternal() is called.
3. Editor.startActionModeInternal() does not invoke
FloatingToolbar.show() right away.
There are two issues here.
a) Editor.startActionModeInternal() ends up calling
FloatingActionModel.repositionToolbar() which hopefully calls
FloatingToolbar.show(). Sadly, it is not the case
because mViewRectOnScreen is not set at that time. mViewRectOnScreen
is set in next onPreDrawCall() call.
b) When mViewRectOnScreen is finally set and calls repositionToolbar()
again , it still won't call FloatingToolbar.show() immediately
because we think that the toolbar is moving by comparing the previous
content rect and the current content rect. They are different because
the previous one is empty(it wasn't shown before). Becoz we think it is
moving, we schedule the FloatingToolbar.show() call after 50ms.
To fix a, we now update mViewRectOnScreen() right away wihout waiting
for the next onPreDraw call().
To fix b, when the previous content rect is moving, we don't consider
the toolbar as moving anymore.
Bug: 169043706
Test: atest android.widget.TextViewActivityTest
Test: atest
cts/tests/tests/textclassifier/src/android/view/textclassifier/cts/TextViewIntegrationTest.java
Test: atest
cts/tests/tests/widget/src/android/widget/cts/TextViewTest.java
Test: Smart select a phone number and then smart select a link.
Make sure the smart actions menuitems are updated.
Test: Click on a smart linkify link. Then dismiss it by tapping outside.
Change-Id: I634b21ac7ed66a14883dc17e03ef006df5b3f223
4 files changed