Why Is A Timer On Android More Accurate When A Finger Is Touching The Screen?

In Delphi 10.1 Berlin, I'm making an Android app. I created a timer like this: fTimer := TTimer.Create(nil); fTimer.Interval := 1; fTimer.OnTimer := OnTimer; fTimer.Enabled := True

Solution 1:

Unlike VCL's TTimer, FMX's TTimer on Android is quite inefficient.

When the timer interval elapses, Android notifies FMX using a callback function (in the Androidapi.Timer unit). That callback is called by a worker thread, and it pushes the timer into a thread-safe queue (in the FMX.Platform.Android unit).

When the main UI thread checks for pending UI messages periodically, it also checks the timer queue, and if any timers are queued then their OnTimer event handlers are called (in the order that they have been queued).

However, if there are no pending UI messages, FMX may delay checking the timer queue! And then once all UI messages have been processed, there may be a delay before events are processed again. It all depends on the internal state of the FMX app.

So, there is no guarantee whatsoever that a 1 ms timer will fire its OnTimer event handler anywhere near 1 ms intervals. And it might also explain why an increase in UI activity can allow the OnTimer event to fire more often, because UI messages are being processed more often.

This differs from VCL's TTimer, which is based on the WM_TIMER UI message, which is a low-priority message that is only generated when there are no other UI messages pending. And when it is generated, it gets dispatched directly to the TTimer's internal window, there is no additional queuing involved to add extra layers of overhead. But, an increase in UI activity will slow down the TTImer.OnTimer event from firing, not speed it up.

---

In the case of TThread.Synchronize(), it actively notifies the main UI thread whenever a pending sync request needs to be handled, thus allowing the main UI thread to check for and execute sync'ed procedures sooner rather than later.