Open cassgenerator opened 5 years ago
I got some more time today to look into this. The multiple calls to setText
seem to be due to the multiple images in the HTML being loaded and setText
getting called each time one is ready for display.
I stumbled on this article regarding spans. It looks like if we store a reference to the internally used spannable/editable we should be able to update the spans then call invalidate()
or requestLayout()
, depending on the change, without needing to call setText
again.
This looks promising but would probably be quite a large change. To verify that this is viable I will work on a little sample project as I get time. However I wanted to provide an update in case any of the authors or contributors have knowledge to share on this subject.
The multiple calls to setText seem to be due to the multiple images in the HTML being loaded and setText getting called each time one is ready for display.
👋 @drspaceboo , can you share here a "stacktrace" or call graph of such a case to have a look? Thanks!
@hypest It should be visible in the trace file linked in the original comments.
I would grab more but I'm away from my computer until Monday. All I did to see it today was log a stack trace when refreshText
is called.
While looking into the root causes of this issue logged against Guttenberg Mobile. I tracked down that one of the causes of the lag that is the call to
AztectText
sfromHtml
call.I made some small modifications to the app to load a large post from this comment into a string then try to load it. Then I profiled it loading that into the TextView.
From the Flame Chart we can see that the![Screen Shot 2019-03-28 at 5 19 41 pm](https://user-images.githubusercontent.com/1308624/55135053-ad7eac80-517e-11e9-8345-02acbbb7a8de.png)
fromHtml
call itself is accounting for a large portion of the time to load this string into the view, and there is also a large portion for thesetText
call on theTextView
. Both expected resultsHowever if we switch over to the Call Chart there is something very interesting happening in the second half of the chart (where the view is still unresponsive despite showing the new text). We can see that `refreshText is being called at least 8 times. Which to me looks like an opportunity for performance gains.![Screen Shot 2019-03-28 at 5 19 30 pm](https://user-images.githubusercontent.com/1308624/55135196-1108da00-517f-11e9-8946-5864fab013c4.png)
I think there are a number of items to look into, please note I don't expect these to all bear fruit but they are worth noting.
refreshText
being called at least 8 times, each callingsetText
?setSpan
,removeSpan
,insert
, andreplace
are taking up a lot of time when we are parsing and styling the HTML. Is there any small gains we can get here which might multiply given the number of calls made?Expected
When
fromHtml
is called onAztecText
the main thread should be blocked for smallest amount of time possible.Observed
We are parsing and applying styling to the string in the main thread, then calling
setText
on the underlyingTextView
multiple times before the user is able to interact with the application again.Reproduced
raw
resource directoryaztec.visualEditor.fromHtml(largeString)
Tested
Android Emulator on Android 9 with
develop
at the point of writing this issue 14b9f948b57657ab1613aefea5e9d366a436f180Stream conversion code