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
Loading
Please register or sign in to comment