Android Performance Patterns: Why 60fps?
Why Stack Overflow recommends it
Stack Overflow users link it when explaining Android UI lag, dropped frames and the 16ms frame budget that the main thread has to respect.
Recommended by 4 people across 3 different months, 2015 to 2019.
What it is
A short episode of Google's Android Performance Patterns series in which Colt McAnlis explains how human vision perceives motion from roughly 10 to 60 frames per second. It argues that 60fps is the right target and that this leaves about 16.67 ms per frame for an app to do its work.
What people said
Recommends bryn · 2015-08 · Stack Overflow · on “Android - Laggy fragment transition with full hd display”
To me it seems you have a performance problem (probably with GPU, maybe you have an overdraw). I don't know what is the cause of it but there is plenty of tools that might help you better understand what's happening. Take a look at this article [LINK] Also android performance patterns videos might be helpful. I strongly suggest watching these: Tool - Profile GPU Rendering [LINK] Overdraw [LINK] UI and GPU [LINK] Why 60 ms [this video]
Recommends georgeok · 2015-08 · Stack Overflow · on “Drawing to canvas with user interaction is a bit laggy”
The magic number is 16 milliseconds for android to redraw the view without having framedrops. Checkout this video from android developers wich explains this. [this video] Especially check this video [LINK] It explains how to use canvas clipping in order not to draw the whole surface in every cicle, nut draw only what is needed to be draw.
Recommends Colt McAnlis · 2015-09 · Stack Overflow · on “Why does the ui not load till the while loop ends?”
There's some issues with your code (as others mentioned) but the main problem here is a mis-understanding of what the UI thread is. As described in " Rendering Performance 101 [LINK] " when your process is launched, Android will create a "main" thread for it. This thread will handle all your input callback events, as well as handle rendering operations for you. The rendering system itself will try to re-draw the screen every 16ms or so. If there's work on your main thread (also called your "UI thread") when one of these 16ms pluses happens, then you'll get what we call a "dropped frame" (see " Why 60fps? [this video] "). As such, most Android developers do everything they can to get work OFF the
Recommends Florian Barth · 2015-12 · Stack Overflow · on “How long Android's application main thread can be busy without loosing performance”
In general for 60fps your magic boundary is 16ms. If you don't need more than 16ms you won't skip frames, thus, introducing no UI lag, etc. Have a look at [this video] (around minute 2 the implications for developers are layed out)
Cites Chrisvin Jem · 2019-07 · Stack Overflow · on “TextView.mText value changed but not updated in output window”
Update - Actually, whilst the Thread.sleep() is bad(let me reiterate very bad ), the true culprit in this case is the infinite while loop that blocks the UI thread. postDelayed() puts the Runnable in the handler thread's message queue. The message queue is processed when control returns to the thread's Looper . That way the UI thread isn't blocked, instead the Runnable is run only after the specified delay time. Thread.sleep() simply blocks the thread. The control does not return to the Looper and messages cannot be processed. Sleeping in the UI thread is almost always wrong . You're better off doing something like the following, public void startWatch(View V){ final TextView time = (TextVie