3

In the new Android Vitals section in the console I'm getting warnings about more than 60% of sessions being affected by slow UI render times (missed Vsync: 1.02%, slow UI thread: 14.29%, slow draw commands: 96.84%). I've turned on GPU profiling on my test device (using the production version of the app) and I'm seeing the following TextView update causing render times well over 16ms (around 24-30ms):

updateTimer = new Timer();
updateTimer.scheduleAtFixedRate(new TimerTask() {
    @Override
    public void run() {
        runOnUiThread(new Runnable() {
            @Override
            public void run() {
                timeLeftView.setText(timeLeftString);
            }
        });
    }
}, 100, 500);

When I comment out the textView update, nothing is being changed on the screen and profiler doesn't create any new bars.

One clue is that when opening the activity with the timer, the first 3-4 updates of the timer have rendering at about 8ms but then they rise to around 24-30ms.

Another clue is when I touch any part of the screen, the render times drop back to around 8ms for a few seconds before they shoot up again to 24-30ms. When I stop touch, the render times drop back again for a few seconds before they shoot up again.

So what I'd like to know is:

  1. Is this normal for such a simple TextView update to cause high render times?
  2. Is this what's messing up my Android vitals? Because it runs at only twice a second. Could the problem be elsewhere? The above code is the only thing that's creating high bars in GPU profiling, the other elements of the app work fine, long listviews with multiple textviews and images have rendering times of around 8ms.
  3. What can I do to reduce these draw times? I've tried removing the centering and gravity in the layout for the TextView, as well as wrap_content (as suggested in another answer) but neither have any effect. Apart from that, I'm unsure what to do.
TimSim
  • 3,936
  • 7
  • 46
  • 83
  • I had a very similar question https://stackoverflow.com/questions/44233870/how-to-fix-slow-rendering-android-vitals. Perhaps you would like to share if you made any progress. The issue has come to the forefront for me now that I can't limit the devices it tests on to only Pixel. – Steve M Oct 20 '17 at 15:55
  • And now they have officially stated that Android Vitals bad behaviors will affect app ranking on Play Store. – Steve M Oct 20 '17 at 15:56
  • Those rat bastards. As for making progress, I've reduced the number of sessions that experience that behavior from 68% to 35% which is still way too much. – TimSim Oct 21 '17 at 14:36
  • Did you decrease the frequency of setText calls? – Steve M Oct 23 '17 at 11:32
  • No, I'm not sure how I reduced the percentage or even if it was anything I did. I changed/simplified some layout and new/faster devices became available. But the problem is evident (to a lesser degree) even on basic templates when you create a new project in Android Studio. – TimSim Oct 23 '17 at 12:26

2 Answers2

1

If you put a lot of layers in your xml it will force android to render multiple times ( if you have a lot of layers, refact your code!! ). I strongly recommend this reading : https://developer.android.com/training/improving-layouts/index.html

About render the TextView multiple times, the speed of the rendering depends of the device you are running your application!

Rodrigo Gontijo
  • 587
  • 1
  • 9
  • 21
1

Tried pretty much every suggestion.

Finally solved it by increasing the frequency of the runnable from 500ms to 50ms or shorter. The problem was that the low frequency of the runnable let the CPU/GPU go to a low power state so draws took longer. By increasing the frequency of the runnable and the draws, the CPU/GPU doesn't go into low power state and frames are drawn much faster. Yes, it's more taxing on the battery but not as much as the screen being on in the first place. No users have complained either way and Android vitals are happy now.

Besides, looking at how default/official apps from device manufacturers work (including from Google itself), this is exactly how they handle TextView updates. Google's clock app for example (countdown timer, not stopwatch) updates the TextView ~60 times a second even though once a second would be all that's needed and most frugal.

TimSim
  • 3,936
  • 7
  • 46
  • 83